Language definition

blankev wrote on Thursday, March 19, 2009:

Using a virgin OpenEMR 3.0.0 and a flawless installation you professionals solved the CAMOS problem within a few hours. Tanks.

Than I wanted to start the Spanish and Dutch translation section, since English, Spanish and Dutch are all three languages I try to use during my patient contacts, but not as in former installs of 2.8XX and 2.9XX there are NO DEFINITIONS at all to be found through the admin choice of Langauge.

1.  Is there an easy solution or should I dive in CVS as proposed for CAMOS

2. Or should I just use the language directory / istallation untar options etc. of an older version?

Or could something simple as might help me to find the Language definitions back?:

===============================
Actually,
  An even simpler way is to just copy your old gacl.ini.php and
gacl.class.php
files to your new installation.
-brady
=============================  TNX, Pimm

cfapress wrote on Thursday, March 19, 2009:

I haven’t tried a different language in OpenEMR, as we just use English. But I am familiar with the source code. I can tell you that much of what you see on the web pages contains language hard-coded into the software. To make OpenEMR truly multilingual would be a large task to be taken on, one source code file at a time.

Also, if you’re looking at the Language tool in the Admin section of OpenEMR you will see that even in English there are duplicate entries. For example, the phrase ‘(New Patient)’ is defined twice. Why? Can one be removed? How?

Really expanding the multilingual feature of OpenEMR is a big task for somebody to take on, and then maintain.

Jason

bradymiller wrote on Thursday, March 19, 2009:

hey,
 
   Actually, everything has been removed both the lang_constants and lang_definitions sql tables, as of 12/17/08, from the database.sql script(used for installation of sql database) for reason “removed all language constants and definitions as they were mismatched and had too many unusable constants”.  This is why it’s empty.  Theoretically, copying those two sql tables over form your old version should bring them back.  In the admin->languages, ‘Add Constant’ will allow you to add a english word (ie. the word ‘form’).  This then gets thrown into the lang_constants sql table.  Then if you click on ‘Spanish’ you will see this word, and you can put the translation of it, which gets thrown in the lang_definitions sql table.  This is feasible for a small number of words.  If your doing many words and several languages I’d consider it as a sql script, such as is done in the older database.sql scripts (search for lang_constants and lang_definitions for examples):
http://openemr.cvs.sourceforge.net/viewvc/openemr/openemr/sql/database.sql?revision=1.104

   We haven’t given up on internationalization.  Most of the hard code seems to use the xl() function which checks for translations.  I haven’t checked CAMOS though. More information can be found here:
http://www.oemr.org/modules/wiwimod/index.php?page=LanguageTranslation

   Would be nice to get well done internationalization tables back into OpenEMR

-Brady

blankev wrote on Thursday, March 19, 2009:

Brady, I think this will solve my problem for now.

Need some extra free hours though.

I am already used to change the global.php file (I think that was in this file that I had to change 1 into 2 or 5…)before I start the program, so my language for the day will be English, Spanish or Dutch. But since we have "English"-speaking"-, "Spanish"- speakings, and "Dutch"-speaking doctors it seems nice that we all can see the main screens in our own native language while each and everyone can fill the fields with medical notes in generalized similar medical readable language.

I have the feeling/impression that in this way we might be able to communicate much more on same level, but with the same software.

The logic in the translations was easy to understand and easy to implement once you understood the coding sequence. Even if not "every word" was translated and sometimes you saw some funny texts on the screen and knew there still was something to be changed.

So in due time I might have some translations to improve on the situation, because as you mentioned the code was off… and that was for me no headache to change in the resutling *.sql down and uploadfile.

But if I start again with different language coding it would be great to have the latest general accepted translation, and this could be done though a separate CVS *sql language block. Now I found one with changes by Larry (?) and will see where this lead.

Pimm

blankev wrote on Saturday, March 21, 2009:

I tried to include an older version of directory LANGUAGE in the new OpenEMR 3.0.0 but that does noi do the job.

Probably due to rewrite of one of the frames… Uptill now I could not find the responsible file to correct. I also see that " edit definition " does not work as planned. So somewhere in history this all was changed. (Or might have been slashed out???, than tell me wher I should slash in again to get things working)

Can someone guide me, as to where I should go back to find the right corrections?

If the language definition problem is solved, I will make the English/Spanish/Dutch definitions code table compatible again… if time permits.

(I want to have the medication according to our local prescriptions list first.)

Using the Language translations includes rewriting the page codes and the code definition. But once the page code is made translation compatible as stated in the help file, translations in any langague through Code definitions is a rather simple procedure. Haveing more than one defenition in easy to correct. Translation of all English sentences is a time consuming effort, but most sentences had been coded in the older versions.

Pimm

bradymiller wrote on Saturday, March 21, 2009:

hey,

  I probably try a mysqldump command to extract specific tables from your previous openemr database.  Then you can restore these into your new openemr database (of course these instruction come with normal warnings to back up everything etc).

  This mysql dump command should pull out the tables you want to a text file (put your old openemr database name in database name, openemr):
mysqldump openemr lang_constants lang_definitions lang_languages > languageTables.sql

You can then put this into your new database with command (put your current openemr database name in database name, openemr):
mysql openemr < languageTables.sql

-brady

bradymiller wrote on Saturday, March 21, 2009:

hey,

I’m pretty weak in mysql, and was wondering if any mysql experts around?  Should the lang_definitions also have a column with the actual text from the lang_constants (I put quick snippet of a sample dump of the lang tables below); currently it just has the ‘id’ number to refer to lang_constants.  The problem with id number only is if we delete a constant (because its a duplicate entry or jarbled) then your screwed; if you also have the actual text identifier then you could use this to do a secondary search if the id number failed.  With this we could then more stably clean up the old tables (delete duplicate and jarbled entries), and not waste all that previous work.  Unless I’m missing something.

-Brady


– Table structure for table `lang_constants`

DROP TABLE IF EXISTS `lang_constants`;
CREATE TABLE `lang_constants` (
  `cons_id` int(11) NOT NULL auto_increment,
  `constant_name` varchar(255) character set utf8 collate utf8_unicode_ci default NULL,
  UNIQUE KEY `cons_id` (`cons_id`),
  KEY `cons_name` (`constant_name`)
) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;


– Dumping data for table `lang_constants`

LOCK TABLES `lang_constants` WRITE;
/*!40000 ALTER TABLE `lang_constants` DISABLE KEYS */;
INSERT INTO `lang_constants` VALUES (1,‘he’),(2,‘brain’),(3,‘users’);
/*!40000 ALTER TABLE `lang_constants` ENABLE KEYS */;
UNLOCK TABLES;


– Table structure for table `lang_definitions`

DROP TABLE IF EXISTS `lang_definitions`;
CREATE TABLE `lang_definitions` (
  `def_id` int(11) NOT NULL auto_increment,
  `cons_id` int(11) NOT NULL default ‘0’,
  `lang_id` int(11) NOT NULL default ‘0’,
  `definition` mediumtext character set utf8 collate utf8_unicode_ci,
  UNIQUE KEY `def_id` (`def_id`),
  KEY `definition` (`definition`(100))
) ENGINE=MyISAM AUTO_INCREMENT=6 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;


– Dumping data for table `lang_definitions`

LOCK TABLES `lang_definitions` WRITE;
/*!40000 ALTER TABLE `lang_definitions` DISABLE KEYS */;
INSERT INTO `lang_definitions` VALUES (1,1,2,‘sweHe’),(2,1,3,‘SpaHe’),(3,1,4,‘GerHe’),(4,2,2,‘swebrain’),(5,2,3,‘SpaBrain’);
/*!40000 ALTER TABLE `lang_definitions` ENABLE KEYS */;
UNLOCK TABLES;


– Table structure for table `lang_languages`

DROP TABLE IF EXISTS `lang_languages`;
CREATE TABLE `lang_languages` (
  `lang_id` int(11) NOT NULL auto_increment,
  `lang_code` char(2) character set latin1 NOT NULL default ‘’,
  `lang_description` varchar(100) character set utf8 collate utf8_unicode_ci default NULL,
  UNIQUE KEY `lang_id` (`lang_id`)
) ENGINE=MyISAM AUTO_INCREMENT=7 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;


– Dumping data for table `lang_languages`

LOCK TABLES `lang_languages` WRITE;
/*!40000 ALTER TABLE `lang_languages` DISABLE KEYS */;
INSERT INTO `lang_languages` VALUES (1,‘en’,‘English’),(2,‘se’,‘Swedish’),(3,‘es’,‘Spanish’),(4,‘de’,‘German’),(5,‘du’,‘Dutch’),(6,‘he’,‘Hebrew’);
/*!40000 ALTER TABLE `lang_languages` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

markleeds wrote on Saturday, March 21, 2009:

I’m no expert either, but it looks like the three tables represent:

constants = English words
definitions = non-English words
languages = language names

I think you are proposing to combine constants and definitions.  The relationship of constants to definitions is a one to many relationship.  For each English word, there are many corresponding non-English words.  Putting constants into the definitions table would be an example of denormalization, creating redundancy.  You would have the same English word repeated for each non-English word which is it’s translation.  If this improves performance, there is nothing wrong with it.  MySQL only recently supports enforcing referential integrity.  I don’t know if we are using this feature yet.  If not, it is up to the programmer and the PHP code to make sure that a user cannot delete a constant without making sure first that it is not connected to a definition.  Checking for duplicates and safely removing duplicates would have to be done with PHP code.  If we are not doing this job, it would be safer to do things the way you recommend and denormalize the tables and combine two or three of these language related tables.

bradymiller wrote on Saturday, March 21, 2009:

Probably wouldn’t be able to combine the tables, because need to be able to add constants, definitions, and languages independently.  Just trying to figure out a way so we don’t have to dump the internationalization data again in several years when it gets messy.
-brady

bradymiller wrote on Saturday, March 21, 2009:

hey,
  Also, as I think about this more, can’t we just automate the initial collection of constants instead of data entry?  Just some sort of grep regular expression spitting out all the xl("???") instances in the source code?  Then for every release could do this to add the additional ones?
-brady

blankev wrote on Saturday, March 21, 2009:

Well, yes and no!

Redundancy ex-/in-cluded as a fail safe way to go, and after fighting with the language_dDefinitions I came to the same conclusion. It is a file and every covered language will have about 2400 entries if we keep the Englisch translation fields. But it works! (I can use my older Dutch translation with good result. Not excellent, but reasonable)

Sugesstion: We keep OpenEMR as an English written software program. That is where you developers stacked the hidden codes. (See HELP File for ways to cover definitions in the original English layout.)

The language_definitions are defined by a field. (English with 1, Swedish 2, Spanish with 3 and Dutch with 5 etc…)

The whole definition system falls and stays in shape with the original English layout-definitions.

During the use of a different language, change of definitions in that language was easy. You see what you want to change, yuo would go to Admin=>Language=>add/change=>… at least that was in the older versions the way to go. The new 3.0.0 version, you only can add definitions and change to a certain language through direct database acces or through export en import of the changed definitions (even a save of the changes is in my version not possible).

It is easy to export the language file in SQL or CSV format, make the changes in a spreadsheet and import the SQL or CSV file again in MySQL.

Now my observation was that in a spreadsheet you have different sorting options and that changes are easy. You sort on different collums, p.e.  the third collum (language definition parameter, 1,3,or 5) and have the English, Spanish and Dutch translations next to each other, and can make easy changes with the original Enlish definitions within view.

But then you have to make an extra English definition in the language_definition table and also  import for the English definitions. THis mght have some extra unused advantage. If for some odd reason you want to change the English version of the text you can do it like in any other language.  (I have not tried this idea yet, but if it works for other languages, why should an extra English language definition not work?

The latest additions of Larry (an older version, makes the Dutch translation rather up to date.

De Spanish translation is not only very small (about 170 entries), but also with different definition control fields, so the field appear in the wrong place and a wrong translation for that spot. So I will try to find a translator within my practice or group of friends who can make the right changes for the Spanish_+definitions.

HELP HELP HELP HELP:

QUESTION 1: Has anybody a private recent definition file in Spanish for the OpenEMR version 2.8.0 or later with more entries than the one with wrong and 170 entries I found?

QUESTION 2: What happened with the Swedish=2 and German=4 and Hebrew=6 translations?

QUESTION 3: Is anybody trying to use a different approach for the translation matter (I remember a discussion in the past over the Spanish translation and a complete different approach for the OpenEMR translation system, but due to temporary lack of interest did not see the follow-up of those leads.

May be this discussion should be transferred to the Developers Forum, but I do not have the resources to make decisions on that matter. (Brady, Sam, Rod?)

Pimm

bradymiller wrote on Saturday, March 21, 2009:

hey,

I’m still trying to get brain around this problem.  It really seems like our current methodology has sort of failed considering we needed to recently clean out the data.

No reason to re-invent the wheel though, and it does seem like the current tables are sufficient if used correctly.  I think the real problem was introduced into allowing users to customize the lang_constants table.  I think we should be able to collect all the possible constants just by grepping for xl("??") in our source code, which I’m guessing will produce several thousand.  We could then keep this in the lang_constants and during every release update this (do NOT let the users modify this table).  To allow the users to customize, we could create another table lang_customConstants, which is where the custom constants are placed.  The xl() function could then search thru the lang_customConstant first by the actual constant, and if nothing is found then search thru the static lang_constant table by the id number.  So, only additional code change would be search thru custom table in xl() function and adding this custom mysql table.

The adding of languages also presents the same problem, and it is probably best to not allow the user to add languages. Instead, we can add requested language codes to official releases.

With the above mechanism, we can produce a continually growing stable body of translations while allowing the users to change definitions and add their own constants without breaking their code during upgrades.

Sam, what do you think?  I know you are very involved in the translation stuff.

-brady

blankev wrote on Sunday, March 22, 2009:

Dear members of the translation headache group,

in my version of OpenEMR 3.0.0 there are:

Language_constants: 2684 definitions in English. These are the coded parts in all OpenEMR used texts.

My Dutch translation list has now 908 translated sentences and need an estimated 10% correction.

I have no real good working translation in Spanish as yet, but my most recent list was about 173 wrong translation entities

I have no list for: Swedish, German, Hebrew.

Looking at these 2684 constant lines there are at least a couple that can be stricken to make a clean start. By getting rid of abundance nothing is lost. (except for the fact that you have to find the original constant for that specific translation)

Some remarks:

AM and PM, Mr, Dr, MC, VISA, is worldwide understood an does not need translation.

A few translations are almost the same: "Day" and "Day:" are different, but with the right coding can be made the same.

Some one words in English have a different meaning and in Dutch needs two different translation to make the text understandable in Dutch. So one word in English needs in a different place another translation, not to be confusing for the user.

Something like "Error in &quot; is four times in the English definition list.

DOB translated in Geboortedatum gives some terrible layout confusion on the screen. So translations should be about the same length not to make OpenEMR look like a modern art drawing

Proposal:

1. Since finding the place of any English-constants in the original flies is like going back to middle ages to find the original text, I propose to keep the english_constant definition list as is and these should be used as new software parts come up, and need to be made into hidden coding for correct  translations in due time.

2. With any new wording in OpenEMR, the maker should choose from the different English_Constants wherever possible.

Now if my propositions are accepted we get some new entities:

1. A definition list that should be used, so the original English-constant list can be kept to a minimum

2. Any translation list has to be made with a group of individuals with the knowledge of what has been changed and what has not yet been translated.

3. All new texts in OpenEMR should be coded with code numbers of the original English-Constants

Whenever a new list of English_constants is out, translations can be added to the new OpenEMR version, like Larry did in the past.

With this system we still have to overcome at least the next problems:

1. Create the correct translation (If I remember well, the correct translation for the Spanish version means a necessary group of about 3 - 7 different lists: Spanish from Spain, Latin America and Caribbean, but this is not so bad if we find enough persons involved in translation department.

2. During new software development of OpenEMR a group has to include the new and old english_constants  in the different files.
3. Keep the text used in the English original wording as close as possible to the English_constants.
4. We need to find a solution for people who love their own translations so their own list will not be overwritten by any new version of OpenEMR or that they at least can have a choice to accept or reject their own translation. Or make a comparison before the new translations are to be included.

:-)) , ;-)),

Mister President of the OpenEMR society can we bring something like mentioned before into vote and than find a way to cover the roads to travel and make OpenEMR translingual by hitting the language button? (Sam, Rod, I know you are in the board and I know you have the knowledge of what it means to implement complete integrations of this translation issue.)

Remark: I would love to have an easier translation solution with less effort and better result, but that goes beyond my software programming stupidity! Something like Xanadu on the fly would be great, but beyond reach I suppose…

Pimm

blankev wrote on Sunday, March 22, 2009:

Dear all,

would the following suggestion give us a nice opportunity to show how well we do on Internationalisation of OpenEMR:

Before login you get the choice of a different LANGUAGE I am speaking of the login pagewith username and password:

With this choice the file global.php will be set to the choosen language. From there you do a reload and you will get OpenEMR in your favorite language and still can add changes in the definitions whenever you feel like something has to be changed in your own language version.

At least that was how it used to be before V3.0.0, make your translation on the fly during use of your own language and they were availabe after save. (Correct me when I am wrong with this faint memory idea)

we could make
global1.php during reload change the name with copy to global.php for default English
global3.php during reload change the name with copy to global.php for default Spanish
global5.php during reload change the name with copy to global.php for default Dutch

etc…

But, I forgot, …, :  global.php should be changed to not writable before using OpenEmr… so "YOU" programmers must find a different solution.

Could the loginframe.php be told to use a linechange as a global setting (include_once) only one line change in the global.php file before we start the program as an active user?

Pimm

bradymiller wrote on Sunday, March 22, 2009:

hey,

Sounds good.  I’m gonna summarize all this stuff and post to developer section. Planning may take some time, but hopefully we can derive a good stable long-term solution during the next development cycle after we release 3.0.1 .

-brady