It's a significant issue.
People haven't typically run into it yet because up until recently
nobody has been sharing metadata in a way that's more sophisticated
than sql dumps.
I think we may already have multiple GPs, actually.
(I assume the default OpenMRS distribution includes en_GB but not
en_US as locales a user can choose, but only en for the concept
dictionary. But I could be wrong.)
-Darius
On Mon, Aug 8, 2011 at 11:18 AM, Michael Seaton <[email protected]
<mailto:[email protected]>> wrote:
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]>
[mailto:[email protected]] *On Behalf Of *Darius Jazayeri
*Sent:* Wednesday, August 03, 2011 7:02 PM
*To:* [email protected]
<mailto:[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
------------------------------------------------------------------------
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
