Translation Customization Log

OpenEMR Development
1

bradymiller wrote on Monday, April 12, 2010:

hey,

Placed code for review in tracker at http://sourceforge.net/tracker/?func=detail&aid=2985851&group_id=60081&atid=1245239# in order to allow translation customizations (languages, constants, and definitions) that can be persistant, while also allowing continued updating with the “official” language tables.

Pimm and other translators, you’ll find this very useful. Allows local mods of the translations, while also allowing continuing to update the language tables with the google docs spreadsheet translations. Still in the early testing phase.

To see it work(after install patch in tracker in a test server and install openemr):
1) Customize the languages,constants,definitions in Administrion->Language gui
2) Download/install most recent set of official OpenEMR translations here: http://www.openmedsoftware.org/wiki/Install_Translations
3) Then go to Administrion->Language->Manage Translations:
—Top button will show how your previous local customizations diffrer fro
m the offical openemr translations
—Bottom button will synchronize you previous local customizations into t
he current language tables

-brady

2

sunsetsystems wrote on Monday, April 12, 2010:

Thanks Brady, this will be very useful.  Is the patch for 3.2, or the current development tip?

Rod
www.sunsetsystems.com

3

blankev wrote on Monday, April 12, 2010:

BRady, to say something is mere speculation, since I didn’t have time to evaluate. But since the additional last 320 definitions I wanted to make my thought clear, but thought you had done enough and was busy with more important OEM things. I was wrong and as always you are working in every part of OEMR…………

Seeing all those new definitions I could not avoid the simple impression of a lot of almost double translations AND some new introductions of medical related things that the practicing physician would like to change in more appropriate sentences.

After translating 3400 definitions a few extra wouldn’t hurt, I thought ,and indeed it was done in an otherwise lost evening, but for a complete new translation this would take about ten lost evenings, or one lost evening a month to finish within a year.

In the past we had discussions about how to decrease the amount of translation sentences and how to correct one way of saying two things in English with only one word, but needed two or three different translations in Dutch and probably this could also be in other languages. I also made some translation into Dutch for two different words in English that could easy be translated in one word of Dutch. (Seek, Search, ……) If needed I will do some searching and find a better example, but for now this shows what I want to make clear.

English "To: " has to be translated in Dutch "Aan: " en "Tot: " and there is nobody consulted who could find a relevant one word translation.

My question is, how can we make less definitions without harming OEMR and is it possible to use the language spreadsheet to find duplicates, almost duplicates, and double translations in the different languages.

I don’t feel confident to “grep” and change in OEMR, since I am a historical grown MS educated follower. I would like to change, but for now the learning curve is still too steep.

How can we start discussing translations without loosing the past and make traqnslations more adequate for the future? Anyone with “THE” or “a possible” solution?

There should be some translation Gurus who can show us where to go from here to make translations more valuable end stable without much more extra work.

Pimm

4

bradymiller wrote on Monday, April 12, 2010:

Rod,

Patch taken from most recent CVS, but will also work on 3.2.0 with most recent patch installed (and will need to install the lang_custom table). Currently polishing up the gui; let me know if see any issues in code or testing. Plan to commit revised version to cvs soon if looks good and no identidied issues/concerns/problems by community.

Pimm,

1)  Why am I spending time on this? I realized that not being able to keep local customizations of language translations was gonna cause users whom required lots of local language mods to stop using/supporting the google doc spreadsheet. Once this is in place and working, then straightforward to add support for export/import of the local modifcations,  which can potentially be added to the google docs spreadsheets during updates.

2)  Constant duplicates and inflation - There are none. If they look like duplicates it’s because one has a trailing/leading space(es). No longer allow these in new code, but still in the old code. When I added the recent new constants, I did whittle many of them down by fixing the source, but way to time consuming to ‘adjust’ them all.  There is a huge amount of developing going on (Certificates, de-identification, embedding globals, decision support, messenging, reminders, lab orders, …) so it’s hard to force the developers to constrain themselves to known constants, given the funding/time constraints of all these projects.  At some point down the road, will need to figure out a way to begin weaning away linguistically redundant constants, which needs to be done in the source, and will then carry over to the google docs spreadsheet.

3) The “To:” issues. Solutions to this (lots of other words in other languages) are being considered. But this may add even more constants, ie To{address} To{time} could be used in source, but the would both need to be translated. Since this is a per language issue, easier to consider the options when this language local logging feature is working well.

4) Where is the guru? I’ve been waiting for a OpenEMR translation Guru for some time. I heard one was spotted in the rain forest somewhere…

-brady

5

blankev wrote on Monday, April 12, 2010:

Brady,

I hope you don’t feel offended, because that was not my intention. I more than appreciate your constant input and I am convinced that without people like you this OpenEMR project would go toward a silence Intensive Care unit and could be forgotten after the next update. So please all of you, keep improving whenever there is time available.

For "To: "  I found a solution. I just put in both translations. "To: " => "Aan/Tot: " it is some solution, kind of ugly , but the goal to understand what is meant in OEMR is achieved.

Now for the other problems, reduce some definitions, could be done in every update or major update. But I lack the knowledge.

“To:” and "To: " and “TO” and “TO:” etc could be reduced to one same spelling. Is this difficult? I don’t know. Will it make things worse for historic old time OEMR-Users? I don’t know.

But I do know that the more reduction in translated definitions we can achieve the more chances we have that some new translators will show willingness to join.

I might have my next vacation in the rain forest, so please contact me! Want to be sure I find the GURU before the rain forest disappears.

TNX again for all the work done on OEMR and all other DEVELOPERS AND USERS, keep up the good work!

Pimm

6

bradymiller wrote on Tuesday, April 13, 2010:

Pimm,
No offense was taken. Always glad to hear your input and suggestions.
-brady

7

bradymiller wrote on Tuesday, April 13, 2010:

hey,

Just uploaded most recent revision of this module (cleaned up the gui, database
tables, and some of the queries). Likely ready to commit as long as
community doesn’t report any obvious problems with code (plan to commit it tomorrow to cvs).

For users who want in 3.2, this patch should also work for that, but will need to manually create the lang_custom sql table (see the patch).

-brady

8

bradymiller wrote on Tuesday, April 13, 2010:

to clarify above, patch was uploaded to the following tracker:
https://sourceforge.net/tracker/?func=detail&aid=2985851&group_id=60081&atid=1245239

9

blankev wrote on Tuesday, April 13, 2010:

Hello Brady,

is your feature also working for the DEMO versions of OEMR? (Which ones?)

I like to do preview first on DEMO and if needed to give comment from preview so I am sure we use the same versions without all kinds of private changes. Today I did not want to ruin any Demo version so early in the morning. Since my online system has to do with 1 Mb and many freezes, I might have to login and reload many times before I can see any wanted result. For me your recent additions becomes understandable, but I don’t want to make a mess of my working version due to misunderstanding even with your so clear WIKI page of how to include new translations.

Pimm

10

bradymiller wrote on Tuesday, April 13, 2010:

hey,

There was a bug in the database schema in last patch, so posted a new one. It’s testing well, so I committed it to the development tip. Pimm, it’s now working in the cvs demo:
http://www.openmedsoftware.org/wiki/Development_Demo

-brady

-brady

11

blankev wrote on Tuesday, April 13, 2010:

I see the new feature. I tried to explore, but I don’t seem to understand what is happening. English Constants are in the left Column, I used the Dutch Definition and they show in the right Column.

Changed History (GB) => Geschiedenis (old) into Historie (new) and Lot (GB) => Perceel (old) into Voorraad (new)

Click on LOAD DEFINITIONS
Click Manage Translations

Click CHECK ………………… but nothing seem to happen
Click Synchronize …………but nothing seems to happen

What shoul dhappen and how should I continue with the exploration.

Some thoughts:

Can I choose between original and used translation in local version?
If I synchonise do I have the option of accept reject?
Or should I wait a some time till every link is in working order?

It seems to be another good improvement for Translations.  But today 13-4-2010 I could not get any disirable results in Demo V4.0.

Pimm

12

bradymiller wrote on Tuesday, April 13, 2010:

hey,

To explain what’s happening, all of your local mods are being placed in the main lang_* tables and logged in the new lang_custom table (check it out in phpmyadmin). This is why nothing is yet happening (ie. get the ‘The translation tables are synchronized.’ message), they are not different.

See the first message in this forum for instructions on seeing it work. Basically, after your done making your local mods in the demo, then follow instructions in the wiki to import the most recent official language tables into the demo. At this point, you now have the official tables and your lang_custom table. Clicking the ‘Check’ button will tell you what differences you have in your lang_custom table that are not yet in the main tables, and the ‘Synchronize’ button will actually synchronize the two (basically commit all stuff from your lang_custom table into the main tables).

Just try it out, and it should then make more sense,
brady

13

aperezcrespo wrote on Tuesday, April 13, 2010:

Yes very nice…

Pimm, While testing it I synched in your Euros, Sorry.
You may have to add some other info.

But Yes it does work nicely.

Now for the next question:
Do I just backup my lang_custom db and import into new install?

Thanks Brady
Very much appreciated.

14

bradymiller wrote on Tuesday, April 13, 2010:

hey,

Yes, is straightforward to take the lang_custom table over to OpenEMR instance and sync it (would be nice to have an import/export lang_custom feature in future to avoid having to do this via mysql/phpmyadmin).

-brady

15

bradymiller wrote on Tuesday, April 13, 2010:

aperezcrespo,
To further clarify, lang_custom only holds the changes that you make in the Administration->Language gui. So, now if Pimm refreshes the main language tables (lang_definitions,lang_languages,lang_constants) with the “official” set from wiki, his ‘Check’ will still show differences(since lang_custom is now again different from the main tables), which can then by ‘Synchronized’.
-brady

16

bradymiller wrote on Saturday, April 17, 2010:

hey,
Also included this in the most recent 3.2 patch. See here for details:
http://www.openmedsoftware.org/wiki/OpenEMR_Patches
-brady