drbowen wrote on Thursday, April 23, 2009:
Dear Andres,
We could use a nice Columbian to help with the Spanish translation. I have been doing a lot of research on Spanish dialects. I am told the Columbians (and Venuzuelans) have a nice Latin accented Castillian Spanish that is easy for almost all Spanish speakers to understand. We could really use your talents here. 
Sam Bowen, MD
andres_paglayan wrote on Thursday, April 23, 2009:
Hey, I am Argentinean, not Colombian,
probably the best way is to use "neutral Castillian", which is the one that is used for movie translations that go to South America and other Spanish speakers. It is easy to write that way, specially after seeing so many translated movies.
I could quickly turn around a document, like if I get a list of phrases, I can send back a comma separated values doc with each corresponding string,
drbowen wrote on Thursday, April 23, 2009:
I apologize for the misidentification. I thought you went to school in Colombia? At leeast this is what I remember what your resume.
This is what I have been trying to get the Spanish speakers to agree to. I guess I didn’t the right terminology.
Sam Bowen
aperezcrespo wrote on Thursday, April 23, 2009:
Hi
As far as neutral Castillian or Spanish is concerned I totally agree on this. I don’t think it is to our advantage to over complicate the language portion with the many (and I think Andres would agree) dialects that spanish entails. We may end up with translations for Mexican, Argentinian, Columbian, Peruvian, Puerto Rican, etc… (and the can be a really long list).
I have been quite timid on adding words to Brady Millers Google document. I have added a few but, we need to be careful while translating because a common word in one dialect can be offensive in another. I know of common everyday words in Mexican and Venezuelan which are extremely offensive elsewhere. And vise versa as well.
I live on an Island and there are variations in local lingos, we can identify what town or part of the Island someone is from by accent and word usage. Can you imagine how many exist in South or Central America?
Could there be a way to accommodate this? Or do we just set a single Spanish table and let each region modify it to their needs?
Thanks
drbowen wrote on Thursday, April 23, 2009:
I had this conversation today with a patient who serves as a translator for his company. His mother is from Spain and he has a very distinct Castilian accent. He got into a lot of trouble in a town in Mexico near the Texas border. "Border" Spanish is particularly problematic along these lines. The company makes copper cables. The English work for the outside covering is "jacket". The Spanish word in Castilian is almost identical but in Mexico is very offensive. In Mexico they use a word that means "outside covering".
The same goes true of many of the capital cities. Madrid in particular is notorious for being proud of the "purity" of their Spanish but in fact the internationalization of the city has done a lot of damage to the Spanish spoken there. A similar thing happens in German where the younger generation in particular adds a lot words (especially English) that the older generation is horrified by.
I would vote for "neutral Castilian" as the first step, but obviously we are going to need help from a variety of Spanish speakers to try to avoid unintentionally offensive language.
Sam Bowen, MD
aperezcrespo wrote on Friday, April 24, 2009:
If you like I can tell you plenty of stories. One of my clients has a lady from mexico and a middle age lady from Santo Domingo. Both are very nice and sweet but clash (and I do mean clash) when they speak to each other. Sometimes they even joust each other by using common words from their respective countries just for fun.
My dad lives in Houston and uses a lot of mexican lingo when he visits. As you can imagine our teenagers have a ball just listening to him.
This can go on and on.
I think we can use Neutral and if we run into a problem we can use RAE (Real Academia Española). If we run into a word that can not be resolved with those two resources leave it blank and have local support fill it in.
But then again local support can change just about anything so that it just fits in.
Just a thought.
Thanks
bradymiller wrote on Friday, April 24, 2009:
Dear Andres,
Send me your email address to brady@sparmy.com so I can invite you to our Google Docs language translation spreadsheet. There are several others working on the spanish translation; I’ll send an email introducing you, so you guys can then strategize the best route to go for a “universal” spanish.
It would be nice to have a translation that worked for everybody, but I’m naive.
I’ll go along with whatever you guys decide, ie. 1 universal vs. 100 dialects.
-brady
blankev wrote on Friday, April 24, 2009:
As for thoughts,
I live and work on an even smaler Island than Alfonso and that gives rise to more language problems. It seems the smaller the group of people the more languages they use.
One of many solutions could be to adapt your own set of languages to your local settings, or create a table with your lang_language identification. And than import you own identified languages. In the not so far future we all use OpenEMR with the choice to start with any set of uploadable languages.
For example:
I will use whenever needed: a start in English or Duch_Dutch or Spanish and I hope to find some translator(s) to translate in Papiamanto the local language to be used by my assistant whenever she wants to open up her screen in Papiamento.
It all might seem complicated but actually it involves only a language uploading in lang-definitions and adding an extra language definition in the login-screen.
The other solution is that "the community" creates a Spanish-Spanish language table (with whatever reasoning behind) and everyone who sees some out of place translation can adapt the definition in the Language screen of OpenEMR. (change the offending definition and save)
For me that last solution was most realistic, having about 20 definitions to change (different in Dutch an Dutch Cariggean). Clinic changed to Oficina and Pharmacy changed to Botica…
If someone wants to have some direct info exchange on this, please feel free to contact. "My Language Guide", DTG is obviously most Dutch information, but I think I am rather good informed about the Language possibilities of OpenEMR.
(I even managed to change some wrong Spanish translation. f.e.: “Back” on the screen means go to former situation. For English speaking persons and dictionaries “Back” could also mean espalda but don’t hit the Espalda-button to often!)
Pimm
drbowen wrote on Friday, April 24, 2009:
We have discussed in the past having multiple Spanish translations. It is still possible to do so but I wish at least one native speaker would "just hitch up their britches" and do something. What we refer to in the American West as the "cowboy method". It means "just do something."
We could leave "3" as RAE (Real Academia Española) with language code of "es".
Then start creating additional Spanish translations with separate country codes. Such as
es == RAE (Real Academia Española)
pr == Puerto Rico
We can use the email two letter country codes.
Andres, what is the email code of Argentina?
Sam Bowen, MD
bradymiller wrote on Saturday, April 25, 2009:
hey,
Time for the openemr language translation newsletter:
We’ve gone from 173 definitions to 3508 in three weeks.
Here’s specifics on the translations to give an idea of current coverage:
Chinese: 1% (29 definitions)
Dutch: 49% (1799 definitions)
French: 0% (0 definitions)
German: 0.1% (4 definitions)
Hebrew: 0% (0 definitions)
Norwegian: 21% (770 definitions)
Russian: 0% (0 definitions)
Spanish: 14% (502 definitions)
Swedish: 11% (404 definitions)
The best way to test your translations is on the online cvs demo, which is using the above new translation table, and allows you to select a language before logging in:
http://oemr.org/modules/wiwimod/index.php?page=DemoCVS
Here is the updated mysql dumpfile: http://openemr.cvs.sourceforge.net/viewvc/openemr/openemr/contrib/util/language_translations/currentLanguage.sql?revision=1.4
You can also install the above mysql dumpfile into your local openemr, but note this stuff is still considered experimental, and will delete your current language tables (back your stuff up before using this). Steps to do this are below:
1. Download the above currentLanguage.sql dumpfile to your computer.
Then in OpenEMR go to
admin -> Database -> Databases -> openemr -> SQL and click ‘Browse’
button at the ‘Or location of the textfile:’ field. Select the currentLanguage.sql
file you downloaded to your computer, then click ‘Go’ button.
2. If you want to see the translations. Edit the openemr/interface/globals.php file at the translations entry. Put 2 if you want swedish, 3 if you want spanish, 4 if you want German, 5 if you want Dutch, 8 if you want to see Norwegian, 9 if you want Chinese, and 10 if you want Russian. After changing setting remember to logout then login back into OpenEMR.
Other News:
We now have an openemr language translation wiki at:
http://www.oemr.org/modules/wiwimod/index.php?page=TranslationGuide
To get "editing" access, register (at bottom right of screen) and then email me (brady@sparmy.com) your username, so I can give you wiki editing privileges.
good luck and keep entering those translations into the google Docs spreadsheet
-brady
bradymiller wrote on Saturday, May 02, 2009:
hey,
Time for the openemr language translation newsletter:
We’ve gone from 173 definitions to 3842 definitions in one month:
Total number of english constants: 3658
Total number of definitions: 3842
Here’s specific percentages of each languages coverage:
Armenian: 0% (0 definitions)
Chinese: 1% (33 definitions)
Dutch: 50% (1834 definitions)
French: 0% (0 definitions)
German: 0.5% (12 definitions)
Hebrew: 0% (0 definitions)
Norwegian: 21% (770 definitions)
Russian: 1% (34 definitions)
Spanish: 18% (663 definitions)
Swedish: 14% (496 definitions)
I have also included a “dummy” language, which basically defines the word dummy for all 3658 constants. This is so we can find constants that aren’t translating and fix them.
The best way to test your translations is on the online cvs demo, which is using the above new translation table, and allows you to select a language before logging in:
http://oemr.org/modules/wiwimod/index.php?page=DemoCVS
Here is the updated mysql dumpfile: http://openemr.cvs.sourceforge.net/viewvc/openemr/openemr/contrib/util/language_translations/currentLanguage.sql?revision=1.5
You can also install the above mysql dumpfile into your local openemr, but note this stuff is still considered experimental, and will delete your current language tables (back your stuff up before using this). Steps to do this are below:
1. Download the above currentLanguage.sql dumpfile to your computer.
Then in OpenEMR go to
admin -> Database -> Databases -> openemr -> SQL and click ‘Browse’
button at the ‘Or location of the textfile:’ field. Select the currentLanguage.sql
file you downloaded to your computer, then click ‘Go’ button.
2. If you want to see the translations. Edit the openemr/interface/globals.php file at the translations entry. Put 2 if you want swedish, 3 if you want spanish, 4 if you want German, 5 if you want Dutch, 8 if you want to see Norwegian, 9 if you want Chinese, 10 if you want Russian, and 12 if you want “dummy”. After changing setting remember to logout then login back into OpenEMR.
Other News:
We have an openemr language translation wiki at:
http://www.oemr.org/modules/wiwimod/index.php?page=TranslationGuide
To get "editing" access, register (at bottom right of screen) and then email me (brady@sparmy.com) your username, so I can give you wiki editing privileges.
have a good weekend and keep entering those translations into the google Docs spreadsheet
-brady
sunsetsystems wrote on Sunday, May 03, 2009:
Jumping in here a bit late…
I was just looking at the list of language constants on the Google Docs spreadsheet. Seems to me that many of them apply only to U.S. insurance billing, and so translating all those is wasted effort… and they are among the longest entries. They should probably not have been wrapped with xl() statements. Mostly I’m talking about the files interface/billing/*_codes.php.
Volume is a huge barrier to translation effort, and we should be looking for ways to reduce it.
And as someone else noted, other xl() usage needs cleanup as part of the translation effort. For example "(New Patient)" should not appear as a language constant… it should be just "New Patient".
bradymiller wrote on Sunday, May 03, 2009:
hey,
Basically have a script that collects all enclosed xl() stuff from source, no biases. This script can also then find new xl() stuff as code is developed by comparing to the old constant list. So didn’t want to go through and remove any constants from the list. Goal is standardizing this stuff and not getting ourselves into the previous position that caused us to throw out the previous list of definitions. Plus, even though it’s US billing stuff, may still have situations (older parents working in a US acupuncture clinic that speak another language) where the translations are beneficial.
If decide to remove things could just use the Google docs hide function for now so translators don’t see the constants.
-brady
bradymiller wrote on Sunday, May 03, 2009:
hey,
Regarding bad xl() usage “(New Patient)”, I’d add the ship as already sailed. The created translation tables created from our scripts are actually compatible with previous versions of OpenEMR. So, if we remove old “bad” constants then previous versions of OpenEMR won’t get full coverage by the tables.
-brady
drbowen wrote on Sunday, May 03, 2009:
Would it be possible to arrange the constants in terms of most important to least important. For instance putting all the billing stuff at the bottom of the list?
I am trying to do some German translation and the whole thing is daunting. It is hard for me to find high impact phrases that show up on the main page, demographics, etc. The current organization makes it more difficult for "not-as-good with computers" translators to be of much help and to train how to do the translations.
Sam Bowen, MD
bradymiller wrote on Sunday, May 03, 2009:
hey,
It’s alphabetical (that’s why annoying special character stuff goes to top), I can add to instructions that it’s sorted alphabetically. To get the high impact phrases, can use the CVS demo to find best words to translate on list (alphabetical sorting makes this straightforward). And if their having issues with a word not working they can check out the “dummy” language (this substitiutes dummy for all translated words, so if not “dummy” then problem in the source). Again, the goal here is maintainability over simplification (list of reasons below).
By not editing the google docs spreadsheet english constants on a whim and instead using standard scripts to create the list of constants and incorporate "new" or custom constants it will stop this project from becoming unmanageable or suck away from precious developer time.
Some of the constants also have to be actually replaced by their originals after exporting from google docs since some get modified during the import/export (ie leading spaces get deleted).
Also need a mechanism that allows other developers to easily take over the "project" in case I get busy/distracted with other things.
And, mostly, we really need to take care to avoid falling into the same trap that caused us to toss the old list of definitions. Hence, even though it is daunting, that german word you type in will always be with us.
-brady
bradymiller wrote on Sunday, May 03, 2009:
hey,
I updated the language wiki page:
http://www.oemr.org/modules/wiwimod/index.php?page=TranslationGuide
Hopefully this addresses the alphabetic and billing issues.
Also included some notes for developers to keep this process transparent. The key script is buildLanguageDatabase.pl, which turns the exported google doc into the mysql language tables. This script also does validity checking (ensure enlgish constants/ID’s were not messed with in google docs spreadsheet) and actually reverts about 90 constants to their original state because of google doc specific mods. I also plan to have this script have the functionality of incorporating new constants (for example adding to end of google docs) to reorder alphabetically and create an entire new spreadsheet to re-import over the old occasionally. I hope this logic is making sense.
-brady
blankev wrote on Sunday, May 03, 2009:
May be, Brady…
can give a solution again… with his grep -R solutions he might be able to write a script and give the different files a number. Than we could make another column with specifications of where the constants can be found in what file. With the connection to the file you might be able to make a list of importance for certain users.
Constant xl(login,e) can be found in file login.php (This file is pretty important and I would give it number (1) put this numbers in a separate column and new translators can follow some kind of important translations to go.
Than you as a translator have to find the files you think are important for your users in translated form.
Another way to go might be to login and make a note of the words you want to translate, than translate these an give them a number (1) and than find the constants of the next important file/page and give them a number (2), these numbers get a separate column. With this column you could sort on importance, but this only will work for new translation. I for example will not start from scratch again to see what I found important…
Remember to use the dummy translation to see what constants still need to be coded. Left menu frame: Ofc notes, Addr book etc… in the CVS demo it is a clear and sound proof (as far as I tried it)
Pimm
bradymiller wrote on Monday, May 04, 2009:
hey,
Rod found a cluster (about 1500) of english constants that are highly specific to US billing concentrated in 3 files in the billing directory (adjustment_reason_codes.php, claim_status_codes.php, remark_codes.php). We are going to delete them from the translation table as long as nobody sees any international use for them. I have pasted the list in the following thread:
https://sourceforge.net/forum/forum.php?thread_id=3261769&forum_id=202506
Please keep your responses in this thread.
-brady
sunsetsystems wrote on Monday, May 04, 2009:
I’ll remove the xl() wrappers from these strings later today, if nobody objects. It will be great to delete all that clutter from the list of translation constants.