Language depends on where it is said (doh!), Therefore, language and language codes reflect this reality. zh is the basic language code, but since there are two main forms of it, zh_Hans and zh_Hant , but they are still language codes, not locales.
Location specific
To fully indicate which language is used in a particular place, the country code should still be a suffix, so make zh_Hans_HK and zh_Hant_HK for simplified and traditional Chinese, respectively, as in Hong Kong.
In fact, the reality is that many countries often require something more specific than a country code, but this is likely to lead to an exponential increase in the complexity and maintenance of databases such as CLDR, plus the support infrastructure for submitting it, such as IP extraction location information is not public or accurate enough.
Fixed text
Now, if the code is just to indicate which set of fixed lines to use in the user interface or even entire pages on the site, the country suffix is really not needed if there are no more than a few places where the language varies significantly (location information) to create a whole separate set of resources.
The larger the set of resources, the more likely it is that a language code based on the language version [in this context, only a language attribute, not a true locale, so you can call it what you like!] Will be required, but at least you need do this only if necessary.
Values on the fly
However, if you want to format specific variable values, such as dates, times, currencies and numbers, on the fly, the locales become important because all tools that support this functionality (for example, based on Unicode CLDR data) expect them. The language standard for them should be a separate parameter for the code for which a custom language created by its own language is set for use if you do not want to create a set of resources for each well-known language standard and support them ad nauseum!
Browser Language Tools
Please note that when specifying a language for a web page that can be edited, as in the input field, as well as spell checking in attributes or css enabled for the field, browser language tools will check the spelling field in accordance with this language.
Criteria
You should clearly understand what a set of resources provides, so consider:
- Fixed lines? Only in language.
- Formatting on the fly? Locale.
- Spellcheck in viewer? Locale.
- Entire pages / sub sites? Only the language, otherwise locale (as a language option) if significantly different content is required.
Table to minimize maintenance costs
I use a spreadsheet to store user interface strings, where each language code has a parent code, so the cell for its version of the string has a formula that gets its string from the parent. To create a custom string for this language and string, I just rewrite the cell formula with the exact text. This minimizes the amount of service resources. I run a macro at the end that generates a complete resource file for each language.