Translation issues

avantsys wrote on Monday, April 09, 2012:

During the localization process from English to Greek, we (me and my collaborator geovasilakos here) came across an issue that hampers our task. Namely, in lines 4713 to 4715 of the Google spreadsheet that contains the messages and notifications of the application, the application has the word “To:”. It uses this exact same message for the following purposes:

1. For signifying to which person (e.g. a patient) it is going to send a message or reminder.
2. For signifying the end of a certain time interval (e.g. From 17/05/2012 to 28/08/2012).

Unfortunately, in Greek this makes our task a lot more difficult, because our term that signifies the recipient of a message and/or reminder is “Προς” and it is entirely different from the term that signifies the end of a time interval (“Μέχρι” or “Ως”). What course of action do you recommend?

Also, we cannot locate anything regarding the Message and Reminder Center, so we are unable to localize this component. Any pointers and/or advice?

blankev wrote on Monday, April 09, 2012:

After long and extended information exchange with Brady, we did not came with an acceptable solution about two year ago, gie or take a year. We have the same porblem for the Dutch translation. It would be good to use different word in English. Can’t be hard to make a general change with Get…… etc in Linux, (most of the time it is this answer I received when I ask for a solution form B.;-). But I do not understand if it is difficult or not.

My solution was to use:

Μέχρι/Ως

Till the English wording is corrected.

In Dutch there were about three of the same words that have the same but different meaning.

Keep on sending mails to Brady till he collapses and find his Mailbox full with this translation issue……… hahaha, he is really busy with OpenEMR and should take some time of and do walking and spend some time with his family. But after that he could.

Pimm

sunsetsystems wrote on Monday, April 09, 2012:

My thought about that was to enhance the translation logic to accept an annotation syntax in the English text that is stripped from output, but serves to differentiate different meanings.  For example “To{interval}” and “To{destination}”.  I don’t think that would be very difficult.

Rod
www.sunsetsystems.com

avantsys wrote on Monday, April 09, 2012:

OK, we’re on it. We’ll implement it and we’ll upstream it when we’re done (and after we’ve tested it properly).

sunsetsystems wrote on Monday, April 09, 2012:

Awesome.  But you might wait to see if Brady likes the idea, LOL.

Rod
www.sunsetsystems.com

yehster wrote on Monday, April 09, 2012:

Just be careful in your implementation as currently, the translation logic puts a whole lot of burden from a performance standpoint since the functions are they called so frequently.  Or maybe while you are making the changes, you can improve the current logic.  The biggest issue is that the audit log functions are called when translations are done, which isn’t really necessary, but does affect performance.

sunsetsystems wrote on Monday, April 09, 2012:

Kevin I think audit logging is already skipped for translations.  See the comment “Avoid filling the audit log with trivial SELECT statements” in library/log.inc.  Of course quite a bit of PHP code is executed to that point, not sure if that is significant to performance.

Rod
www.sunsetsystems.com

yehster wrote on Monday, April 09, 2012:

The insert into the database isn’t the most significant portion of the time used in the audit log.  It’s that “quite a bit of PHP code” which has been executed to that point. 

blankev wrote on Monday, April 09, 2012:

Great solution if they show like this in the translation tables. If it is stripped in translation tables of the {….} how would be we able to find the correct place to use the correct translation.

Once decided on how to implement, I will try to find back my issues with an ugly solution, the earlier problems I discussed some years ago…

Pimm

yehster wrote on Monday, April 09, 2012:

I would suggest adding a “context” parameter to the xl function rather than adding it to the string to be translated.   Since the {…} info is relatively static, it would be bad from a performance standpoint to make the server parse/search for the {} delimiters every time it gets called when the programmer can do it once.

sunsetsystems wrote on Monday, April 09, 2012:

The markup, when present, would exist in lang_constants.constant_name.  My thought is that the only change required to the code would be stripping “{…}” from the displayed output if there is no translation defined for the string.  At that point the parsing could be done with a single preg_match() call.

Kevin, not sure exactly what you mean but remember strings to be translated can come from layout and list items, ACL group names, etc., not just xl() calls.

Rod
www.sunsetsystems.com

bradymiller wrote on Tuesday, April 10, 2012:

Hi,

Rod’s proposal should be fine (Pimm, note that the constants on the spreadsheet would contain the {…} descriptor elements). I think it would be best to simply wipe out anything (within all translations) within {…} in the xl() function, since will be difficult from stopping translators to include these elements in their translations. A possible way to go about this is:
1. Incorporate this mechanism into xl() function in library/translation.inc.php
2. Then start placing these new “constants” in the codebase
3. Then, when I do the the next constant addition run (was planning to do this soon, but will postpone it a bit), these new elements will get picked up (also, avantsys, note the ‘Message and Reminder’ stuff will also get picked up) and placed into the google docs spreadsheet (and translation engine).

Also, for a proposal to improve performance of translation and log engine, see this thread:
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/5181000

-brady
OpenEMR

blankev wrote on Tuesday, April 10, 2012:

Is there a need to make a comment in top row something like: No need to translate {…} , or doesn’t this make sense since it will be deleted during processing?

bradymiller wrote on Tuesday, April 10, 2012:

Hi Pimm,

When this gets incorporated, plan to place this information in the guidelines on the following wiki page:
http://www.open-emr.org/wiki/index.php/OpenEMR_Internationalization_Translator_Guide

And will describe it when include constants of this nature in the next translation release newsletter.

Despite educating the translators on this mechanism, I think it makes sense to also have the engine remove these embedded comments (the {…} ) just in case the guidelines are not followed.

-brady
OpenEMR

bradymiller wrote on Sunday, May 06, 2012:

Hi,

To keep this project moving, here is code that will support comments in both the constants and the translations in the following format:
{{<comment>}}

http://github.com/bradymiller/openemr/commit/450d90f8452cfdc665e68387e53690c0aa43cd12

thoughts?

-brady
OpenEMR

bradymiller wrote on Tuesday, May 08, 2012:

Hi,
Committed above code to sourceforge.
-brady
OpenEMR

sunsetsystems wrote on Thursday, May 10, 2012:

My last commit (patient list/finder feature) uses ‘to{{range}}’ to indicate the ending number in a range, which I assume is good for dates also.

What’s a good way to keep track of these, so developers can be aware as appropriate uses come up?

Rod
www.sunsetsystems.com

bradymiller wrote on Friday, May 11, 2012:

Hi,

Updated the developer translation wiki page with this feature:
http://www.open-emr.org/wiki/index.php/OpenEMR_Internationalization_Development_Guide

Note on that page it discusses commenting and links to this wiki page, where we can track the constants that contain comments:
http://www.open-emr.org/wiki/index.php/English_Constants_Descriptions#Constants_with_comments
(this is a nice place to work out which contants need comments and what to use; for example, I also place a to with the comment salutation to propose what to label the other To/to in those situations; so can ensure we agree on commented constants before we use them)

Additionally, it’s also very helpful to search through the list of current english constants when deciding on strings to use; and this (after the next update) will also show the constants with comments there:
http://github.com/openemr/openemr/blob/master/contrib/util/language_translations/currentConstants.txt

-brady
OpenEMR