CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site
This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Discussion »
  • Internationalization and Localization (Moderators: Michał Mach, mathieu) »
  • Migrating translation to 2.2
Pages: [1]

Author Topic: Migrating translation to 2.2  (Read 5104 times)

sawjer

  • Guest
Migrating translation to 2.2
December 19, 2008, 10:28:50 pm
I am working hard to finish 2.1 translation (to German) before 2.2 comes out.

Handle obsolete strings
Changed strings in English will show up on pootle as not translated. What about strings, that are not used any more? Is there an automatic removal of out-of-use strings?

Consider Webmasters
Webmaster will (in my opinion) always prefer to use native English when it comes to configuring or managing CiviCRM.  Is there an easy way to recognise such texts (and just put English as the translated string)? This could lighten the burden of translation.

Improve Translation accuracy
The present pootle solution is a clear help of managing translations. However insuring good quality is difficult as the translator has difficulty to see the text in context. Would it be possible to have a setup where the result of translation in pootle can immediately be seen in a local test environment? That means you could have a test setup with three windows, one running English, one running target lanugage (e.g. German), one running pootle translation.
« Last Edit: December 19, 2008, 10:56:26 pm by sawjer »

Piotr Szotkowski

  • I live on this forum
  • *****
  • Posts: 1497
  • Karma: 57
Re: Migrating translation to 2.2
December 22, 2008, 08:29:59 am
Quote from: sawjer on December 19, 2008, 10:28:50 pm
I am working hard to finish 2.1 translation (to German) before 2.2 comes out.

Thanks! It’s much appreciated!

On my side, I found a better way to migrate strings translated for old versions after we branched for a new version, so there was a large translation update for most (if not all) languages lately.

I just thought of a way to salvage strings from even older releases; I’ll do that in the coming days. Of course, in the case when a given string was translated differently for two releases, the newer translation will prevail (so no 2.1 work will get overwritten).

Quote from: sawjer on December 19, 2008, 10:28:50 pm
Handle obsolete strings
Changed strings in English will show up on pootle as not translated. What about strings, that are not used any more? Is there an automatic removal of out-of-use strings?

Yes. The POT/PO files get regenerated for every release, and old strings get removed. For stuff like country and province lists, where the translations are ‘stricter’, I simply do remove them; for other, they can be left in the PO files as commented with #~ – this way gettext can reuse them if a given string ever comes back (and use them for the base for fuzzy translations).

Quote from: sawjer on December 19, 2008, 10:28:50 pm
Consider Webmasters
Webmaster will (in my opinion) always prefer to use native English when it comes to configuring or managing CiviCRM.  Is there an easy way to recognise such texts (and just put English as the translated string)? This could lighten the burden of translation.

I wish this was true – but way too often CiviCRM is installed by webmasters that aren’t fluent in Enligh and they prefer to have the admin screens localised as well. These webmasters don’t show on this forum for obvious reasons… :|

Note that in a multi-language environment, the chosen language is associated with the user, so if the webmaster chooses to use English, they’ll get English CiviCRM every time they come back.

Quote from: sawjer on December 19, 2008, 10:28:50 pm
Improve Translation accuracy
The present pootle solution is a clear help of managing translations. However insuring good quality is difficult as the translator has difficulty to see the text in context. Would it be possible to have a setup where the result of translation in pootle can immediately be seen in a local test environment? That means you could have a test setup with three windows, one running English, one running target lanugage (e.g. German), one running pootle translation.

This is a very good idea; we’ll think about it. Another choice would be a JavaScript translation layer that would allow one to simply translate strings inside CiviCRM; we’ll think about that as well.

Thanks a lot for your interest and great suggestions!
If you found the above helpful, please consider helping us in return – you can even steer CiviCRM’s future and help us extend CiviCRM in ways useful to you.

sawjer

  • Guest
Re: Migrating translation to 2.2
February 05, 2009, 03:04:14 pm
Hallo Pjotr

I seem to be the only one who has translation problems? I have reflected on it for a long time. On my professional work I constantly work in a multilingual environment and I have not run aginst such a problem. That make me think, perhaps a different approach could be the solution. I am aware, that most of the people seem to be happy with the situation, so either they are using English or have a finished translation available. Still I like to propose a different structuring that is in my experience easier to handle:

1) Divide the language texts in three parts:
- Form Field Names (short, small number of strings, pootle is a sufficient tool)
- Syntax eplanation for each form field, grouped into one popup help text for each field set. This will explain the syntax, the possible range of values to enter, but will not explain why or to what purpose (can be done in pootle, there is a limited set of field sets alltogether, a sting will explain all form fields of a field set)
- Wiki style online help, a tree for each language. This is a lengthy online help and tutorial that will not work with gettext but be created as a complete wiki tree for a particular language. From each page within civicrm there is one button to call a particular page that explains the purpose and reasons for the values to enter. The wik navigation will allow the user to browse the whole online help/tutorial,  if the presented page does not answer the questions.

2)Quicker to translate, better quality
The largest part of texts are in the online help/tutorial. Translating whole texts is easier than doing fragments without knowing the respective context.
The online help in the users language does not exist at the moment, I would have to create one on top of the current unfinished translation. The explanatory text that is interspersed in the forms, according to my experience not really answering the questions I had, could be eliminated. The online help/tutorial would be a more helpful replacement.

3) A benefit for all
This structure would make the forms lean and easier for the user. Civicrm has to be useable by the average user.  An improvement in this respect would be very welcome.

4) I would be willing to help in coding. I have productive systems running that can be visited as demonstration of the principle. Is anybody interested in joining in?

Piotr Szotkowski

  • I live on this forum
  • *****
  • Posts: 1497
  • Karma: 57
Re: Migrating translation to 2.2
February 06, 2009, 03:02:53 am
Quote from: sawjer on February 05, 2009, 03:04:14 pm
1) Divide the language texts in three parts:
- Form Field Names (short, small number of strings, pootle is a sufficient tool)
- Syntax explanation for each form field, grouped into one popup help text for each field set. This will explain the syntax, the possible range of values to enter, but will not explain why or to what purpose (can be done in pootle, there is a limited set of field sets alltogether, a sting will explain all form fields of a field set)
- Wiki style online help, a tree for each language. This is a lengthy online help and tutorial that will not work with gettext but be created as a complete wiki tree for a particular language. From each page within civicrm there is one button to call a particular page that explains the purpose and reasons for the values to enter. The wik navigation will allow the user to browse the whole online help/tutorial,  if the presented page does not answer the questions.

I like the idea of spliting form field names from the longer in-UI strings; we tried to go that way when splitting into civicrm-core.po, civicrm-modules.po and civicrm-helpfiles.po, but your approach would be even more usable. I’m not yet sure how to code this so that the string extractor (which scans the PHP files for ts() function calls and the Smarty templates for {ts} blocks) would handle this (the current core/modules/helpfiles split is done based on directory layout), but maybe passing some params when ts-tagging the strings could accomplish that…

Quote
2)Quicker to translate, better quality
The largest part of texts are in the online help/tutorial. Translating whole texts is easier than doing fragments without knowing the respective context.
The online help in the users language does not exist at the moment, I would have to create one on top of the current unfinished translation. The explanatory text that is interspersed in the forms, according to my experience not really answering the questions I had, could be eliminated. The online help/tutorial would be a more helpful replacement.

3) A benefit for all
This structure would make the forms lean and easier for the user. Civicrm has to be useable by the average user.  An improvement in this respect would be very welcome.

These are also valid points. I got an email from Christian Sager with his thought much along this way, and hope to see his reply to my reply soon; I’ll spin a general UI discussion addressing these as soon as I have all the arguments in my hand.

I’m redoing some of the l10n stuff in the next week (moving to a separate repository, using newer Pootle with Subversion support, etc.), and I’ll think about all this in the meantime to see how to best fix all this for CiviCRM 2.3.
If you found the above helpful, please consider helping us in return – you can even steer CiviCRM’s future and help us extend CiviCRM in ways useful to you.

sawjer

  • Guest
Re: Migrating translation to 2.2
February 09, 2009, 10:53:07 am
Just a clarification of my proposed change:

As the context help (per fieldset) is just a call to a procedure to popup a window with a help text reference, the scanning for [ts] should be no problem at all.  The question remains how to create automatically the link to the text. In the same line of thinking this could be done by scanning those calls.

Perhaps we should consider to store the translation in the db. The drawback: slow, the advantage, easy to change a text that does not fit. At the moment it is a lengthy process to get the wrong translation corrected (at least a week). And because it takes long, you loose oversight. It should not be difficult to move to an index file, once it is stable.

My main concern is to get a stable situation. With standalone I am neither with the translation nor with the reliability of the code at that point.

Piotr Szotkowski

  • I live on this forum
  • *****
  • Posts: 1497
  • Karma: 57
Re: Migrating translation to 2.2
February 10, 2009, 04:16:57 am
Quote from: sawjer on February 09, 2009, 10:53:07 am
Perhaps we should consider to store the translation in the db. The drawback: slow, the advantage, easy to change a text that does not fit.

I thought about this extensively. The main drawback would be to create a sane mechanism for caching the strings in the memory (so not to do database round-trips for every string we display). Currently, the CRM_Core_I18n class creates a singleton that keeps the proper civicrm.mo file in the memory for fast seeks, and we would have to somehow mirror this approach – which is doable, but non-trivial.

I’ll definitely keep this on my list of things to consider for 2.3. :)
If you found the above helpful, please consider helping us in return – you can even steer CiviCRM’s future and help us extend CiviCRM in ways useful to you.

sawjer

  • Guest
Re: Migrating translation to 2.2
February 13, 2009, 10:02:42 am
I understand the concerns and changes involved.
 Would it be possible without too much effort to create the .mo from a database table. My main reason for advocating a database is the ability to change it on the spot and see the results. In the present solution I need to change it in pootle and then wait for a week (or do the conversion to .mo myself).
This is lengthy. I am shure, beeing able to translate it quicker would help the adoption in other languages. At present, I am at 50% translation (German). A user who is not fluent in English will not understand many texts.

Piotr Szotkowski

  • I live on this forum
  • *****
  • Posts: 1497
  • Karma: 57
Re: Migrating translation to 2.2
February 16, 2009, 03:22:34 am
Quote from: sawjer on February 13, 2009, 10:02:42 am
Would it be possible without too much effort to create the .mo from a database table. My main reason for advocating a database is the ability to change it on the spot and see the results. In the present solution I need to change it in pootle and then wait for a week (or do the conversion to .mo myself).

Bad news: We can’t move to a database-backed solution for CiviCRM 2.2 (as its in beta right now), but I’ll think about this for CiviCRM 2.3.

Good news: I’m working on a new l10n workflow for translations.civicrm.org this and next week, and this will be a solution for CiviCRM 2.2. This will include a new Pootle version and some solution that will generate the MO files much more often. I’m not yet sure how often, but the idea is to either have it more-or-less instant (i.e., after every string change) or to enable the translator to trigger this as their leisure (so you can translate five strings, rebuild the MO file with a click and have the demo reflect these changes instantly.
If you found the above helpful, please consider helping us in return – you can even steer CiviCRM’s future and help us extend CiviCRM in ways useful to you.

sawjer

  • Guest
Re: Migrating translation to 2.2
February 17, 2009, 07:21:40 am
Pjotr, that sound great ;D

All my civicrm English language users cannot imagine the frustration I have, because my users laugh at me because of the the terrible English/German muddle in the texts.

Your provisions should adress a large part of my trouble.

Thanks for the effort

sawjer

  • Guest
Re: Migrating translation to 2.2
February 24, 2009, 04:23:54 am
Quote from: Piotr Szotkowski on February 16, 2009, 03:22:34 am
Quote from: sawjer on February 13, 2009, 10:02:42 am
Would it be possible without too much effort to create the .mo from a database table. My main reason for advocating a database is the ability to change it on the spot and see the results. In the present solution I need to change it in pootle and then wait for a week (or do the conversion to .mo myself).

Bad news: We can’t move to a database-backed solution for CiviCRM 2.2 (as its in beta right now), but I’ll think about this for CiviCRM 2.3.

Good news: I’m working on a new l10n workflow for translations.civicrm.org this and next week, and this will be a solution for CiviCRM 2.2. This will include a new Pootle version and some solution that will generate the MO files much more often. I’m not yet sure how often, but the idea is to either have it more-or-less instant (i.e., after every string change) or to enable the translator to trigger this as their leisure (so you can translate five strings, rebuild the MO file with a click and have the demo reflect these changes instantly.

Hallo Piotr

I am getting ready to implement the changes I have proposed. Could you give me some startup help so the coding effort fits with the general procedures and can be merged into 2.3.
I am working with trunk version.

On top, how do I get an account to update language texts directly to subversion? I am currently updating the de_DE texts for v2.2 .

I have been trying to adjust the language files for v2.2. I notice, from v2.1 to v2.2 a large amount of fuzzy translations more than in v2.1 . This seems to indicate, that all effort of translation to v.2.1 is again lost in v2.2 . This is a very unfortunate development: I do not seem to advance in translating at all!
Can we discuss this on IRC?

I see also on your post to xavier that po files are now in svn.civicrm.org/l10n . Which of the de_DE files do I continue now? I have already translated a lot of texts imported from the trunk. Which is newer?

I have difficulties to get the .po files converted to the .mo file. I do not seem to understand msgmerge and msgfmt syntax properly

I am glad for help
« Last Edit: February 25, 2009, 12:22:07 am by sawjer »

Piotr Szotkowski

  • I live on this forum
  • *****
  • Posts: 1497
  • Karma: 57
Re: Migrating translation to 2.2
February 25, 2009, 02:29:46 am
Quote from: sawjer on February 24, 2009, 04:23:54 am
I am getting ready to implement the changes I have proposed. Could you give me some startup help so the coding effort fits with the general procedures and can be merged into 2.3.
I am working with trunk version.

On top, how do I get an account to update language texts directly to subversion? I am currently updating the de_DE texts for v2.2.

I have been trying to adjust the language files for v2.2. I notice, from v2.1 to v2.2 a large amount of fuzzy translations more than in v2.1 . This seems to indicate, that all effort of translation to v.2.1 is again lost in v2.2 . This is a very unfortunate development: I do not seem to advance in translating at all!
Can we discuss this on IRC?

I’m working on the 2.2 PO files yesterday and today, so they’re not yet complete. I’ll be on IRC today till 3 pm (CET) if you want to chat – ping me (Chastell) there and we’ll work an account for you.

Quote
I see also on your post to xavier that po files are now in svn.civicrm.org/l10n . Which of the de_DE files do I continue now? I have already translated a lot of texts imported from the trunk. Which is newer?

The never version should always have all the translations from previous versions that are still relevant.

Quote
I have difficulties to get the .po files converted to the .mo file. I do not seem to understand msgmerge and msgfmt syntax properly

Let’s figure this out on IRC.
If you found the above helpful, please consider helping us in return – you can even steer CiviCRM’s future and help us extend CiviCRM in ways useful to you.
Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Discussion »
  • Internationalization and Localization (Moderators: Michał Mach, mathieu) »
  • Migrating translation to 2.2

This forum was archived on 2017-11-26.