This happened to me today when I logged into the system using the English locale. I happened to notice that for concepts that only have Fully specified name in english, no short name in english but another short name in russian, The russian short name is used instead of using the Fully specified name. I have attached some pictures to explain a little more. Is there a way to configure the system so that these locales do not mix? I think this can be an issue if you are running reports/exports.
Just confirming that you are using your own concept dictionary. Although CIEL has Russian translations, this concept does not have any (regardless of term type).
Thanks @akanter! In the CIEL dictionary, this concept does not have any Russian translation. We(PIH) are translating some concepts that will be used for our endTB project. Some of these concepts come from CIEL, others were newly created by the bahmni team.
@akanter, as an additional note, all of the concept translations for these terms (which equates to the display names they will appear with in the application), are being authored and managed here:
@jmbabazi thanks for pointing out. This looks like an issue on Bahmni side. The fix will be a smaller one but will be a code change. We will be working on it.
I am not able to see the actual content as I keep getting a server error. However, can I ask why we are using this method of translating CONCEPTS? I thought this was to be used for UI/properties files only. I really would prefer a method which can be consistent with CIEL and so all us to distribute the translations with CIEL.
OK> I was able to see a text file. I see that it is a mixture of CIEL and non-CIEL concepts. Many are confusing and I believe problematic. The UUIDs don’t match CIEL for concepts that exist in CIEL. I think we probably need to have a discussion about this dictionary…
Mike suggested we do things this way, to give a consistent process for the translators. And that sounds correct to me. (See the next comment.)
I think that we need to redouble our efforts to have a better tool for shared concept dictionary management (i.e. OCL). As long as the technical process for using a subset of CIEL is as involved and convoluted as it today, we will constantly be running into situations where dev and implementation teams go their own way, given their timelines and available resourcing.
I agree with both of these comments, but I’d also ask why we think that translating Concepts this way is problematic? Doing translations like this in Transifex is much more transparent and completely accessible and available for incorporation back into OCL as each Concept is translated. I know of no other mechanism for doing this today that doesn’t involve some sort of back-channel email-based or shared google spreadsheet approach.
@akanter, is there a different preferred process / workflow for teams of people, working in their local languages, to participate in translating Concepts and getting those back into CIEL?
Well, we do have the TSB module… but translating concepts can be done in Transferex if I can figure out an easy way to bring them into the dictionary. Medical translations are not the same as an engineer translating the UI, though. The subtleties are important. But then again, I often do not have bilingual medical translators that can double check what other people are doing via spreadsheets either! In this case, it is more a question of which concepts are there (which is more of the former issue) since there is clear overlap with existing CIEL content.
A few things to note in case they are significant.
These translations are the equivalent of “Form Field Name” or “Label Text” that are used by other form entry technologies. Bahmni happens to be engineered to use Concept short names as their mechanism for customizing the specific label/text for a given question and/or answer. If we are concerned about the manner in which these form presentations are being managed, then we have even bigger issues in the world of htmlformentry, where the vast majority of display names for questions and answers is likely not in a format that could easily be extracted, or even associated with the Concepts being used (it is simply loose text in the html). Not that we should follow that example, but you should know that this is a far bigger issue if you view this kind of Concept naming as significant.
We are not just talking about “engineers translating the UI”, but rather the people performing the translations in Transifex are often clinicians who already have translated versions of the paper forms in their own languages, and are ensuring these are accurately represented in the electronic system.
It is really important to separate the “field name” from the actual default concept description which is the concept_name. Sounds like these might be good translations, but terminology does not come naturally to clinicians (as we have seen) so the sooner that we coordinate strategy with the team, the better (to make the effort more usable and successful).
