Internationalisation project notes

Hi @maikel, (and adding @blancnic, @RohanM and @pmackay to the discussion),

Following the discussion, we have different options:

  • include dynamically the locale in the view --> rarely used currently and only in headers
  • insert the right locale in the all.js.coffee file using ansible via ofn_deployment depending on the config
  • I have been investigating that. Coulb be possible using blockinfile module which is an extra in ANsible 2.0 (but requires upgrading Ansible)
  • The 3rd option that you suggested, using a variable in the all.js.coffee, is not allowed as far as I understand. There is no way to use a variable or a condition in the asset pipeline.

My personal choice would be thru Ansible as long as it is the uwual way to deploy.

Any thoughts ?

We are using Ansible to provision servers, but have a different method to deploy/upgrade. I think that the dynamic inclusion is the best option. Also because there will be countries that want multi language support. In that case the user will change the language and we need to load the locale dynamically or include all supported locales.

OK, I guess we are talking about a new feature : ability of the user to switch language.

Is this feature planned somewhere in the release plan, yet ?

I will investigate further with that option in mind and see if I can get somewhere. I’ll let you know.

The development notes of the internationlisation project had that in mind. But that feature was not included in the first round.

So, if we do internationalisation work and it is not too hard to keep it flexible for that feature, it would be good to go that way.

Yes, to be able to switch language within one instance is something that might be required soon… we were discussing that with Indian people recently, they have 24 languages I think :wink:

OK, it’s clear, I’ll have a look and see if I can’t propose something.

I have been looking into a way to dynamically change the UI language on the fly.

I can’t find a way to do that, due to the precompilation of assets. Since the libraries like moment.js and its localization files are"compiled", it is not possible to change “on the fly”. Even though we could “externalize” it and include it as a standard javascript, I don’t think it is the right way.

Moreover, there is something strange about locale files. If you change something into it, in environments where the assets are precompiled (staging and production), you need to change the .haml file (not touch, but a real change) to have the modification reflected in the UI after recompiling the assets.

I am not that familiar with Rails, but it seems to be a feature and, thus, it should prevent changing the language dynamicaly.

Any thoughts ?

pinging @RohanM, @maikel and @MyriamBoure.

My thoughts for the OFN localisation in Javascripts where that we can include the right translations on the fly. Each page would have a line like this:

<script src="/i18n/:chosen_locale.js"/>

The browser would load new locales and then cache them.

Regarding the precompilation. Rails tries to be smart and not recompile stuff that has been compiled already. Otherwise each deploy would take at least half an hour. But it doesn’t handle the pre-compiled locales well. I tried to solve that.

The file app/assets/javascripts/darkswarm/i18n.js.erb should tell Rails that the Javascript locale depends on the Ruby locale. But that doesn’t pick up changes in other locales. And there might be more cases. I’m not sure how the detection really works.

@maikel can you check if this is working as it should? If you look at the transifex branch the en.yml file contains around 1000 keys, same as in Transifex. But nb.yml and fr.yml contain around 600. Both Norwegian and French deployments don’t get translation updates (cf deployment channel on slack).

Is it me not understanding correclty or is something missing? I thought it should be enough to push the transifex branch to get the latest translations from Transifex.

Only 100% complete translations are committed. French and Norwegian are translated to 99%. There were a couple of mistakes in the translation file and I guess you didn’t translate them.

OK I understand. Do you think I need the 7 remaining strange strings from G#878 to make the Enterprise admin work? cf What's New? - v1.6 (160401)

If so should we roll back and wait for 1.7?

Is there a definitive javascript string translation method now? I’ve just been using some javascript in a view, so it’s easy to pass in the translation with: var mystring = "#{t('the.translation')}", but if the localised translation is missing (present in en.yml, but not en-GB.yml) the string returns as: <span class="translation_missing" title="translation missing: en-GB.admin.... which then breaks all the javascript on the page. :frowning:

I don’t know exactly now, but there is plenty of strings missing in transportation file on Transifex that are in language file of installation file.And even there in not all text strings are included.
This is one thing we have to fix! Basic also for multilanguage
Can we tap into translations of open projects like Mozilla/Libre office fundation?

Hi @JozeHladnik it might be worth adding these missing pieces as GitHub issues (if they aren’t already there) so that they can get picked up by developers and fixed. Let myself or @oeoeaio or @maikel know if you need any help with GitHub access :slight_smile:

There is. Look at https://github.com/openfoodfoundation/openfoodnetwork/blob/master/app/assets/javascripts/admin/bulk_product_update.js.coffee for examples using the t function. If the string is missing in you current locale, it will just return the key.

1 Like

I already have a list of files that need fixing. It is included in the quote for multi-lingual instances. The list “Files containing language” at the end of Multilingual instances. Now, I added it to this Github issue as well: https://github.com/openfoodfoundation/openfoodnetwork/issues/1095#issuecomment-265912956

Everybody is welcome to work on that. It’s not hard at all, just a bit boring.

@maikel I just wanted to conect this topic. . Is it possible to bulk upload strings? (As @maikel have overview of)
What about importing translation memory?
(I’m translating language file in OmegaT as it is more convenient).
On programing level: How much work is needed to make all strings to display in new language once translated.

Transifex allows the upload of files with translations for a chosen language. They overwrite the existing translations though. I don’t think it has an upload feature for the translation memory. But I would hope that the translations from an uploaded file would be added to the translation memory.

I’m not sure about the permission system in Transifex. Maybe you need to be a Project Maintainer to upload files. It makes sense since it is a destructive action (replace instead of add).

Would you like to send a translation file to me? We can also experiment with giving you more permissions on Transifex.

I will translate strings in OmegaT, check for changes in code it might
caught and than try to upload.
I turn to you if I encounter troubles.

napisala:

Maybe this will be to some help http://okapiframework.org/wiki/index.php?title=How_to_Translate_Transifex_Projects_with_OmegaT