Translation with ng-i18next

[debuggingfuture]

with current translation files,

• there are multiple files for translation
• all languages are in same file

at front end we can model one "namespace" object per language

• use the same keys no matter which lang, easier to code
• allow lazy initialization, i.e. not necessary to load english file when we are using chinese

ng-i18next is a good choice which further

• auto-detect on which lang to use
• remembering lang preferences

Work

• [ ] setup i18next services @vincentlaucy
• [ ] merge into single object with human defined string overriding generated string
• [ ] change backend to generate new static files per language @hupili

[debuggingfuture]

instead of manually merging different objects into one, we can make use of i18next's namespace concept it will control which files to load, and which will take precedence.

For example we can have basics strings e.g. geocode generated in generated.json, which we assign the namespace 'generated_ns' Then we can put human-translated file human.json as namespace 'human_ns' , which will override the other if key is defined

we only need to specify key like 'geo.location.code.a' which will first search in human_ns , if miss then use string in generated_ns automatically

i18n.loadNamespaces(['human_ns','generated_ns'],function(){/* loaded */});

i18n.init({ fallbackNS:['generated_ns']});

i18next.setDefaultNamespace('human_ns')

[hupili]

@vincentlaucy Where can I find your FE code? I need to refer to the dir structure and dict structure you use. I made per-language dicts based on memory. Code is in 64fdf17ef11f98d19a16a16bdd67c7655506e3c8 and 3d56b9d and you can see the generated dicts here

[debuggingfuture]

Let me commit tmr night Le 10 févr. 2014 22:38, "HU, Pili" notifications@github.com a écrit :

@vincentlaucy https://github.com/vincentlaucy Where can I find your FE code? I need to refer to the dir structure and dict structure you use. I made per-language dicts based on memory. Code is in 64fdf17https://github.com/hxu/hk_census_explorer/commit/64fdf17ef11f98d19a16a16bdd67c7655506e3c8and you can see the generated dicts here http://137.189.97.90:5901/static/data/translation/index.html

Reply to this email directly or view it on GitHubhttps://github.com/hxu/hk_census_explorer/issues/23#issuecomment-34638000 .

[debuggingfuture]

oops sorry seems I committed twice and mess up are we on master now? please merge only 246c852

[hupili]

@vincentlaucy , it seems your two commits have already been merged to frontend. Can you verify whether the current frontend has the correct samples? Then we can start all from there.

[hxu]

Not sure if the merge in frontend is usable, as there were a few issues I noticed after pulling. I think I've fixed them, but not sure.

[hxu]

It seems that i18next is requesting en-US and en translations, but we only have the first, so there are a lot of 404s

[debuggingfuture]

This is one of the issue i face in another proj as well, not sure an option to disable the fallback lang name Le 12 févr. 2014 13:00, "hxu" notifications@github.com a écrit :

It seems that i18next is requesting en-US and en translations, but we only have the first, so there are a lot of 404s

[image: image]https://f.cloud.github.com/assets/38583/2145382/9722257e-93a2-11e3-8ca7-94110051dc30.png

Reply to this email directly or view it on GitHubhttps://github.com/hxu/hk_census_explorer/issues/23#issuecomment-34839117 .

[hupili]

I think it's OK to generate both versions in the backend, if needed.

[hxu]

Setting the option load: 'current' seems to have it only load en-US, but I'm not sure if that behaves correctly if no language is set. See docs for load, and this issue

[hxu]

Note that we probably need to config the serverPrefix, as we deploy to /hk_census_explorer subfolder on github pages. We won't be on github pages forever, so maybe this problem goes away when we get our own domain, but we'll likely still have other config issues later.

[debuggingfuture]

load: 'current' should be fine as I tested after removed the default lng: 'en-US' it seems only removing lng: 'en-US' in ng-i18next, will the query param works

[debuggingfuture]

I created branch translation for the actual localization work, @hupili you can try with generating geo codes name mapping etc into locale/en-US/generated_ns-translation.json

[hupili]

The dicts are put under locale/__lang__/generated_ns-translation.json. Test use is also included in #/browser.

@vincentlaucy It can not automatically fallback to generated_ns at my side. I changed the order of human_ns and generated_ns to test the generated_ns. Please help to solve the two namespaces issue.

[debuggingfuture]

what is translation_ns? you mean with original order human_ns ->fallback to generated_ns, the key menu.sample failed to be lookup?

[hupili]

It's a typo, I mean generated_ns. The comment is fixed.

You can check out the latest translation branch and the code diff I pointed to in previous comments. You will see what I mean. Basically, there is no effect on fallbackNS, so I put ns: 'generated_ns' directly to test the generated dict on application #/browser.

[hxu]

A bit of a digression, but I saw this package, angular-translate, on hacker news today. Not sure how this will compare to the current package that we are using, but it seems to have more stars and commits on Github than i18next.

[hxu]

I checked out angular-translate. It doesn't seem to have some of the features of i18next, such as automatic loading of namespaces and translations based on locale. Probably would take a bit more work to get that sorted out.

Also, I fixed the issue of the automatic fallback. You need to specify both namespaces in the ns and fallbackNS keys in the config. It now looks like this

   i18n.init({
      // lng: 'en-US', //removed to allow override by query string
      useCookie: false,
      useLocalStorage: false,
      detectLngQS: 'lang',
      fallbackLng: 'en-US',
      // Must have the ns key, even though we have the fallbackNS field, otherwise it doesn't properly load namespaces
      ns: {
        namespaces: ['generated_ns', 'human_ns'],
        defaultNs: 'human_ns'
      },
      // This line seems to cause double loading of namespace files if you use ng-i18next config block
      // But is required to have automatic fallback
      fallbackNS: ['human_ns', 'generated_ns'],
      load: 'current',
      resGetPath: translationPrefix + 'locale/__lng__/__ns__-translation.json',
      getAsync: false  // We'll block, since the translation files are pretty critical
    });

Another problem arose where having both ns and fallbackNS and configuring ng-i18next via the config block seemed to cause two requests to the server for the translation files. This doesn't happen if I call i18n.init() manually, which is what I ended up doing. As it turns out, this also means we no longer need the "hack" to load the second namespace.

I'm going to go ahead and merge this branch in directly, since it's been under review for some time.