fix: properly work with languages with multiple scripts

[LPkkjHD]

Description

The pointers by @zlewe in the Issue have been very helpful. This is literally just the implementation.

Fixes #17965

How Has This Been Tested?

This has been manually tested with the following steps

• Open App
• Choose {zh_TW|zh_CN|sr_Latn|sr_Cyrl}
• Reopen App
• Observe the chosen language to still be selected and applied

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if applicable
• I have no unrelated changes in the PR.
• I have confirmed that any new dependencies are strictly necessary.
• I have written tests for new code (if applicable)
• I have followed naming conventions/patterns in the surrounding code
• All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc.
• All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/)

[alextran1502]

Please fix the formatting in the file. Thanks

[LPkkjHD]

@alextran1502 Done!

[zlewe]

Hi @LPkkjHD , thanks for the mention.

The i18n files should be renamed too right? I'm assuming it would default to English if it doesn't find the files.

[LPkkjHD]

The i18n files should be renamed too right? I'm assuming it would default to English if it doesn't find the files.

Not quite. The i18n files are named correct (at least that's what I gathered from testing this change).

My read on why this bug occurred is that Locale(String _languageCode, [String? _countryCode]) as per documentation does not check for invalid countryCode tags (invalid in the sense, that they don't exist in the standard) and therefore ignores it and only sets the default locale for the given languageCode.

[zlewe]

The i18n files should be renamed too right? I'm assuming it would default to English if it doesn't find the files.

Not quite. The i18n files are named correct (at least that's what I gathered from testing this change).

My read on why this bug occurred is that Locale(String _languageCode, [String? _countryCode]) as per documentation does not check for invalid countryCode tags (invalid in the sense, that they don't exist in the standard) and therefore ignores it and only sets the default locale for the given languageCode.

I agree with your read on the root cause of the original bug – that the Locale constructor wasn't properly handling the non-standard country codes like SIMPLIFIED and Hant, causing the locale setting not to stick correctly.

However, I think the change might have introduced a new issue. By changing Locale('zh', 'SIMPLIFIED') to Locale('zh', 'CN') and Locale('zh', 'Hant') to Locale('zh', 'TW'), the localization package now seems to fail to find the corresponding translation files based on my testing.

So, while the setting itself seems to stick correctly with your change, the UI language doesn't actually update and remains in English because the correct translation file isn't being loaded.

Perhaps the i18n file names do need to be updated to match the new locale identifiers? Or is there something else I might be missing in my test setup?

[LPkkjHD]

My Testing was starting the app and upon seeing the Letters of the designated scripts in the timeline checking whether the right language was still set. However, you're absolutely spot on with your take (obviously the date would translate correctly, as this is managed by the system rather than the translation strings).

I'm ashamed this slipped though as it's a rather plain error.

Perhaps the i18n file names do need to be updated to match the new locale identifiers? Or is there something else I might be missing in my test setup?

I think renaming them is a rather big hustle and touches the web code as well. We could abuse the Locale#fromSubtags() in conclusion with the scriptCode Hant | SIMPLIFIED in order to keep the current file naming as is.