Consider rename Chinese translations from zh-cn/zh-tw style to zh-Hans/zh-Hant about congo HOT 16 OPEN

Ok, I ran some tests and can confirm this does in fact interfere with how Hugo renders dates and times.

However, I want to propose that we should change zh-CN to zh-Hans-CN and zh-TW to zh-Hant-TW for better adaptability to fit customs in different regions.

In addition, we may want to add some documentation to hint to future translation contributors that they should use codes available in gohugoio/locales so we won't bump into the same issue again.

from congo.

I'm happy with the proposal to use zh_Hans, zh_Hans_CN, zh_Hant, zh_Hant_TW if that is the consensus here?

from congo.

Hi, sorry for not having cited the source.

Localization of datetime string (also currencies, etc) is done in this pkg https://github.com/gohugoio/locales , and language code for chinese is in zh-Hans/zh-Hant format.

#805 btw, in this pr, zh-han should be renamed to zh-hans to conform to the code used in gohugoio/locales

from congo.

I don't see this requirement has anything to do with the code.

I couldn't find anything on Hugo's docs that says localized date and time should use zh-Hans/zh-Hant, but my guess is that it's implemented deeper in Golang rather than Hugo.

Can you maybe cite your source for this information?

Anyway, I did find this snippet on Hugo's forum, which seems like what you're trying to achieve. Hope this helps.

from congo.

In addition, we may want to add some documentation to hint to future translation contributors that they should use codes available in gohugoio/locales so we won't bump into the same issue again.

True. This is really a common mistake because most websites use zh-cn as the de facto language code for Chinese(simplified) although w3c suggests zh-Hans (https://www.w3.org/International/articles/language-tags/ ). Plus there are also styles like zh-cmn (same for zh-Hans), and it is really a little messy here.

However, I want to propose that we should change zh-CN to zh-Hans-CN and zh-TW to zh-Hant-TW for better adaptability to fit customs in different regions.

As per my experience, zh-Hans (the simplified version of Chinese) is normally consistent among its usage regions (China Mainland, Macau and Singapore), there are slight differences for zh-Hant (traditional Chinese) between the Hong Kong dialect (which includes words and phrases in Cantonese) and the rest of its usage. Since current translations have only two of them, zh-Hans and zh-Hant naming should be enough because most language processors will fallback to these two and we can create regional translations when we have them.

from congo.

As per my experience, zh-Hans (the simplified version of Chinese) is normally consistent among its usage regions (China Mainland, Macau and Singapore), there are slight differences for zh-Hant (traditional Chinese) between the Hong Kong dialect (which includes words and phrases in Cantonese) and the rest of its usage. Since current translations have only two of them, zh-Hans and zh-Hant naming should be enough because most language processors will fallback to these two and we can create regional translations when we have them.

Hmm...that's different from my experience.

I cloned a copy of gohugoio/locales and dug into all zh languages and found them to have multiple differences in ways of formatting date, time, and currencies. Just to name a few examples:

As the author of zh-TW.yaml, I cannot speak for other regions using Traditional Chinese. In addition, I would suggest that they create their own translation to fit their needs.

In this case, I would say that we create four translations: zh_Hans, zh_Hans_CN, zh_Hant, zh_Hant_TW, and let the user choose their favorite.

from congo.

This is definitely a topic where I do not have relevant knowledge or experience to make a call on the best way forward. My only concern is that the codes chosen work with Hugo and don't cause any implementation issues but it seems like that is not a problem with this issue.

from congo.

In this case, I would say that we create four translations: zh_Hans, zh_Hans_CN, zh_Hant, zh_Hant_TW, and let the user choose their favorite.

@tomy0000000 Ofc, it would be best to have the separated. Since we currently have not authors for other dialects, we may put up a notice so that people using other dialects could use fallback ones.

from congo.

This is definitely a topic where I do not have relevant knowledge or experience to make a call on the best way forward. My only concern is that the codes chosen work with Hugo and don't cause any implementation issues but it seems like that is not a problem with this issue.

@jpanther Hi! As for the codes chosen, did you mean the formerly chosen ones (zh-TW, zh-CN)? It did work for most of the parts. But when translating using hugo's built-in i18n module (datetime functions, etc), zh-CN and zh-TW won't be recognized as valid languages (although these two should also be listed as a common practice) and it will fallback to EN, as shown above.

from congo.

I'm happy with the proposal to use zh_Hans, zh_Hans_CN, zh_Hant, zh_Hant_TW if that is the consensus here?

Sounds good to me, let me know if you need help with this.

from congo.