Temperature와 top_p는 0 ~ 1 사이여야 합니다. 예를 들어 0,4 (또는 0.4. 형식은 언어 설정에 따라 달라지는 것 같습니다).
현재 입력 시 앞자리 0과 소수점이 지워집니다. 즉, 0,4를 입력하면 바로 4로 변합니다.
이 문제는 비교적 최근에 시작되었습니다.
물론 누군가가 범위를 0 … 100으로 설정하고자 의도적으로 이렇게 만들었다면 UX 문제일 수 있습니다.
하지만 iPad/iPhone에서의 동작을 보면 버그일 가능성이 높습니다.
유럽이시군요 
0.4를 대신 입력해 보시면 어떻게 될까요? 그래도 입력이 안 되면, 아마 우리의 숫자 입력 컴포넌트를 수정해야 할 것 같습니다 
제가 처음 시도한 것이 바로 그것이었지만, 실패했습니다. 해당 설정이 도입되었을 때, 여러분도 이상한 날짜 형식을 사용하고 있어서 먼저 0.x 형식을 사용했습니다. 
하지만 당시 저장 버튼을 클릭하면 형식이 0,x로 바뀌었습니다.
이제는 실제 숫자가 들어오면 바로 숫자가 엉망이 됩니다(음, 0도 일종의 실제 숫자긴 하죠…).
이건 …
<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 여기서 “올바른” 해결책은 무엇인가요? @ember/component의 Input을 사용하는 대신 자체 Input을 만들어야 하나요?
그렇다면 왜 숫자 외에는 아무것도 허용하지 않는 건가요? 그런 식으로 까다로운 다른 프로그램들보다 좀 더 똑똑하거나, 혹은 좀 더 엄격해서 그런 건가요? 하지만 저장하려고 할 때만 그런 건가요? 그런데 0.x 형식도 거부하는 걸 보면, 0,x를 싫어한다는 이유만으로 거부하는 셈이니, 이 부분에서는 오히려 좀 더 멍청한 것 같기도 하네요.
솔직히 궁금한 건, 올바른 문자가 아닌 모든 문자를 거부하는 방식이 어느 정도는 유용한 접근이라는 점입니다.
음, 여기서 스펙을 읽고 있는데… 이건 로케일 문제가 아닐 수도 있겠네요:
기본 단계(step)는 1입니다(단계 기본값이 정수가 아닌 경우를 제외하고는 사용자가 정수만 선택할 수 있도록 허용).
그러니까 여기서 버그는 단계(step)를 명시해야 한다는 점일지도 모르겠네요. 나중에 좀 테스트해볼게요…
HTML 문제인 것 같고, Ember 문제는 아닌 것 같습니다. 일관된 소수점 동작을 얻기 위해 전달할 수 있는 lang= 속성이 있다는 것을 시사합니다:
https://stackoverflow.com/a/7610054
(ember의 <Input이든 단순한 <input이든 작동해야 합니다)
다음으로 수정될 예정입니다:
아직 문제가 남아있으니 시연해 보겠습니다. 제가 iPhone을 사용하는 이유는 (제게) 키 스트로크를 보여주는 가장 쉬운 방법이기 때문입니다. 
최신 커밋이 있는지 100% 확신하나요?
정말 확실합니다. 그리고 그 이전 게시글보다 25분 전에 업그레이드를 마쳤습니다. 태그에 그렇게 표시되어 있다면 병합된 것으로 믿고 있습니다.
하지만 알겠습니다. 몇 시간 후에 다시 확인하고 업그레이드를 다시 진행하겠습니다.
정말 여러분은 그 문제를 해결하기 위해 귀중한 시간을 들였네요. 그런데 원인은 아주 흔한 것이었습니다: 관리자 사용자(admin-user)였죠.
문제가 되었던 부분은 제가 © 기호를 자동으로 활성화하기 위해 사용했던 이 코드 조각입니다:
<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>
제 1순위의 메시지는 이렇습니다: 죄송합니다. 제가 바보였지만, 이런 일이 일어날 수 있다고는 꿈에도 생각하지 못했습니다. 하지만 최신 업그레이드가 작동하지 않자 어딘가에서 input 관련 내용을 본 기억이 떠올랐고, 그 이후로 해결책을 찾는 것은 꽤 쉬웠습니다.
두 번째 질문은, 왜 이 문제가 특정 부분들을 깨뜨렸는지에 대한 것입니다(또한 Discourse Chatbot에서도 몇 가지 이상한 일이 발생했었거든요) — 정규식이 잘못된 건가요?
어쨌든 이것은 엄밀히 말해 버그는 아니었지만, 제게 보고된 버그 배지는 하나, 단 하나만 빼앗아 가셔도 됩니다 
전혀 걱정하지 마세요 
해결되어서 정말 기쁩니다.
문제는 조건 없이 replace를 수행하는 것이며, 이는 하위 요소에 영향을 미칩니다. 최소한의 수정은 실제로 (c)가 있을 때만 replace를 수행하는 것입니다. 하지만 저는 이 해킹 방식 자체를 권장하지 않으며, 대신 markdown prettify에서 이 작업을 수행하는 것을 권장합니다. ™
과거에 우리는 여기서 이 치환을 비활성화했습니다:
원하시는 것은 이를 다시 활성화하는 일종의 플러그인입니다.