SketchUp model and HtmlDialog locales

[j-te]

Context

Version: SketchUp 2024, Win64

• SketchUp makes the use of locales:

  Sketchup.os_language
  #=> "en-US"

• UI::HtmlDialog browser also requires locales for JS functions such as constructing dates: new Date().

  navigator.language
  // 'en-US'

The issues:

1. SketchUp does not provide a user-friendly way for a user to override/set the locale. I think this should be a model property, potentially linked to the Add location feature and be displayed/changed in Preferences. It would be good to have an API to change this too.
2. When coding a plugin using UI::HtmlDialog, the browser User Agent is incorrect and inconsistent. Normally: A browser installed on a user's machine would correctly identify the user's locale automatically. The question is, should this be linked with SketchUp's locale or correctly identified via the OS — as a browser should do? I believe it should be the latter.
   • HtmlDialog's incorrect locale is causing critical issues while working with/creating new dates in JS. There is no 'easy hack' in JS.
   • I'm sure erroneous data is being passed through plugins/server requests/forms/databases as devs may be, understandably oblivious to this.
   • Could the SketchUp team please immediately describe the current behaviour of browser locale to the UI::HtmlDialog documentation: to make this really clear to developers (as a minimum).

NB: I am developing a plugin where time conversion is critical and must be performant, and recorded correctly.

There are other issues and requests which aren't directly related but relevant...

https://forums.sketchup.com/t/preferences-option-to-change-the-language/116046/21

[Eneroth3]

Locale in HtmlDialog is likely quite unexplored territory with no defined behavior at this point.

I would expect it to honor the user locale and SketchUp language, for consistency with SketchUp. This should not be connected to the model or geo location.

I'd expect this

navigator.language

to always match this

Sketchup.os_language

(For the record, this method returns the language SketchUp runs in, not the system language as the name suggests. And SketchUp doesn't get its language from the system language, it gets it from the system locale which can be different from the user's language of choice. SketchUp also falls back to English if the language of the user locale is missing and you can override the SketchUp language with a command line argument. )

I'd expect this

1.1.toLocaleString()

to use the same decimal separator as

1.5.m.to_s

or

Sketchup::RegionalSettings.decimal_separator

I'd expect Javascript Date to match Ruby's Date and DateTime.

For the time being, maybe you can send the dates to Ruby to have them parsed and formatted? Or maybe this part of the app can be used in an external web browser and not a HtmlDialog?

[j-te]

I would expect it to honor the user locale and SketchUp language, for consistency with SketchUp.

Just to be clear I believe it should be the user OS locale for the browser. Language is a separate topic which shouldn't alone determine locale. Agreed.

This should not be connected to the model or geo location.

I do agree with this but it would be nice to have more language functionality with a property associated in the model or user setting. Extensions could make use of reading the property as there is an API currently. Technically extensions could use the lat/lng to determine the locale of the model but the browser must always use the user's locale else dates will be incorrectly created and parsed.

For the time being, maybe you can send the dates to Ruby to have them parsed and formatted? Or maybe this part of the app can be used in an external web browser and not a HtmlDialog?

I did think this but is a bit unnecessary/big overhead. Formatting and parsing is not the issue anymore as I have built-out those features. There are quite a lot of heavy time operations on tick and sharing/updating data with the model. The work-around for now is strictly only using UTC epoch (as a number) input and output of Ruby, and avoid using locale formatting anywhere. So I'm basically omitting locale from my plugin. Ideally I would prefer to work with locale/full UNIX timestamp but it's not worth the effort unless the browser is corrected. My alternative would be going down the C API and a more stand-alone plugin but my product is web-based.