Temperature and top_p shoud be between 0 … 1, eg. 0,4 (or 0.4; format comes from language settings, I reckon).
Now it erases leading zero and decimal point when entered. So. 0,4 and right away it changes to plain 4.
It started quite recently.
Sure, this can come by design too if someone wanted it be between 0 … 100 and then this would be an UX issue.
But how it acts on iPad/iPhone my bet is a bug.
Europe 
Try 0.4 instead… does that work? If it does not allow you to enter, then I guess our number component needs fixing 
That was the very first thing I tried, but no luck. When those settings was introduced I used 0.x form first, because you guys are using strange dates too 
But back then it changed the format to 0,x when I clicked save.
Now it messes numbers right away when comes a real number (well, zero is a real number, kind of…).
Its this …
<Input
@type="number"
class="ai-persona-editor__top_p"
@value={{this.editingModel.top_p}}
disabled={{this.editingModel.system}}
/>
The type=number thing is causing issues on European keyboards/locales.
When we ask the component what the value is we get a 0,4 which is correct but you don’t want code all through your code base that says:
if Europe Locale then replace(",",".") etc…
@CvX / @david what is the “correct” solution here, do we need our own Input here vs using Input from @ember/component ?
Why isn’t it accepting nothing else than numbers then? Is it a bit smarter or thigher than others that are picky that way, but only when trying to save? But a bit dummer too because it is denying 0.x too just because it doesnt like 0,x.
I’m just curious here because, kind of, it is helpful approach to deny every characters than right ones.
Hmmm reading the spec here… maybe this is not a locale issue:
The default step is 1 (allowing only integers to be selected by the user, unless the step base has a non-integer value).
So maybe the bug here is that we need to specify a step for it, will test a bit later…
Looks like it’s an HTML thing rather than an Ember thing. This suggests there’s a lang= attribute we can pass to get consistent decimal behaviour:
(Should work for either ember’s <Input or simple <input)
Will be fixed with:
Let me demonstrate that, because the issue is still there. I’m using iPhone here because it is the easiest way (for me) show key strokes 
You 100% sure you have the latest commit?
Really sure. And upgraded 25 mins before that earlier post. I trust it is merged when that tag says it is.
But sure. I can double check that and do upgrading again, in couple hours time.
Really you guys used some valuable time for that, and fixed something, but the reason is the very usual one: admin-user.
The issue was this piece of code I used to enable automatic © sign:
<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>
My priority one is: sorry, I’m stupid, but I couldn’t even imagine this could do something like this. But when latest upgrading didn’t work I remembered I’ve seen input thingy somewhere and after that solution was quite easy to find.
Secondary question is do you have an idea why that broke places (I had some other strange happenings with Discourse Chatbot too) — is regex faulty?
Anyway this wasn’t a bug per se and you can take away one, but only one, bug reported badge from me 
No worries at all 
so happy you have it sorted.
The problems is that you are unconditionally doing the replace and that is fiddling with stuff downstream, a minimal fix would be only to perform the replace it fhe (c) is actually there, that said I would recommend against this hack anyway and do this in markdown prettify. ™
Back in the day we disabled this replacement here:
What you want is some sort of plugin that re-enables it.