Hi All
@xispa, I see a lot of Spanish translations coming in, are they referenced in the code by ID or actual Inglis string?
There are many of the original Tags and Descriptions that can be improved. Let me know soonest please.
I started a list earlier, will publish for others to add to. Then wanted to teach myself Git but Mike suggest i rather just hand that spreadsheet to a coder who could much quicker just search and replace.
Bests
l
English is the “default” langauge, so each english string acts as an ID for any given translation to other languages. Thus, If we change an english string in the code, then all the translations done for the replaced string are lost and the new string needs to be translated again.
Consequently, english strings in the code should be almost perfect from the very beginning
Well, another option you might consider is to translate directly the english .po file, so changing the underlying english strings from code will not be required.
Poedit is the recommended application, very easy to install (I guess ’ apt-get install poedit` would be enough) and use. Just search for the strings you feel are wrong and translate them.
Once you finish with the translation, just save the file, go here https://github.com/senaite/senaite.core/blob/master/bika/lims/locales/en/LC_MESSAGES/plone.po , press the “Edit” icon, paste the content of the new file, and a new Pull Request will automatically be created.
K. I’ll keep on collecting them and then proceed, if you don’t mind holding back with the Spanish for a week or so?
I find them very tough and coders don’t always come from a user perspective, often in a second language, and should not have to lose time, code rather;-)
I try to spell out the tags and descriptions literally in feature requests to counter that.
No worries, we have in mind to keep spanish translation up-to-date from now onwards, so if you replace an original string in english, we’ll deal with it for the next release.
By default the source string will double as the id, but that’s more useful as a crutch to get started. The same English string may have different translations based on context.
Eventually what the code should contain should be mnemonic ids (that can look like English), but English should be just another language.
By the way are you using https://pypi.python.org/pypi/i18ndude/ ?
Agree. Mnemonic ids will make translations easier. Specially to languages with significant differences with english in terms of structure and grammar. As you noted, while translating to romanic languages, we end up with problems because of the context quite often. Seems to me that English is less context-specific and less accurate than romanic languages regarding to the precision of verbal forms.
But well, this:
_("Found {0} results from {1}").format(num_results, num_total)
is easier to type than:
_("search_results_found_msg", default="Found ${results} results from ${total}", mapping={"results": num_results, "total": num_total})
Yes, of course we use i18ndude
Worth to say that in romanic languages we don’t use acronyms, and senaite has plenty of them! (e.g AR)
Update senaite.core.po by lemoene · Pull Request #918 · senaite/senaite.core · GitHub if i did it correctly
If I interpret the PR comments correctly, initial changes are required in the code itself?
If you can again provide a recipe @xispa, I can start with the most important first.
Context example before / after will be brill. Firstly, how to find the string, e.g. Folder that results will be saved
You have to look for the strings inside the code (not in locales) and replace. For example, the string “Folder that results will be saved” is located here: https://github.com/senaite/senaite.core/blob/master/bika/lims/content/instrument.py#L210
This is the main problem with the source language, these “source” strings are the “keys” used for translations to other languages, and the “source” language is displayed “as is”. Thus, if you change this string, all its translations will be lost. But, what to do? Little by little.
K. While we build it up, I might look at options to run the new .PO in our installations, I came across some more;-)
This post has a lot of visits and the answers here might generate confusion, especially about how to translate senaite.
Translations are now located at Transifex, so poedit is not required (and not recommeded) anymore. You can add your translations in Transifex repository without the need of installing or downlading anything: https://www.transifex.com/senaite/public
Thanks @xispa
For me (missing something) https://www.transifex.com/senaite/ enforces a logon and then 404s, i can browse the rest of the site
The OP is about improving the en original source texts though, it is going to be a hell of a maintenance job doing it in the code. I touched 100+ strings before stopping. Thoughts?
One workaround is to translate en to en_ZA say and use that, asking users to update their browser language setting accordingly.
Some differentiating l10n remains in the same region though, e.g. Batch to Project/Experiment/Workorder etc, in Health, Client and Doctor.
https://www.transifex.com/senaite/public/ should work, I edited my previous message accordingly.
Although more tedious, In my opinion is better to have those english strings correctly spelled in the source code rather than creating an en_ZA locale. The latter would work, but is not a long-term solution imo, cause the “default” language will still be en and therefore, translators will keep using the “wrong” version as the source.
My suggestion for en locale, would be to keep fixing those strings into the source code little by little (say ~10-20 max strings for each 4w release), so contributors would have enough time to fix the gaps at their own pace. Re the translation you did previously (for which you created a PR), I would merge it into master for 1.3.x series.
Is going to be a timeous initial task, needed sooner for the UI to match the pro backend. Most i can promise is a few of the better ones at the first opportunity
Smaller improvements and maintenance in the code will be easier