sramazzina commented on issue #2814: URL: https://github.com/apache/hop/issues/2814#issuecomment-5441235319
**The problem, put precisely.** Right now the interface language and the regional settings travel together: picking a language also decides your decimal separator, grouping separator, currency symbol and date formats. So there's no way to run an English interface with Italian number formats, which is what a good few of us need day to day. There's a second half to this that's easy to miss. The language is applied to formats only when the Hop GUI starts up — `hop-run` and `hop-server` never apply it and quietly use the machine's own settings instead. So the very same pipeline can produce different output in the GUI and in production whenever the machine's regional settings don't match the Hop language. If you're hashing or comparing stringified numbers downstream, that's not a cosmetic wrinkle, it's a reproducibility problem. We'd like to fix that too, and carefully. **What we'd like to build.** A new **Regional settings** tab in the configuration perspective. The existing *Preferred language* dropdown simply moves there, unchanged, and right next to it the regional settings become their own choice with three states: - **Neither option ticked (the default)** — regional settings come from the selected language, exactly as they do today. - **Use operating system regional settings** — Hop just inherits the formats from the machine it's running on, whatever the interface language happens to be. - **Override regional settings** — you pick a locale explicitly, from a list of everything the platform offers rather than only the languages Hop happens to be translated into. Whenever you make one of those two explicit choices, it's honoured everywhere — the GUI, `hop-run` and `hop-server` alike. Headless runs read the configuration of the machine they're running on, which we think is what people expect in the first place. **A safety valve for the default case.** Closing the GUI/production gap for people who *haven't* configured anything is trickier than it looks, so we're not doing it silently. The stored language is filled in automatically on first start from the machine's locale — but it falls back to English whenever that language isn't one of the fourteen Hop is translated into, or is still marked beta. On a Swedish or Greek machine, then, the stored language is English while the machine isn't, and simply honouring the configuration would change `hop-run` output for those users without them touching a thing. So there's a fourth option, **Legacy support for hop-run and hop-server**, enabled by default. While it's on, headless runs keep using the machine's regional settings for the default case, exactly as they do today — upgrade, change nothing, and nothing changes. Turn it off and headless finally agrees with the GUI. It has no effect on the two explicit choices above, which are always honoured either way. It's deliberately transitional: the idea is to drop it in a future major release and make "honour the configuration" simply the behaviour. The tab also shows a live preview of sample dates, times, numbers and currency for whichever option is selected — much like the equivalent panels in Windows and Linux — so you can see what you're getting before you save it. **On the per-transform separator options** — @mattcasters, you're right about these, and we're not proposing to touch them. They're the correct tool for their job, and they solve a genuinely different problem: a particular file or field showing up in a format that differs from the environment's. What's missing is the environment-level default underneath, which today can't be set independently of the interface language. The two work together nicely — wherever a per-transform override is set, it still wins. **Two things we'd rather flag ourselves than have someone discover later.** This kind of setting is global to the running process, so in Hop Web it belongs to the installation rather than to each connected user. That's already true of the interface language today, so it isn't a regression, but it does deserve a line in the docs. And we've deliberately left string collation — and therefore sort order — out of scope. It's arguably a regional setting too, but it changes data-affecting behaviour and deserves a conversation of its own, so we'd rather bring it back as a separate issue once this one has landed. Backward compatibility is the hard constraint running through all of it: change nothing, and nothing changes. We're covering that with an explicit regression test rather than trusting inspection. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
