hey,
The Indonesian group is rather resourceful and enthusiastic. They placed the translations first from http://translate.google.com/ into the spreadsheet, and are now modifying those listings. They are aware that most entries need human modifications, but felt it would be quicker for them. I told them this was fine as long as they verified each definition before the next openemr release. I’ll send their mastermind an email with you cc’d, so you can further discuss this strategy. Doing this for every language may be a mistake, since as you have probably noticed about half of the languages requested so far have no definitions (ie a user requested the language and access to the google docs spreadsheet, but has done no translating). Just want to make sure OpenEMR isn’t using any unverified “machine only” translations in a official release.
-brady
Just to clarify; if a translation table has NO translation for a given item, the default English will be posted, and NOT a blank? That will make any of the issues listed by Brady meaningless - if users care enough to have the language right, they will make it so. Is it possible to require that language changes must go through the Brady "master", or should we allow for individual user changes?
If possible, I would prefer we default to the former, with the latter as a user changeable “switch” via Globals.php or other. That would assure the community gets the maximum value from our effort (and the users’ as well), but allows users to still have maximum local flexibility and fastest process. Even for that, the users must be able to get the conversion table for their selected language(s) as a download at any time.
Yes, a blank will default to English. Which issues? (I have lots of meaningless issues, just want to know which ones your specifically referring to…) At this point I’d also rather have users contribute to the spreadsheet and our definitions than create their own in OpenEMR (admin->language); better for the community. Plus the tables I publish weekly at this point will delete any custom things the user has (this has to do with the mechanism of the translation engine and tables), so this will also push users to want to contribute to the spreadsheet rather than make their own local stuff. A project down the road will be figuring out a way to allow user to use the official translations and make stable customizations.
Figured out a nice clear mechanism for the translation of list and layout (and will also use for gacl group names) labels. There are two flags for user to turn off translation of lists and layouts in globals.php (in case the user wants to just go ahead and translate their own layouts and lists).
To make clear in the code and managable for us I’m gonna check in two wrappers of the xl() function; one for list_labels and the other for layout_labels. Thus, in the code, can call the xl_list_label() wrapper if showing a list_label, which will then only translate if the flag is set to true in globals.php. I’ve changed the options.inc.php to use this mechanism, and much clearer for the coder (have not checked it in yet). My questions is where the best place to place (for developer clarity) these wrapper functions xl_list_label() and xl_layout_label() function; in options.inc.php or in translations.inc ? (also note will have a xl_gacl_label() wrapper at some point to also control translation of the gacl group names via a globals.php flag)
I guess in translations.inc, given that translation touches virtually all areas of functionality and we keep all the other translation stuff in there rather than in those other areas. Unless you have some special reason to do otherwise.
Just committed changes to cvs code to fully support internationalization in the access controls (admin->acl menu).
There is a flag that can be turned off in globals.php for translation of the gacl groups (since users may decide to create groups in their own languages). However the return values and aco names will always be translated.
Rod, hope your ok with what I did to the acl_setup.php file; set it up so each control gets a xl() comment to flag the name for inclusion into the list of constants. So should now be straightforward for developers to set up translation of a new official openemr aco or group.
Time for the weekly translation table update and statistics. Lots of definitions this week. Also several problems in the worksheet over the last week, so time to institute some news rules:
1) Let me know if you modify/delete a english constant or other definition by mistake and can’t undo (I can quickly fix this)
2) Do not enter any ‘new line’ or ‘tab’ characters into spreadsheet (both cause problems, which require manual fixing on my part)
Here are the statistics:
Total number of english constants: 2421
Total number of definitions: 11395
Bahasa Indonesia: 99.9% (2416 definitions)
Brazilian Portuguese: 0.1% (1 definitions)
Chinese: 62% (1502 definitions)
Dutch: 100% (2420 definitions)
German: 2% (48 definitions)
Greek: 5% (132 definitions)
Norwegian: 37% (902 definitions)
Russian: 4% (89 definitions)
Spanish: 90% (2186 definitions)
Swedish: 74% (1789 definitions)
We will continue to include the “dummy” languages, which basically defines the word dummy for all 2421 constants (there is also a dummyUTF language which uses a chinese word for every translation). These are 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 (this is the most current development version of openemr), which is using the new translation table, and allows you to select a language before logging in: http://oemr.org/modules/wiwimod/index.php?page=DemoCVS
Still working on providing a “safe” set of sql tables for users that you want a local version. I’ll place the link and instructions on the wiki below when finished.
Time for the weekly translation table update and statistics. I’ve imported the new definitions into the online cvs demo (see link below).
Here are the statistics:
Total number of english constants: 2421
Total number of definitions: 11546
Bahasa Indonesia: 99.9% (2416 definitions)
Brazilian Portuguese: 0.1% (1 definitions)
Chinese: 62% (1502 definitions)
Dutch: 100% (2419 definitions)
German: 2% (48 definitions)
Greek: 8% (193 definitions)
Norwegian: 37% (902 definitions)
Russian: 4% (89 definitions)
Spanish: 90% (2187 definitions)
Swedish: 74% (1789 definitions)
We will continue to include the “dummy” languages, which basically defines the word dummy for all 2421 constants (there is also a dummyUTF language which uses a chinese word for every translation). These are 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 (this is the most current development version of openemr), which is using the new translation table, and allows you to select a language before logging in: http://oemr.org/modules/wiwimod/index.php?page=DemoCVS
Still working on providing a “safe” set of sql tables for users that you want a local version. I’ll place the link and instructions on the wiki below when finished.
Planning on adding another 300 constants either this weekend or next. Hopefully will have complete coverage of source code within the next 1-2 months. Only sizable projects left includes (I plan to do 1 and 2. 3 is in limbo.):
1) Mechanism to translate appointment type titles (will be toggable like translation of lists)
2) Mechanism to translate patient note titles (will be toggable like translation of lists)
3) UTF-8 characters in pdfs (relatively big project likely involving importing and converting to tcpdf library or converting to all html-css print). Any input here on solving this problem would be very very helpful.
Time for the weekly translation table update and statistics. I’ve imported the new definitions into the online cvs demo (see link below).
Here are the statistics:
Total number of english constants: 2421
Total number of definitions: 12856
Bahasa Indonesia: 99% (2416 definitions)
Chinese: 62% (1502 definitions)
Dutch: 99.9% (2419 definitions)
French: 2% (41 definitions)
German: 2% (48 definitions)
Greek: 40% (980 definitions)
Norwegian: 37% (902 definitions)
Russian: 4% (89 definitions)
Spanish: 99% (2400 definitions)
Swedish: 74% (1789 definitions)
We will continue to include the “dummy” languages, which basically defines the word dummy for all 2421 constants (there is also a dummyUTF language which uses a chinese word for every translation). These are 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 (this is the most current development version of openemr), which is using the new translation table, and allows you to select a language before logging in: http://oemr.org/modules/wiwimod/index.php?page=DemoCVS
Still working on providing a “safe” set of sql tables for users that you want a local version. I’ll place the link and instructions on the wiki below when finished.
The source code internationalization project continues to move forward. Incorporated a toggable feature (in globals.php) to allow translation of form titles. I’ve realized all of our main forms will need to be internationalized (the new.php and report.php files); did this to the SOAP and dictation forms which seems to work well. Here’s are files I touched for the stuff just discussed:
openemr/interface/forms/dictation/report.php
openemr/interface/forms/soap/report.php
openemr/interface/forms/soap/templates/general_new.html
openemr/interface/patient_file/history/edit_billnote.php
openemr/interface/patient_file/history/encounters.php
openemr/interface/globals.php
openemr/interface/forms/newpatient/report.php
openemr/interface/forms_admin/forms_admin.php
openemr/interface/patient_file/encounter/forms.php
openemr/interface/patient_file/encounter/new_form.php
openemr/interface/patient_file/report/custom_report.php
openemr/interface/patient_file/report/patient_report.php
openemr/library/translation.inc.php
Gonna postpone addition of new constants (likely 350 of them) for another week or two to try to get following done first. Once the following is complete and the new constants are added, almost everything will then be internationalized:
1) Internationalize majority of the main forms
2) Toggable mechanism to internationalize the patient appointment titles
3) Toggable mechanism to internationalize the document categories
Would be great to get any takers to volunteer to figure out how to get utf8 characters working in pdf’s (likely require going to the tcpdf library) for the prescriptions, letter generator, and possible billing (spanish names with special characters to us carriers??). This mechanism will be required for us to really claim that openemr is a fully functional program in languages requiring utf-8 characters (which is most of them).
Why is it that we can create language translations for English, but the xl() function won’t use them?
I have English-speaking clients who want to substitute some words and phrases, such as “Visit” for “Encounter”. That used to work, but does not any more. I guess I’ll make it an option in globals.php, unless someone has a better idea.
That’s my fault; I assumed if a user was using english then no need to go through the translation engine. The speed without the engine is just a bit faster (barely noticeable now that the table keys have been correctly optimized). It would be very easy to go back to previous behavior.
Two options:
1) Remove this completely in the translations.inc file xl() function, so everything including english goes through the translation engine.
2) Control it with a global.
Now the language stuff is efficient and progressing well, I’m ok with completely commenting out the if statement in xl() function that blocks english translations since not really intuitive to user to control with a global.
Just tested above (removed the block to english translations in xl() function), and works fine to replace english constant. If you want, I’ll commit it.
BTW, your cool filter in admin->language is no longer working…
In another thread, I’m looking for comment on a pile of patches that switch encounter with visit, and patient with client, amongst other actions.
I’ve taken the approach of using a variable in globals.php.
It will take a bit of time to separate the encounter_is_visit and patient_is_client patches from my disable_(calendar|immunization|prescription|chart_tracker) set.
Are we just going to use the translation engine for this? I thought that would slow down operations too much, personally.
hey,
Incorporated a toggable feature (in globals.php) to allow translation of appointment categories. (won’t be obvious until add the next round of constants). Files I touched to do this include:
openemr/interface/forms/newpatient/common.php
openemr/interface/main/calendar/add_edit_event.php
openemr/interface/patient_file/summary/demographics.php
openemr/interface/reports/appointments_report.php
openemr/interface/main/calendar/modules/PostCalendar/pnuserapi.php
openemr/interface/main/calendar/modules/PostCalendar/pnadmin.php
openemr/interface/main/calendar/modules/PostCalendar/pnlang/eng/admin.php
openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/admin/submit_category.html
openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day/orig_default.html
openemr/interface/globals.php
openemr/library/translation.inc.php
Gonna be a good time to add the new constants soon (hopefully over weekend)). Then can more easily identify parts in calendar that aren’t internationalized.
I just added 375 brand new constants to the Google Docs spreadsheet. Because of this I also updated the tables and inserted these into the online cvs demo (see link below). NOTE that since I updated the tables and demo today, I plan to SKIP this weekend. The new english constants are also listed here: https://sourceforge.net/forum/forum.php?thread_id=3312267&forum_id=202506
NEW Language Statistics:
Total number of english constants: 2796
Total number of definitions: 12683
Bahasa Indonesia: 86% (2416 definitions)
Chinese: 54% (1502 definitions)
Dutch: 87% (2421 definitions)
French: 1% (41 definitions)
German: 2% (48 definitions)
Greek: 38% (1074 definitions)
Norwegian: 32% (902 definitions)
Russian: 3% (89 definitions)
Spanish: 86% (2400 definitions)
Swedish: 64% (1790 definitions)
We will continue to include the “dummy” languages, which basically defines the word dummy for all 2796 constants (there is also a dummyUTF language which uses a chinese word for every translation). These are 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 (this is the most current development version of openemr), which is using the new translation table, and allows you to select a language before logging in: http://oemr.org/modules/wiwimod/index.php?page=DemoCVS
Still working on providing a “safe” set of sql tables for users that you want a local version. I’ll place the link and instructions on the wiki below when finished.
Just checked in changes to cvs to allow translation of the document categories. Touched following files to get this working:
openemr/interface/globals.php
openemr/library/translation.inc.php
openemr/library/classes/Tree.class.php
openemr/templates/document_categories/general_list.html
openemr/templates/practice_settings/general_list.html
openemr/templates/patient_finder/general_find.html
openemr/controllers/C_DocumentCategory.class.php
openemr/controllers/C_Document.class.php
openemr/CategoryTreeMenu.js
openemr/interface/patient_file/history/encounters.php
openemr/interface/patient_file/report/patient_report.php
openemr/interface/patient_file/report/custom_report.php
There are now mechanisms to give the option to translate the following in globals.php:
layout items
list items
gacl titles
form titles
document catgegories
appointment titles
These are set to “on” as default, thus international users will see everything translated out of the box. What’s really cool about this is that it allows multi-lingual use of openemr in the same clinic. And if for example, a foreign practice wants to create their own layout in their own language they can then turn off the translation of the layout items (this avoids the potential of translating foreign words that happen to be same as an english constant).
Still to do in the Internationalization project:
1) Translate forms (SOAP and dictation are done, plan to get through the main ones)
2) Clean up some translations in the calendars
3) Get UTF-8 to work in PDF. Likely will require import and testing of the TCPDF library.
4) Testing, testing, testing. Would be nice to get Chinese or Greek users to input these characters everywhere possible in online OpenEMR CVS demo to ensure utf-8 encoding is not broken anywhere.
5) Predicting to have another 150 more english constants to add to the translation spreadsheet in 3-4 weeks (this should be it)