Locales are case sensitive

[PanMan]

This took us some time to debug: Locales are case sensitive when the filesystem is.
On OSX (case insensitive) setting the locale to NL got strings from nl.json
In production, on a linux server, this failed and the strings didn't get translated.
I feel this should at least be in the docs, or always work case-insensitive

[mashpie]

....well, yes. When started, I decided to leave cases and names of any locale completely untouched and up to the developers or frameworks responsibility to handle it "their way"

File systems act differently - which is a well-known issue when working with git on Mac either way. But that's only part of the story. There are query-parameters, accept-headers and developers setting locales programmatically by setLocale() api. The i18n package kept matching locales "as-provided" to their files for ~ 10 years now, which treats 'en', 'en-EN', 'en_EN' individually. Let's say I got mislead by POSIX examples of locales while BCP 47 and other RTF and ISO Standards clearly state to interpret locales, headers and env variables case insensitively.

I am back referencing to #128 here. And though I can't think of a reasonable use-case, changing that could break. Adding a simpletoLowerCase() looks pretty easy, but should be either opt-in or opt-out (preceded by a deprecation period) with a config switch.

Points left to consider:

1. handle conflicting files (like: 'en-EN.json', 'en_EN.json', 'en-en.json') while reading & writing?
2. handle legacy configs like locales: ['en', 'en-EN', 'en_EN']?
3. setLocale() parameter matching
4. getLocale() return value matching

Could i18n normalize locales? Yes. Should i18n normalize locales? Only if this won't break existing implementations.

Any further thoughts are welcome.

[PanMan]

Thanks for the extensive response!
I understand everybody's usecase is different - and you don't want to break current behaviour. However, we Did run into this in our current project - twice, even :). Especially as it did work in development.
I can understand not changing the behaviour, or making it optional, but I do think it would be good to include in the documentation. I thought about a pull request, but it wasn't immediately obvious to me where it would make most sense in the docs.

[mashpie]

as for docs: https://github.com/mashpie/i18n-node#storage should be more expressive either way :) feel free to send a pr - or wait until I‘ll manage to write some more words.

…

Am 26.10.2021 um 17:05 schrieb PanMan ***@***.***>:  Thanks for the extensive response! I understand everybody's usecase is different - and you don't want to break current behaviour. However, we Did run into this in our current project - twice, even :). Especially as it did work in development. I can understand not changing the behaviour, or making it optional, but I do think it would be good to include in the documentation. I thought about a pull request, but it wasn't immediately obvious to me where it would make most sense in the docs. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.