Improve localization logic

[SamusAranX]

This should fix the issue where some language code/region code combinations would result in English text instead of the appropriate localization.

I noticed that most of the different region codes used the same localizations, so I removed the redundant copies. The only exceptions are the localizations for zh-CN, zh-HK, and zh-TW, because those are in fact different. To account for that, zh-* locales are now special cased in the code.

For all other language code/region code combinations, these changes should result in less error-prone localization, as the region code isn't considered at all anymore.

Additionally, the user's preferred languages are now checked for valid language codes before falling back to the system language.

[sindresorhus]

Even if these are the same, I still think we should keep them since they're coming from the system and for consistency between localization strings, as some string might differ.

[SamusAranX]

I compared all these strings using a script to make sure they're 100% the same. In case the translation for various variants of English changes, they can be put back in just by adding them to the dictionary, but for now, there's no use in keeping them.

[sindresorhus]

This could be simplified to:

let preferredLocale = Locale.preferredLanguages
			.lazy
			.map { Locale(identifier: $0) }
			.first { $0.languageCode != nil }
			?? Locale.current

[SamusAranX]

The term "simplify" is very subjective in this context. 😄
I didn't do any performance comparisons, I just personally think my version is more readable.
Also, IIRC, locale.languageCode was never nil in my tests, so in the overwhelming majority of cases, the loop should stop after just one iteration anyway.

[sindresorhus]

Are you sure about that? What are you basing it on? It feels weird hard-coding this. From experience, assumptions about date, time, and localizations are usually wrong.

[SamusAranX]

This is based on comparing the dictionary's entries and checking which region code variants are actually different.
I admit it does feel weird to special case this, and I'd be happy to change it, but as long as Chinese is the only language where different region codes produce different translations for "Preferences", I'd prefer keeping it this way.

[sindresorhus]

There must be some better system APIs we can use that handles the resolution here so we don't have to hard-code it like this. Good enough for now I guess, but I would want to fix this properly in the future.

[sindresorhus]

Thanks :) 🙌