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?
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.
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.
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.
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.
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.
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…
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.
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’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).
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?
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.
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)