Temperatura e top_p devem estar entre 0 e 1, por exemplo, 0,4 (ou 0,4; o formato vem das configurações de idioma, suponho).
Agora ele apaga o zero à esquerda e o ponto decimal quando inserido. Assim, 0,4 e imediatamente muda para 4 simples.
Isso começou bem recentemente.
Claro, isso pode ser por design também se alguém quisesse que fosse entre 0 e 100 e então isso seria um problema de UX.
Mas como funciona no iPad/iPhone, aposto que é um bug.
Europa 
Tente 0.4 em vez disso… funciona? Se não permitir que você insira, acho que nosso componente numérico precisa ser corrigido 
Essa foi a primeira coisa que tentei, mas sem sucesso. Quando essas configurações foram introduzidas, usei primeiro o formato 0.x, porque vocês também usam datas estranhas 
Mas na época mudou o formato para 0,x quando eu clicava em salvar.
Agora ele bagunça os números imediatamente quando entra um número real (bem, zero é um número real, tipo…).
É isto…
<Input
@type="number"
class="ai-persona-editor__top_p"
@value={{this.editingModel.top_p}}
disabled={{this.editingModel.system}}
/>
A coisa type=number está causando problemas em teclados/localidades europeias.
Quando perguntamos ao componente qual é o valor, obtemos um 0,4 que está correto, mas você não quer código em toda a sua base de código que diga:
se Localidade Europeia então substituir(",",".") etc…
@cvx / @david qual é a solução “correta” aqui, precisamos do nosso próprio Input aqui em vez de usar Input de @ember/component?
Por que ele não está aceitando nada além de números então? Ele é um pouco mais esperto ou mais rigoroso que outros que são exigentes dessa forma, mas apenas ao tentar salvar? Mas também um pouco mais burro porque está negando 0.x também só porque não gosta de 0,x.
Estou apenas curioso aqui porque, de certa forma, é uma abordagem útil negar todos os caracteres, exceto os corretos.
Hmmm, lendo as especificações aqui… talvez isso não seja um problema de localidade:
O passo padrão é 1 (permitindo que apenas inteiros sejam selecionados pelo usuário, a menos que a base do passo tenha um valor não inteiro).
Então, talvez o bug aqui seja que precisamos especificar um passo para isso, testarei um pouco mais tarde…
Parece que é uma questão de HTML e não de Ember. Isso sugere que há um atributo lang= que podemos passar para obter um comportamento decimal consistente:
(Deve funcionar tanto para o <Input do Ember quanto para o <input simples)
Será corrigido com:
Deixe-me demonstrar isso, porque o problema ainda existe. Estou usando o iPhone aqui porque é a maneira mais fácil (para mim) de mostrar as teclas digitadas 
Tem 100% de certeza de que tem o último commit?
Tenho certeza. E fiz o upgrade 25 minutos antes da postagem anterior. Confio que está mesclado quando a tag diz que está.
Mas, claro. Posso verificar isso novamente e fazer o upgrade mais uma vez, em algumas horas.
Vocês realmente usaram um tempo valioso para isso e consertaram algo, mas o motivo é o mais comum: admin-usuário.
O problema era este trecho de código que usei para habilitar o símbolo de copyright automático:
<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>
Minha prioridade um é: desculpem, sou estúpido, mas eu nem imaginava que isso poderia fazer algo assim. Mas quando a última atualização não funcionou, lembrei que tinha visto input em algum lugar e depois disso a solução foi bem fácil de encontrar.
A pergunta secundária é se vocês têm alguma ideia de por que isso quebrou lugares (tive outras coisas estranhas acontecendo com o Discourse Chatbot também) — a regex está com defeito?
De qualquer forma, isso não foi um bug em si e vocês podem tirar um, mas apenas um, distintivo de bug reportado de mim 
Sem problemas 
fico feliz que você tenha resolvido.
O problema é que você está fazendo a substituição incondicionalmente e isso está mexendo com coisas a jusante. Uma correção mínima seria realizar a substituição apenas se o (c) estiver realmente lá. Dito isso, eu recomendaria evitar esse hack de qualquer maneira e fazer isso na formatação do markdown. ™
Antigamente, desabilitamos essa substituição aqui:
O que você quer é algum tipo de plugin que o reative.
5 posts foram mesclados em um tópico existente: Inserir símbolo de direitos autorais