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]> 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] <[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]> > 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] > Mobile: +1 (646) 469-2421 > Office: +1 (212) 305-4842 > Skype: akanter-ippnw > Yahoo: andy_kanter**** > ------------------------------ > > *From:* Wyclif Luyima <[email protected]> > *To:* [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]> 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] with "SIGNOFF openmrs-devel-l" in the body > (not the subject) of your e-mail. > > [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]**** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > > ------------------------------ > Click here to > unsubscribe<[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]
