This is an unfortunate situation. Are we saying that in order to
support both US (or default English) and GB variations in our Concept
Dictionary, we need these to be in our allowed_locales list? But by
having these in our allowed_locales list we are forced to give these to
the user as options? And sadly, in order to have dates formatted as
dd/MM/yyyy we need our users to choose en_GB and for this to be the
default? And even more sadly, if a user chooses en_US or en, then they
will read 07/08/2011 differently from a user who happens to be using the
en_GB locale?
This is a mess, particularly since I believe en_US and en_GB are
included by default for all OpenMRS installations.
Does anyone know if there is already work underway (or completed), or a
ticket created to separate out the notions of date formatting,
user-supported language selection, and supported locales for concept
name management? If not, I will be happy to create some. Does anyone
else have opinions on this? Am I blowing it out of proportion?
Thanks,
Mike
On 08/04/2011 09:56 AM, Mark Goodrich wrote:
The issue here is that we are setting the current locale on the Haiti
production servers to en_GB because we want to use to European date
format dd/mm/yyyy.
I think the solution is that we should add the locale “en” to the list
of allowed locales on the Haiti system, but keep the default locale
set to en_GB. Then, when we add new concepts, we should be careful to
make sure we are setting the “en” name instead of the “en_GB” (because
the UI will default to the “en_GB” name).
Mark
*From:*[email protected] [mailto:[email protected]] *On Behalf Of *Darius
Jazayeri
*Sent:* Wednesday, August 03, 2011 7:02 PM
*To:* [email protected]
*Subject:* Re: [OPENMRS-DEV] Locale on concept_name
Ellen,
As Andy says, the correct approach is for you to create concept names
with the locale "en" with the standard English name. (And since your
implementations are US-English-based, you can just put US-English
spellings in names with locale=en.) OpenMRS should choose the
appropriate concept name for the user's current locale, by first
trying the locale+country, and then falling back to just locale. (I
believe this is implemented in 1.8.)
So, don't go and change all your concept names. This seems like a
Metadata Sharing module bug, not an error in your concept dictionary.
-Darius
On Wed, Aug 3, 2011 at 2:59 PM, Andrew Kanter <[email protected]
<mailto:[email protected]>> wrote:
I don't think you want to remove the distinction between en_GB and
en_US. Where the term is the same in both, the en would apply. If the
term specifies en_GB or en_US it should mean that there is a different
term in the other locale.
I would love to have someone smarter than I go over the issues with
localization. It seems that there should be an automatic failover...
if there is a term with a specified locale (en_GB) it should be used,
but if there isn't, then a term with the more generic locale (en)
should be used.
I am not sure why metadata sharing should care about allowable
locales. The inbound concept should come over with its appropriate
locale. I don't think we want to change these during the import.
Andy
--------------------
Andrew S. Kanter, MD MPH
- Director of Health Information Systems/Medical Informatics
Millennium Villages Project, Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University
Email: [email protected]
<mailto:[email protected]>
Mobile: +1 (646) 469-2421 <tel:%2B1%20%28646%29%20469-2421>
Office: +1 (212) 305-4842 <tel:%2B1%20%28212%29%20305-4842>
Skype: akanter-ippnw
Yahoo: andy_kanter
------------------------------------------------------------------------
*From:*Wyclif Luyima <[email protected] <mailto:[email protected]>>
*To:* [email protected]
<mailto:[email protected]>
*Sent:* Wednesday, August 3, 2011 5:23 PM
*Subject:* Re: [OPENMRS-DEV] Locale on concept_name
Technically 'en' is considered to be different from 'en_GB' and
'en_US', there are few sections of the application that might loosen
on this, i can't seem to recall any right now.
It should be fine if you updated all 'en_GB' and
'en_US' occurrences to 'en' in the 'concept_name.locale' column and
probably update 'en_GB' and 'en_US' values to 'en' for
locale.allowed.list.
Wyclif
On Wed, Aug 3, 2011 at 4:43 PM, Ellen Ball <[email protected]
<mailto:[email protected]>> wrote:
Is there a default standard for concept_name.locale? Should we use 'en',
'en_US' or 'en_GB'? I've landed on a problem with metadata sharing of
concepts, and believe the problem is that one system is using
locale.allowed.list = 'en_GB,fr', and the other system has
locale.allowed.list =
'en,fr,rw' (META-112). (I'm not sure if the bug is related to the
locale.)
I am aware that there are reasons to use en_US or en_GB for
'hemorrhage' or
'haemorrhage'. However we normally use the American spellings. Should we
use plain 'en'?
We are using various locales when we mean the same thing (en, en_US and
en_GB). If I change from 'en_GB' to 'en', what else would be
affected? Will
this change how dates are handled? How should this work with metadata
sharing? If I import a concept with the same uuid, will it change the
concept_name.locale on the importing server?
Perhaps this has previously been discussed, so apologies if this is
repetitive. If
this is clear to someone, I'd be grateful if it was documented on the
OpenMRS
wiki.
Regards,
Ellen Ball
Partners In Health
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail
to [email protected] <mailto:[email protected]>
with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your
e-mail.
[mailto:[email protected]
<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l]
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
