Температура и top_p должны быть в диапазоне от 0 до 1, например, 0,4 (или 0.4; формат зависит от настроек языка, полагаю).
Сейчас при вводе оно удаляет ведущий ноль и запятую (точку). То есть 0,4 сразу превращается в обычное 4.
Это началось совсем недавно.
Конечно, это может быть сделано намеренно, если кто-то хотел, чтобы значения были в диапазоне от 0 до 100, тогда это проблема UX.
Но судя по тому, как это работает на iPad/iPhone, я ставлю на баг.
Европа 
Попробуйте ввести 0.4 вместо этого… сработает ли это? Если ввод не разрешён, значит, похоже, наш компонент для чисел нужно исправить 
Это было первое, что я попробовал, но безрезультатно. Когда эти настройки были введены, я сначала использовал формат 0.x, потому что вы тоже используете странные даты 
Но тогда при нажатии на «Сохранить» формат менялся на 0,x.
Теперь числа искажаются сразу же, как только появляется реальное число (ну, ноль — это, в общем-то, реальное число…).
Вот это…
<Input
@type="number"
class="ai-persona-editor__top_p"
@value={{this.editingModel.top_p}}
disabled={{this.editingModel.system}}
/>
Проблема в том, что атрибут type=“number” вызывает сбои на европейских клавиатурах и в европейских локалях.
Когда мы запрашиваем у компонента значение, мы получаем 0,4, что правильно, но нам не хочется разбрасывать по всей кодовой базе код вроде:
if Europe Locale then replace(",",".") и так далее…
@cvx / @david, какое здесь «правильное» решение? Нужно ли нам использовать свой собственный компонент Input вместо Input из @ember/component?
Почему тогда оно принимает только числа? Оно немного умнее или строже других, которые тоже придирчивы, но только при попытке сохранить? Но в то же время оно немного глупее, так как отклоняет значения вида 0.x просто потому, что не любит формат 0,x.
Меня это просто интересует, потому что, в некотором смысле, это полезный подход — отклонять любые символы, кроме правильных.
Хм, читаю спецификацию здесь… Возможно, это не проблема локали:
Шаг по умолчанию равен 1 (что позволяет пользователю выбирать только целые числа, если только базовое значение шага не является нецелым).
Так что, возможно, ошибка в том, что нам нужно указать шаг для этого. Проверю чуть позже…
Похоже, это проблема HTML, а не Ember. Это означает, что мы можем передать атрибут lang= для обеспечения согласованного поведения при работе с десятичными числами:
(Должно работать как для Input в Ember, так и для простого <input>).
Будет исправлено в:
Позвольте мне продемонстрировать это, поскольку проблема всё ещё сохраняется. Я использую iPhone, так как это самый простой способ (для меня) показать нажатия клавиш 
Ты на 100% уверен, что у тебя последний коммит?
Действительно уверен. И обновил за 25 минут до того самого предыдущего поста. Я доверяю тому, что он слит, когда тег это подтверждает.
Но конечно. Я могу перепроверить это и выполнить обновление снова через пару часов.
Честно говоря, вы потратили на это ценное время и исправили проблему, но причина — самая обычная: пользователь-администратор.
Проблема заключалась в этом фрагменте кода, который я использовал для автоматического вставки символа ©:
<script type="text/discourse-plugin" version="0.8">
document.addEventListener('DOMContentLoaded', function() {
document.body.addEventListener('input', function(e) {
if (e.target.tagName === 'TEXTAREA' || e.target.tagName === 'INPUT') {
e.target.value = e.target.value.replace(/\(c\)/gi, '©');
}
});
});
</script>
Мой главный приоритет: извините, я глуп, но я даже не мог представить, что это может привести к подобному. Однако, когда последнее обновление не сработало, я вспомнил, что где-то видел эту штуку с input, и после этого решение оказалось довольно простым.
Второй вопрос: у вас есть идея, почему это сломало другие места (у меня также были некоторые странные случаи с Discourse Chatbot) — возможно, проблема в регулярном выражении?
В любом случае, это не был баг как таковой, так что вы можете снять со мной одну, но только одну, значок «сообщённый баг» 
Никаких проблем 
очень рад, что вы всё решили.
Проблема в том, что вы безоговорочно выполняете замену, что вмешивается в последующие процессы. Минимальное исправление — выполнять замену только если «(c)» действительно присутствует. Тем не менее, я всё же не рекомендую этот хакинг и советую делать это в рамках предобработки Markdown. ™
Раньше мы отключали эту замену здесь:
Вам нужен какой-то плагин, который снова её включит.