Name of the database for translations

Management and Administration
1

fbll wrote on Friday, June 27, 2008:

Hi community, I am newby using OpenEMR. In fact I am just testing it.
As my colleagues do not speak english I would like to translate OpenEMR to Spanish during this summer hollidays.
It is one of my projects for this summer and I am decided to do that.

The question is that I am going to do the job at home in my private PC. When I finish the traslation,
- Is it possible to put it in other computer?
- What are the files I have to modify?
- Is the medical database the same as the translation one?

I’ve never worked with PHP nor MySQL, but I have some experience with other programming languages.

Your comments will be appreciated. Regards from Spanish Mediterranean.

2

drbowen wrote on Thursday, July 03, 2008:

There are three tables that are concerned:
________________________

lang_constants

Defines a small number of English language constants.  This table currently contains 56 terms that are mostly demographic oriented.
________________________

lang_definitions

This table actually holds the terms that you are looking for and currently holds 173 terms.
________________________

lang_languages

This is a table that assigns a code for each language.  Spanish (es) is number 3.
________________________

Very likely you will only need to add terms to "lang_definitions".

Some of the forms predate the multi-language capability and have not yet been convrted to the xl() format required to allow the translation to take place.  This is somewhat time consuming but relatively easy to fix.  Each time a term that is displayed in the browser such as a text label for for a text box the term needs to have a small amount of xml code added.

A line of code such as:

<span class="text" >How did Injury Occur?:</span><br>

which is the label to a text box would need to be modified to:

<span class=‘bold’><?php xl(‘How did Injury Occur?’,‘e’); ?>: </span>

Then a Spanish translation is inserted into the "lang_definitions" table and the translation should occur.

Sincerely,

Sam Bowen, MD

3

fbll wrote on Monday, July 21, 2008:

Hi Sam,
I am a bit confussed because while begining to translate to Spanish:
  - In the OpenEMR soft -> Admin -> Language -> Spanish, I can see some very strange translations that have nothing to do between them (e.g. "(New Patient)" is traslated as "Solamente para uso de  Correo Electronico a pacientes" instead of "Nuevo Paciente" or "? No show" is traslated as "Cancelar" (Caneclar means "Cancel")) Maybe they are made just as an example or I do not understand something.

  - I opened the table lang_definitions and I can see just the items in Spanish language (3), but not in the original language, then it is a bit difficult to translate.

Please, I am a bit lost about how to translate.

By the other hand I would like to make you some observations about the xl() function.

You indicate that the xl function works like:
<span class=‘bold’><?php xl(‘How did Injury Occur?’,‘e’); ?>: </span>

The parameter in xl() function is a sentence. When I used to program commercial software in different languajes, my programmer’s chief recomend us make a funtion like xl(), but instead of workin with a sentence parameter, the parameter was an integer number.

Using an integer parameter is quicker and simplier, because the search engine has to search just a number instead of a sentence, and also is more easy to translate.

Regards,

Francisco Blasco

4

blankev wrote on Monday, July 21, 2008:

It is somewhat confusing, since I just solved the problem for the Dutch translation, here is my advise:

Go to OpenEMR folders of your installation.

go to the subfolder SQL and find the file:

database.SQL

Start browsing and import the part you wish to change in your OpenEMR (1) tables and than INSERT in the (2)fields.

There is an extensive part of Spanish translations somewhere scrolling down. First update the tables (necessary for Dutch translation, I don’t know about Spanish translation) use the copy past in the SQL window of OpenEMR (QUERY WINDOW)and click on “go”. It worked for me in windows version.

Good luck if needed!

Pimm Blankevoort

5

blankev wrote on Monday, July 21, 2008:

But exploring the Spanish translations I must admit that there is discrepancy between the English id numbers and the second field number in the translated file.

INSERT INTO `lang_constants` VALUES (39, ‘Faxes In’);    (English)

INSERT INTO `lang_constants` VALUES (209, 39, 5, ‘Fax ontvangen’),     …(Fax received)…(Dutch)

INSERT INTO `lang_definitions` VALUES (34, 39, 3, ‘Cita(s) del Paciente’);

OR the following:

Spanish: INSERT INTO `lang_definitions` VALUES (143, 149, 3, ‘Activos’);

English: INSERT INTO `lang_constants` VALUES (149, ‘duration’);

Dutch:(914, 149, 5, ‘duur’),

6

blankev wrote on Monday, July 21, 2008:

The Dutch translations (if interested)can be found in OpenEPR files in CSV database on the net. They start at 174 so these are inserted after Spanish translations that go till (173,xx,3, TRANSLATION OF SENTENCE). Under SQL subdirectory in CSV files.

Pimm

7

drbowen wrote on Tuesday, July 29, 2008:

Dear Francisco:

I am not sure about the differences in the Spanish translations, but I know the existing translations were done by Andres Paglayan (from Columbia) and Alfonso Perez (from Puerto Rico).  One of the things they wanted the Spanish speakers to do is to agree on which Spanish was going to be used.  They recommended using "Standard Spanish" such as what is used on "CNN" instead of a local dialect.

I hate to sound ignorant on the Spanish but I know there a lot of dialects and tremendous variation around the world.  So many of the Spanish speaking countries have their own way of doing things.  I think I remember you saying that you were in the Mediterranean?   What type of Spanish do you speak?

I agree about using the numbers to search the terms (though I am not a programmer) and then translation the number.  It seems to me that the Dutch has already been fixed with number in the way you are asking.   There is an extensive dutch translation with a lot of English "constants".  It may be better for me to import these English "constants" and then add the Spanish as you have suggested.

It will be easier for me if you do a mysql dump of the table.

Sam Bowen, MD

8

meanmicio wrote on Saturday, September 06, 2008:

Dear all :

I’m also working on the translation of OEMR for Spanish. Here are some thoughts that I’d like to share:

** 1) Have a master language ( in this case English )

We should have to have in each record ( both at DB level as in the csv file )

- name of the object / field , english term, spanish (or target language) term.

OEMR should have the possibility of exporting the language table into a csv - encoded file, so we can edit it.

We also should have the way of importing the specific language from the csv file (either from console/OS or from the the admin menu).

We must be very careful with assigning codes to the systems. Different DBs can assign different numbers. What I believe Francisco means is the object/field code. This can be numeric or text. I like when we include the object/field, since it’s very useful for contextual translations.

This will make the language table smaller, since only English will be initially loaded. Then, we can import as many extra languages as we wish, but it will be optional.

** 2) Create a directory i18n with the different translation files, with the ISO code for each language / country :

For example :

– es_AR : Spanish for Argentina (es: Spanish language ISO code . AR: Argentina country ISO code ).
– es_ES : Spanish for Spain
– en_US : English for USA
– en_GB : English for Britain

This will allow us to use as many language variants as we wish.

Sam, regarding having a single language flavor, "plain" Spanish is hard. Spanish from Argentina varies significantly from Spanish from Spain. The system should be localized to the specific country. This method should take care of it.
Of course, there are a lot of expressions that are the same among dialects, so if someone wants to start a new language variant, he can take one of the csv files as a model, and just change the terms that differ.

** 3) UTF-8 encoding: Most linux system are UTF today. Please check the environment variable LANG. If you use another Operating System, make sure that when saving the file you choose the option Unicode or UTF-8. That should take care of the problem. There is a great little utility called iconv that will convert from different encodings to UTF.

** 4) Language should be chosen at login time
This makes the system much more flexible. The default language can be a property of the user, so if she/he does not choose one, he’ll login with the language by default.

At this point, I’m translating OEMR to Spanish from (from scratch) using the translation utility from the 2.9 version. So far it’s saving the terms OK, except the ones that contains double or single quotes. These might have to be escaped \ .

Let me know your thoughts and suggestions

Best regards
Luis Falcon

9

jimmietwodogs wrote on Monday, September 15, 2008:

Luis:
My name is James Town and I am a retired G.P trying to establish a medical mission in Bolivia, South America.

My interest is to obtain a medical records programme that will allow me to document the visits of patients to the clinics, which are mobile units, including a photo of the particular patient.

This is to prevent over-use problems and to keep track of inventory since I will not be able to be present for most of the time.

I wish to prevent theft/black marketeering and abuse of the service.

I plan to have each member of a three-team unit supplied with a computer, networked to each other.

The data, once completed in the field, will then be transferred to a base computer from which I can access data.

The system will need to be bi-lingual, since I understand little Spanish and the Bolivians understand less English.

There will be no need to have any billing software included.

Since this is a Christian charity, I would like to be able to follow church and school/education activities and our success with instituting a safe water programme as well.

I hope that you will be able to assist me in this endeavour.

Thanks,

Jim

10

drbowen wrote on Wednesday, September 17, 2008:

In general I agree with your thoughts.

We should have to have in each record (both at DB level as in the csv file )

- name of the object / field , english term, spanish (or target language) term

I would prefer, if possible, to also include a column with the path to the file to make it easier for others to translate other languages.  So what I would like to see would be:

Path to the file,  field name in the file, language name, english term or phrase, translation

For me it would be more intuitive for non programmers to be able to help with these translations.  I am a non-programmer but I have access to German, Russian, French, Romanian, Ukrainian and probably others in my community.  Currently, the translation process is sopmewhat arcane and difficult to figure out. 

Also, we already had a Swedish translation but it got lost in one of the upgrades.  Having individual CSV files will help insure against this loss.

Current structure:

lang_languages=(lang_id, lang_code, lang_description)

lang_definitions=(cons_id, constant_name)

The constant_name is the english term

****
OEMR should have the possibility of exporting the language table into a csv - encoded file, so we can edit it.
****

oemr already has this capability in the MyPHPAdmin.  This can export CSV values that are in Excel spreadsheet format.

We also should have the way of importing the specific language from the csv file (either from console/OS or from the the admin menu).

I should not be too hard to write a script that can be executed from the "admin" area to import CSV files.

****
This will make the language table smaller, since only English will be initially loaded. Then, we can import as many extra languages as we wish, but it will be optional.

2) Create a directory i18n with the different translation files, with the ISO code for each language / country :*****

Agreed.  This would be my preference but some of the other developers have insisted that we not worry about this.

****
Sam, regarding having a single language flavor, "plain" Spanish is hard. Spanish from Argentina varies significantly from Spanish from Spain. The system should be localized to the specific country. This method should take care of it. *****

I know there is no "plain Spanish".  My reference was to "Standard Spanish" such as that used on CNN.  Most Spanish speakers understand this even if it is not there usual dialect.

If it is easier to have country specific Spanish dialects I am all for it.

Sam Bowen, MD

11

Ask me anything about Spanish translation… I am updating it…
I am for a single variant, international Spanish for everyone…
Sergio