My wife wanted to use the Dutch Psyche forms (3) for her psyche practice, so she tried the no-no of converting the field_identifiers to english (as best she understood). Don’t ask…
Having now fixed THAT, I changed the LABELS as display from the php files to read dutch - english (again, as best understood). I sent a copy to Dr Bowen, along with a batch program which can post them to replace the existing dutch-only set in a Windows 3.0.1 setup.
My question is whether those forms also will receive the translation tables, and will therefore be in english with the new CVS? When I tried the Brief_aan_Verwijzer form in the CVS, it gave me an error that the form_intakeverslag does not exist, which suggests that somehow the php files got swapped.
There will doubtless be a number of people using the various forms that already exist in OpenEMR as we are. And some of them will likely have originated in a language other than english. I would suggest that any contained in the OpenEMR distribution should follow the translations plan, even if they were not originally in english, but leave the database field_names as original, if only to assure that others’ investments in data not be invalidated by our translation efforts.
One other thing, but related. Each of the forms has a "New" and a "View" php file which are essentially identical, but arrived at by different means. I notice that the Encounter/Visit had been the same "new" and "view", but became a single file for both effective ver 3.0.1. Should we not try to make that the standard throughout, if only to halve the likelyhood of overlooking a variable for the translation (and perhaps reduce the number of duplicates there as well)?
Especially note the developers section. Basically the "english constants" should be surrounded by the xl() function. We have a script which finds all these in the entire cvs source tree (including forms), which we place in the translation google docs spreadsheet (we have about 3600 english constants).
Right now the goal is just to make translations functional and comprehensive, and to begin to think how we can get openemr fully UTF-8 compliant (this will be required for languages not covered by latin1 encoding such as chinese/russian). Dealing with custom forms entered in another language is way down on my queue (unless somebody else would like to tackle this issue). Best way to deal with this now is to translate them to english as you have done and surround with the english with xl() constants. A better way to deal with our form issues is to have an easier mechanism for creating the forms in the first place.
Also, don’t worry about duplicates. We’re ensuring each english constant is unique via the script. I can’t comment on the “New”/“View” stuff, since know little about it.
just another way to tackle this translation of foreign language parts in OpenEMR is to create an English translation_definition part.
lang_constants will cover the to be translated parts, English and foreign language.
lang_languages will include "English", "1", "en"
and translation_constant being "verwijzing naar", will have to get the lang_definition of "referred to".
The only problem will be to find a translator from foreign language to English. All other constants will not have to be translated since they are English in the first place.
YES, in this solution the xl( ) coding is also essential!
Definitely a possibility and would be easy to configure the spreadsheet (just insert an english column, which will basically be an empty column next to the constants) and translation engine to do this. Just would be nice to keep source in one language for several reasons:
1) encoding issues in source code (latin1 vs UTF-8 etc.) (dealing with dos/linux issues hard enough, encoding of special characters would bring more issues; the few places where special characters are used in current source code seem to be screwed up because of encoding issues.
2) potential to have duplicated constants in different languages
3) we’d need translators bilingual in languages other than english (chinese to swedish etc.).
and all other Developers please be so kind as to accept Brady’s proposal. It would make tranlations less confusing.
From now on every development of OpenEMR should be in standard English Constants!
All Dutch_Language parts that are now included in Dutch will be translated into English. (I will start to learn the CVS and do the Dutch-to-English translation of Psyche whenever this proposal is accepted)
If you want pieces of Dutch text in the software, please Develop in OpenEPR!
OpenEMR will be translated with lang_definitions.
All who is in favor say YES all who are against can not vote.
This mail is to be meant serious! (Although you might think different reading the text.)
I LOVE your idea of democracy - especially when we want to get something done! ;-) YES
Contact me via my website below and I’ll send you the set I made. At the very least you could use the text match search to find the labels fast. Unfortunately, when it comes to converting what is there to the Xl() you have exceeded my programming skillset. But I will happily help wherever I can. Can you identify all the psyche forms currently in OpenEMR for me, as I’ll happily do those as well (motivated self-interest
And I must say I like the direction we seem to be moving OpenEMR. I believe we will get far more support for our “certification” by our multi-lingual capability than by our political action alone, given the multi-cultural society we have here in the USA alone, to say nothing of the rest of the world’s usage of OpenEMR, which I certainly support and appreciate.
I am on the way to go to Holland to visit my almost one year old twin grand daughters and will be busy till end of may so I don’t know if I can give you direct support.
Please ask your boss (partner/wife) to make a little note when she encounters a Dutch_psycho.PHP file. I have tried to exclude all Dutch_PC files from my three OpenEMR versions that I currently use mostly for translation reasons.
So let your wife and everybody else, he/she who want to work with non-English parts of OpenEMR make a copy<-> paste of the part that shows on the third row of the screen, should give us a reasonable way to find most of the files.
Leave out localhost or whatever is used in "…/openemr…" away so not get chances of breaching safety and/or HIPAA rules or unwanted intrusion of her OpenEMR system. For now start at the root: …/openemr/etcetera.php
I discovered some dutch wordings in MySQL tables as field names… this might give rise to some implementation works for the Developers…
