The Translation system of the Public Lab codebase is a project with the aim to foster diversity and make site more genial and accessible to new and existing users. In this project, the strings or texts present in the infrastructure (i.e. codebase) of the project are translated into various languages by volunatary contributors.
Contributing to this project can seem a bit tedious and requires you to have a thorough knowledge about the various parts of code and their dependencies. I'll walk you through various parts and hopefully after this you can contribute to this project.
You can find language resource files stored as YAML files here. All the strings that are present in the translation project are stored in these files in the form of key value pairs. You can call these strings in view files using the key for each string. Each language has its own YAML file, named after the language's standard code - i.e. English is en.yml and German is de.yml
There is a custom Ruby helper function that we've created to simplify using translation strings in the codebase. You can find it here. This is one of the most important parts of the project. It basically returns the translation of the string if it is present, or else returns an HTML tag with the English translation of the string and a globe icon beside it which tells the translation team members that translation to this string is missing. Note that this globe icon prompt is a unique feature of our helper function and not a default behavior of the Ruby i18n gem.
As of #9826 and 09d8ed3, only every 3rd translation is requested, for a maximum of 10, so as not to create too many prompts across the site.
The function is designed in such a way that it presents two very similar experience to normal user and members of the translation team.
There is a corresponding JavaScript version of this function, however it is not as well documented at this time. It's documented at: http://i18njs.com/ and you can see it in action on this line of code:
plots2/app/assets/javascripts/dashboard.js
Line 139 in e646cfd
The translation function does not interfere with the normal user experience. It presents translated string if present or English translation if the translation is not available. There are no globe icons rendered for normal users and UI breaks do not occur for normal users. This is done to prevent anonymous contributions and prevent site-wide UI breaks due to translation function.
You can be a part of the translation team by following this wiki detailed wiki by @gauravano and @liz. The only difference in experience for members is the globe icons which can be seen at some places across the site. More about it here. There are breaks in the UI sometimes (especially if translations are used within complex HTML UI elements like menus, buttons, or forms) but most of them have been fixed. But as the code is constantly being updated by first-time contributors some breaks can be missed out. Feel free to raise an issue if you find one.
The function works on the i18n gem here and yaml file structure. Each yaml file is mapped with corresponding translation resource on the Transifex project. This function may be called from any of the .html.erb view files.
Here is how the call looks
<%= translation('yaml key to string',option,html parameter) %>See an example here.
There is one prerequisite to call translation function for a string, it should be present in the en.yml file else it won't work correctly. In most of the cases, function call only requires the YAML keys. You can read more about YAML keys here. I feel various calls that exist in the views files code are kind of self-explanatory.
This parameter helps deal with expection cases of translation function - sometimes globe icon cannot be correctly rendered in views in places like inside buttons and links. So to prevent UI break we add the html parameter as false in the translation function call. Here is a sample call
<%= translation('dashboard._header.community_research', {}, false) %>You can find calls like this in views that have translation function call in search bars and buttons.
Some improvements to this call can be reorganising the parameters to make it bit concise but it is tricky as lots of tests are written that follow the existing call structure, many function calls have this structure and also the gem has an inbuilt options parameter that can be passsed as an array of options or as a list of key value pairs, so for now, this call is simple to check and for now though a bit longer.
Moving on to the second part of the project. We use Transifex localisation platform to handle voluntary contributions and add them regualarly to the code-base.
We don't need to exclusively add new strings to the Transifex project. Adding it as a key-value pair in the en.yml file will do the trick. Transifex keeps track of the file and automatically imports new strings from GitHub at regular intervals. Managers and admins can also run a manual sync from the settings->integrations->Send to Github option, more about it here. Once imported you can find the string in the Transifex resource file. You can check by searching it in the translation search bar.
Here is where managers can trigger a pull request
Transifex bot automatically raises a PR when a language resource is 100% reviewed. Managers and admins can also trigger a manual sync by settings->integrations->Send to Github option, we can specify a threshold percentage and any language files having reviewed percentage above the threshold will be added and a PR will be raised by the Transifex bot. Alternatively, we can also directly download a yaml file for the translation resource from the transifex site. More about it here
Here is a sample pull request.
So now that you know all the aspects in this project, let's see how the entire project works.
Add new strings as a key value pair in the en.yml file.
Transifex automatically fetches new strings from en.yml file. Managers and admins can also run manual sync to add strings to Project.
Translation team members can add translations on the Transifex site. You can find a detailed wiki on how to do so here
Once the string is reviewed, it can be added back to the GitHub repo. The Transifex bot automatically raises a PR once language resource is 100% reviewed. Managers and admins can also trigger a manual sync, which you can do by opening an issue at the plots2 repository, specifying which language you're interested in.
Once the translation are added to repository and changes are published, you can view the Public Lab site in different language by selecting the language of your choice from the footer of the dashboard page.
Hope you find this document helpful. Please feel free to improve it and reach out to the community in case you are still confused.