ISO-639 Standard for Translation Files

tony199555

I was doing some translation for extensions, and someone say something about not working properly (not showing up when switch language). So I am curious what kind of name scheme we should use.

For example, for Simplified Chinese: zh_CN.yml instead of cn.yml

luceos

tony199555 it depends on the key in the translation extension I think. Haven't delved into the code to check it completely.

tony199555

luceos OK. I see. I guess use zh.yml for now. The problem is zh.yml will cover both zh_CN and zh_TW among other zh_* too. So I don't know how this would work at least there is a standard for developers to follow, IMHO.

tony199555

@Toby @jordanjay29 Not mean to bother you guys. But I was hoping I can have some answers that will directly address this issue. Is there any standard that you guys enforced? I do see that inside composer.json the code for English is en.

Thanks for the hard work guys.

jordanjay29

I'm mostly guessing here, but I took a look at Github to see how others formatted:

This one uses pr-BR to specify Brazilian Portuguese.

Here's a couple Chinese ones that use the format you'd prefer.

I also see straight zh but again, you may find that confusing. Go with zh_CN.

Ralkage

Sorry to bump this but I've come to a realization that this will become an issue in the future when distinguishing different variations of a language such as Chinese.

Here is the generic list of i18n codes:

https://www.science.co.il/language/Locale-codes.php

Should we standardize this when developing extensions and adding translations? I honestly think we should, but it's a very subjective topic.

What if a user wanted to create a translation file for Chinese - Singapore? They would essentially put "sg" but that just indicates that it's it's own language code and has no prefix to group it under the appropriate language code such as "zh".

ReFlar will test the possibilities of seeing if language code prefixes are supported and if not? Well, we can take it from there I guess but @tony199555 does bring up a good point.

Does Flarum support the PHP related identifiers for locale as explained briefly here or is it managed through a package in a different way?

See here and here for example usage and supported languages (officially).

I believe that translation files such as cn.yml should not be accepted due to it not being prefixed properly and following the ISO-639 standard. Having a prefix + - + language tag should be the appropriate usage especially with Chinese.

E.g. zh-cn