OK, so we’ve got the Graphic Pain Map. We need to do the following things:
1. Translate its title to Greek. Where is it?
2. Translate its pop-up and its contents (including the pain scale menu and the objects in it).
3. Perhaps change the graph with one that is of a higher resolution and definition (the existing one looks like an overstretched to death low-res image).
4. Adapt it for dermatologists; they saw it and said it’d be useful as a graphic rash map.
Ad 1. No clue
Ad 2. Should be done in due time. (The words/sentences below the image are translatable.)
Ad. 3. Changing the graph is easy as long as you keep the same size of the image. Need to change the words on the graph in Greek. Any graphic program should be capable of this. (I use Paint.net program). even without words you can use it, since it is obvious in the note why there is a red square to mark something)
Ad.4. May be the option of having different graphs in the Graph pain map is possible. The label can be changed into medical graphic click-able graphs or something better could do the trick, or might already be available as was discussed in the past (Who can shed some light in the use of different images?).
As doctor I see the improvements of the program with these options. But I am just a commenter (used to be called a lurker), and not a Developer or financial sponsor, so I have to wait for others to take the challenge.
1. This constant basically got missed (the forms titles need to be manually added when I do a constant update), but it is planned to get added to the next constant run (can happen anywhere from 1-3 months). Note that you can add this constant to your local OpenEMR instance at Administration->Other->Language->Add Constant and then define it. The cool thing about doing local translations like this when needed is because these custom entries are tracked in the lang_custom sql table, which allows two things:
a. Can continue to import/update the official translation sets and not lose your local customizations (via the Manage TRanslations->Synchronize feature).
b. You can simply copy the lang_custom data to other OpenEMR instances to bring your customizations to other instances (again via Manage TRanslations->Synchronize)
2. I think just need to encapsulate the strings at end of the interface/forms/painmap/C_FormPainMap.class.php file. Will need testing since I note that for some reason the string (and also potentially the id’s) seem to be stored in the database (so some testing and maybe a minor change, whereby only the id number representing the element is stored there).
Brady, while we’re on the subject of translations (local, custom etc), I need to point out a problem we’ve encountered with our own system. Under our domain, we run multiple different databases for various doctors and practices. The thing is, OpenEMR doesn’t give the same const_id’s from one database to the other, which makes it impossible for us to continue using the Google spreadsheet.
Downloading the latest translation tables and inporting them on all different databases must give the same result on everey setting updated.
It is just because the translation table is imported from a renwed version every day. Through administration, database download CSV imported file should do the trick!.
But if you have a large custom_definition file made in the different local/server settings, it might be necessary to make your own corrections in the CSV tables for the Custom_Language translations, which is a separate table. Download trough Administration Database the CSV file WITH Put Fieldnames in the first row, made from Custom_Language and compare this file in any CSV compatible spreadsheet program. Be sure to keep the same heading of the CSV file and at import phase, don’t import the first line of the new created CSV file. (Or use the official translation spreadsheet and us the next days automatic created corrected version.)
As far as I remember, it is the Custom _language file that is copared first, second the languag of choice Definitions and if filed content is not found, the English Constant_Language is used.
If done stpewise as advised it must work on all databases. I do this since OEMR 3.1 without anu problem.
All of your local modifications done in the editor within OpenEMR are stored in the lang_custom table, which can then be added back after you bring in the official translation set. So, you could set up a central OpenEMR instance that you only use to enter in custom constants/definitions for all of your customers. Then you can simply take the data from the lang_custom table and re-populate this table in your customers OpenEMR instances. Then you can import the official translation set and follow it with the Synchronize button in the Manage Translations GUI to bring in your custom stuff.