Full stops converted to decimal commas in Inspector when spanish OS profile is in use

Hi there:

Foremost, thanks for make the Inspector a reality. That’s a terrific tool not only to debug, but indeed to make a light (but very useful) “live” authorship of 3D scenes, tweaking this and that from the GLTF/GLB files.

We’re making an intense use of it in each of our 3D web interactive projects, modifying values in order to see how that is looking in the scene, copy&pasting some values to the code in order to develop animation “stories” and so on.

Only one issue with it, that I suppose it’s related with non-EN OS profiles, more specifically with the way decimal values are managed in different languages (cultures).

For example, here in Spain, we use decimal commas instead full stops. So, when we proceed to edit any value (please note the 8.720 in position.y):

…decimal full stops are shown as decimal commas in the edit box (note that now we have an 8,721),…

…so well, after tweaking it to the desired value and make a copy&paste to the code editor, an additional (and annoying) step of revert in code the comma to the full stop must be done.

Also, as a collateral effect of this behavior, when a value is channeled via animation, it is show with a comma for each keyframe.

Any thought on this?

Thanks for your time.

1 Like

cc @carolhmj

Thanks for your comment, @PirateJC will be very satisfied with it :smiley:

We use HTML input elements for the inspector, and their usage of commas or periods is dependent of the browser locale, so this might be the cause of the behavior. We could explicitly set the locale to english so it’s consistent, but I’m not sure if this could cause other problems. @PatrickRyan what do you think? :thinking:

@paleRider, just so I understand the pain point are you saying that pasting a value with a full stop in the string will have the full stop replaced with a comma? Or are you saying that you have a copied value that has a comma in it and when you paste the value, you need to go in and change the comma to a full stop? In either case, we need to have a solve to reduce this pain point but am wondering about the best approach.

Do you work primarily with commas for decimal values to full stops? Is it the browser which is causing a problem due to a character replacement, or is it that the inspector is not flexible enough to accept and/or convert the commas to full stops itself?

I’m wondering, @carolhmj if we should just validate the string and automatically change the value to the formatting that Babylon expects, or if we should set locale. I anticipate the forcing a locale could potentially cause unwanted side effects that I would not see coming due to the fact that I work in an English locale. So I am wondering if a simple validation and conversion of characters for any number entered would be the best route. It would not cause unexpected side effects in the browser and it would allow for some flexibility in pasted values to either contain commas or fill stops for decimal values. Thoughts?