In both reviewing manually the google doc, and running a query on the demo server
(I used this SQL statement)
select count(), constant_name from openemr.lang_constants group by constant_name having count() > 1 order by count(*) desc;
There are a number of duplicated constant_names in the constants table.
I am guessing that this may cause some glitches with translations, but I’m not sure what the correct course of action is.
This is the list of duplicates
2 Priority
2 Blood pressure
2 Don’t Save
2 Accept Payment for
2 Category
2 Search or Add Patient
2 Review Of Systems
2 Additional Notes:
2 Diagnosis:
2 To:
2 Treatment:
2 Gender
2 Totals for
2 Claim was generated to file
2 Physical Exam
2 Not Examined:
2 From:
2 Total for
2 New Definition set added
2 Printing skipped; see test output in
2 Normal Cardiac Exam:
2 Encounter
2 Procedure Order
2 Dictation:
2 Left:
2 English
2 Error: passwords don’t match. Please check your typing.
2 Reference Reason
2 Claim
2 and
2 Normal Lung Exam:
2 Generate Letter regarding
During my efforts to translate I encountered many places with just a space at the end of a line. (After " . " or " : ")
Another observation is: There are many more words or parts of sentences with the same medical result. Words in Capitals or beginning with Capital or lower case, for the same words.
If you could make a Dictionary for Developers of what is used and what can be changed into…, it would result in a more consequent text for OpenEMR, but hard to stay in sync with the past versions of OpenEMR.
I just checked Gender and indeed twice available. 1. “Gender” 2. "Gender " just a small difference, but very important for the lay-out of the text.
Recommend verifying these to the list of constants in the following file:
contrib/util/language_translations/currentConstants.txt
For example, with “Priority”, one has a trailing space and the other does not, which shows up both in above file and if you look at the entries in phpmyadmin.
See below for some sql queries of interest. It appears we should have a BINARY in the query in the library/translation.inc.php (note that the constant_name is collated in binary, but appear need to place BINARY in front of the variable, like so(I have not tested this):
$sql="SELECT * FROM lang_definitions JOIN lang_constants ON " .
"lang_definitions.cons_id = lang_constants.cons_id WHERE " .
“lang_id=? AND constant_name = BINARY ? LIMIT 1”;
This is where I saw some info on this:
BELOW ARE THE INTERESTING SQL QUERIES:
select constant_name from openemr.lang_constants where constant_name = “Priority”
-> ;
±--------------+
| constant_name |
±--------------+
| Priority |
| Priority |
±--------------+
2 rows in set (0.06 sec)
mysql> select constant_name from openemr.lang_constants where constant_name = "Priority "
-> ;
±--------------+
| constant_name |
±--------------+
| Priority |
| Priority |
±--------------+
2 rows in set (0.00 sec)
mysql> select constant_name from openemr.lang_constants where constant_name = BINARY "Priority "
-> ;
±--------------+
| constant_name |
±--------------+
| Priority |
±--------------+
1 row in set (0.01 sec)
mysql> select constant_name from openemr.lang_constants where constant_name = BINARY “Priority”
-> ;
±--------------+
| constant_name |
±--------------+
| Priority |
±--------------+
1 row in set (0.00 sec)
Best thing to do is take a peak into the translation table (Google translation sheet OpenEMR):
Don’t Save
is not the same as:
Don’t Save
for your second example there is the same backward slash before the apostrophe
but for OpenEMR it looks the same. I am not a programmer, so I can’t help you to find the correct query to distinguish these double translations. It used to be we needed a backward slash for special characters.
Let’s hope Brady finds some time to tell you what to do. Get the Backward slash in or get it out in OpenEMR. the slash seems there is no special need for the backward slash in modern OpenEMR.
The issue seems to be that the backslash is being treated by the scripts which generate the constants as a distinct character when it should be “escaped out.” (It does in fact get escaped out when loaded in to the database.)
But in this case, it’s generated without the backslash
After processing in the database things get duplicated.
I’m “post processing” definitions to remove duplicates in the system I’m working with to prevent ambiguity, and because the definitions seem to be repeated in the Google Doc, there is likely no real impact to users, but it is a bug of sorts.