Language support

drbowen wrote on Monday, October 17, 2005:

“I understand your points. I have not been through the whole system yet, but so far about 75 - 90% of the files in the directories I’ve been through have been changed. That means that nearly every file need changing in the same way as sql-ledger uses the same text-array for every single file in the system.” 

"But offcause for the single practitioner in the future it will only be needed to change the file lang.php in order to decide what language to use. "

"There are a few things to decide, that might be important for first of all the developers:"

"1) Using one large or many small files?
- I tend to think many small files are better. Especially since one in an easy way can add more modules and let the needed language-files come with the module in an easy way. "

Personally, I think the use of smaller files will speed up operation.  You may need to make you best judgment here.

"2) Using arrays or single variables. 
- I don’t know enough about php-coding to know if this makes any difference for memory-usage or speed. I must say that I am not sure that it even makes a difference using constants or variables in php. (In c-code it would be better to use constants since these steal less memory and makes faster programs but in an interpreted language like php I don’t know)  "

Constants are generally faster but are more difficult to maintain.  Arrays will require more memory but will be easier to maintain.  PHP has always been popular because of its ease of use.  Taking the easy way is the traditional PHP approach.  Again, this is likely going to be your preference. 

"3) Naming of the variables.
- So far I mostly have used simple naming in order to not get conflicts with existing variables and make fast programming. But the readability is more difficult using this naming. It might be worth working out a better naming but it will take more resources too. "

I suspect in the long run this area will not need much maintenance.  What I have down with my naming is to start all similar variables with a common prefix and then follow with an individual name.  In my bronchitis form all variables start with the name of the table that containes the bronchitis information, such as:

bronchitis_cough
bronchitis_murmur
etc.

Would there be any benefit to have a static table that has the name of the variables in one column and a fuller discription in a second column?

Sam Bowen

andres_paglayan wrote on Friday, October 21, 2005:

Hi,
I am testing Johan’s (many) changes,
I installed from his tarbal,
I am getting this at the calendar,
Warning: Config_File error: Could not open config file ‘modules/PostCalendar/pntemplates/default/config//lang.se’ in /var/www/e/openlang/interface/main/calendar/modules/PostCalendar/pnincludes/Smarty/Config_File.class.php on line 348
I don’t have such file in there, only
-rw-r–r--  1 www-data www-data 441 Mar  9  2005 default.conf
-rw-r–r--  1 www-data www-data   0 Mar  9  2005 index.html
-rw-r–r--  1 www-data www-data 915 Mar  9  2005 lang.eng
-rw-r–r--  1 www-data www-data 915 Aug 21 16:51 lang.sv
-rw-r–r--  1 www-data www-data  98 Mar  9  2005 navigation.conf
r
any clue?

sunsetsystems wrote on Friday, October 21, 2005:

There is no lang.se nor lang.sv in current OpenEMR.  I’ll bet a dollar that the name lang.sv is a mistake and that Johan meant it to be named lang.se instead.

– Rod (http://www.sunsetsystems.com/)

nahoj1976 wrote on Saturday, October 22, 2005:

Hi
I’m afraid this is one of the problems with multiple dependencies…

The language code for Sweden should be ‘se’ and this is what I add in the file lang.php

But there are quite a few peoples out there not using the right coding; sometimes they use ‘sv’ for swedish.

Smarty has one language-support (that is not used in openEMR). Then the calendar-function has another language-support. This one applies for the calendar on the year and month view. I think (if I remember it right) that this one defines sv as swedish. Finally we have the language-support I have been working with.

Those things I don’t think you should look too deeply into right now. The things I would like to get tested is the functioning in the english language. So please change the definition in the file …/includes/lang.php and change to $lang = “en” and test that not the things that work is damaged by the language additions.

When I am sure that the system still works for you then I can work more on the parts I have left this far.

Concerning the calendar I think Rob said that the month and year calendar is planned to be changed in order to get rid of the dependencies on smarty. The day this is achieved all parts are maintained the same way…

/Johan

andres_paglayan wrote on Wednesday, November 16, 2005:

Hi all,

Finally, and thanks to Johan push and great previous discussions, a very light and easy to implement multi language tool is ready to be plugged in OpenEMR. (~150 lines)

You will be able to add a whole new translation set with only two clicks.

My question before committing the module is where do you thing the xl( ) function should be better placed in order to be called once and be globally available (Rod?).

I’ll post the developers and users documentation here, and it’s included in the module too.

Johan, we well grant you (if we didn’t already) commit privileges so you can modify the code to fit the translation in.

Again, Thank you all for the great feed back which helped ending with an intelligent solution.

sunsetsystems wrote on Wednesday, November 16, 2005:

Andres, that sounds very cool.

The library directory seems to be where most of the included modules go.

– Rod
http://www.sunsetsystems.com/

andres_paglayan wrote on Wednesday, November 16, 2005:

Commited,

files touched are

globals.php
acl.inc
acl_setup.php
interface/language
usergroup/usergroup_navigation.php
database.sql
2_8_0-to-2_8_1_upgrade.sql

Johan,
the first step will be to install from CVS.
then replace the text with the function with the ‘e’ option when needed (see documentation below).
ie
replace: Hello
with: xl(‘Hello’)

Then load the constants (the part enclosed within  ‘’) and its english definition using the language tool.

When you have all constants in English click in the Swedish tag and add the Swedish translation.

At this point you’ll need to export the three tables lang_* so their content can be included in the database.sql for default installation with Swedish tranlation, I will translate to Spanish when you have the constants loaded.

And this is the documentation (also included within the module)

Multi Language Tool.

This module has very few components to care about.

The first one is the following lines you can find at globals.php

//Language Control Section (will add toggling)
//English:1, Swedish:2, Spanish:3, German:4,
define (LANGUAGE,1);

By changing the number, you change the default language.
At a click language toggling capabilities will be added in the future.

The second thing is the module itself.
By default we have English, Swedish, and Spanish loaded as languages.
But not all the translation is done yet.

The options are.
Add Language: You get a box to enter a new language.

Add Constant: You get a box to add a new string to be used in the translation function, this one should be used only if you know what you are doing, mostly, if you added some custom programming with new text output. The "constant" string can be literally what you want to say or a shorter reference to it.

Edit Definitions: English is used as the reference language, if you click the English label you’ll get a set of all constants and the English definitions at the side. If no definition is loaded yet for a given constant then a blank box is shown, by entering a definition and clicking “Load Definition” you save whatever changes you made.

If you click other label than English, you get a set of all constants, the English definition at the side, and an input box to enter/modify the definition in the selected language.

The translation is done by the xl() custom function.
Its semantics are very simple.

xl (string[,‘r’[,string prepend[,string append]])

Which with examples means:

xl (‘translate this’)

By default the function will return (after all, is a function) the translation.

First it uses the LANGUAGE constant defined to pick the translation.

Second it goes for the translation, if none is found, then the same string entered is used and returned as is.

The first optional and only argument is ‘e’ which stands for echo. Use it if you want the function to echo the translated result instead of returning it.

i.e.
xl (‘translate this’,‘e’)

But if you are already within another function, then you want the function to return something.

i.e.
echo (“this and”.xl (‘translate this’).“that too”);

The third and fourth optional arguments are strings to be prepend and appended respectively.

i.e.
xl (‘translate this’,‘e’,’<b>’,’</b>’);

will echo
<b>this translated</b>

If you want only something to be appended in the a return, then you must supply empty second and third arguments.

i.e.
xl (‘translate this’,’’,’’,’<br>’);
will echo
this translated<br>

Have fun!

andres_paglayan wrote on Wednesday, November 16, 2005:

And I forgot to mention,

When writing new code use the xl() function for output even if you are not loading definitions, it will simplify future translation.

drbowen wrote on Wednesday, November 16, 2005:

Hi Andres & Johan,

Thanks for the hard work!

How many languages does this allow OpenEMR to be used in?

Have you tested in:

Swedish?

Spanish?

Other?

Please let me know

andres_paglayan wrote on Wednesday, November 16, 2005:

It allows as many languages as you want,

On Administration, Languages, you first click on add languages, then you click in the new addded language and you get the full set of constants, their English translation, and a blank space to add the new language.

If upgrading and using gacl already, then you have to grant languages to admin using gacl interface.

I will add a "contribute language" button to let users send us the whole definition set when someone adds a new language.

The task Johan will face now is replacing the scripts’ flat English output by the function and loading the constants using the tool.

What I did was the frame to implement translations, so my guess is it will take same time to have it fully translated.

nahoj1976 wrote on Wednesday, November 16, 2005:

This looks great!
This function was more than I hoped for!

(And txs for your kind words… :-)  )
I’m not sure how to install from cvs in easiest way - I have mostly used tar balls.

And how to upload the changed files…

You could send me a personal note on how to, please.

Best regards,

/Johan

ajperezcrespo wrote on Monday, January 09, 2006:

What do you make of this?  This is after editing globals.php for spansh (after restarting nothing has changed) so I clicked on load defenitions and got this.
Warning: Invalid argument supplied for foreach() in /var/www/openemr/interface/language/lang_definition.php on line 9

Warning: Invalid argument supplied for foreach() in /var/www/openemr/interface/language/lang_definition.php on line 25

Thanks
Alfonso

andres_paglayan wrote on Tuesday, January 10, 2006:

Well, we are providing a framework to allow users enter their own translations, the multilanguage module has support for as many languages as you want.  before switching to Sapnish, you should go in the module and enter the language equivalents, so there is something to be show. We expect translations lists to come from the community.

drbowen wrote on Monday, August 07, 2006:

I am a bit fuzzy on how the translation system works.  If I understand correctly there a “language table” that holds a look up id for a particular phrase on any one page.  In the table, the record contains the ID of the phrase the ID for the language (1 English, 2 Swedish, 3 Spanish, 4 German, 5 Dutch, 6 Hebrew), and a corresponding phrase in the correct language.

I think this means will will end up with a table that contains (approximately) 6 languages x the number of phrases that need translating?

Is this more efficient than a table with more columns that contain the phrase ID and then one column each of English, Swedish, Spanish, German, Dutch, and Hebrew (ie a shorter wider table)?

My wife, brother-in-law and mother-in-law are all fluent in German.  I may be able assist with the German translation.

andres_paglayan wrote on Tuesday, August 08, 2006:

actually the data storage for the tranlation module is normalized,
there are three tables,
one for the constants, which are the original English phrases to be translated,
one for the languages
and another one for the translated results,
the information on how the module works is under
/interface/language/lang.info.html
if you need any technical assistance in how to get it translated to German, please email me privately and I will help,