| Message ID | 1501482928-45952-1-git-send-email-akhilesh.k@samsung.com |
|---|---|
| State | New |
| Headers | show |
Akhilesh Kumar <akhilesh.k@samsung.com> wrote: > Fix yesexpr for en_DK > > [#BZ 21867 ] > locales/en_DK (LC_MESSAGES) : Fix yesexpr > --- > localedata/locales/en_DK | 5 +---- > 1 files changed, 1 insertions(+), 4 deletions(-) > > diff --git a/localedata/locales/en_DK b/localedata/locales/en_DK > index 351c84b..2087786 100644 > --- a/localedata/locales/en_DK > +++ b/localedata/locales/en_DK > @@ -128,10 +128,7 @@ first_weekday 2 > END LC_TIME > > LC_MESSAGES > -yesexpr "<U005E><U005B><U002B><U0031><U004A><U006A><U0073><U0053><U0079><U0059><U006F><U004F><U005D>" > -noexpr "<U005E><U005B><U002D><U0030><U006E><U004E><U005D>" > -yesstr "<U0079><U0065><U0073>" > -nostr "<U006E><U006F>" > +copy "en_US" > END LC_MESSAGES > > LC_PAPER decoded: diff --git a/localedata/locales/en_DK b/localedata/locales/en_DK index 351c84b..2087786 100644 --- a/localedata/locales/en_DK +++ b/localedata/locales/en_DK @@ -128,10 +128,7 @@ first_weekday 2 END LC_TIME LC_MESSAGES -yesexpr "^[+1JjsSyYoO]" -noexpr "^[-0nN]" -yesstr "yes" -nostr "no" +copy "en_US" END LC_MESSAGES LC_PAPER Hm, first I thought that this might be a similar case to en_CA which has: LC_MESSAGES % Accept both English "Yes" and French "Oui" as Canada is bilingual. yesexpr "^[+1yYoO]" % Accept both Engish "No" and French "Non" as Canada is bilingual. noexpr "^[-0nN]" % yes - Display only the English "yes". While Canada is bilingual it would be % difficult to display two words e.g. yes|oui, where one word is expected. % Thus given that the majority of the population is Anglophone we use only % the English word for yesstr. yesstr "yes" % no - Display only the English "no". See the rationale for yesstr. nostr "no" END LC_MESSAGES But in Danish, "yes" would be "ja" and "no" would be "nej". So yesexpr "^[+1jJyY]" might make sense, but I have no idea where "sSoO" could come from. Apparently not from Faroese or Greenlandic either (These are recognized minority languages in Denmark). Checking with git blame shows me that en_DK always had these yesexpr and noexpr. So this seems to me just a mistake and “copy "en_US"” is probably OK.
>decoded: > > diff --git a/localedata/locales/en_DK b/localedata/locales/en_DK > index 351c84b..2087786 100644 > --- a/localedata/locales/en_DK > +++ b/localedata/locales/en_DK > @@ -128,10 +128,7 @@ first_weekday 2 > END LC_TIME > > LC_MESSAGES > -yesexpr "^[+1JjsSyYoO]" > -noexpr "^[-0nN]" > -yesstr "yes" > -nostr "no" > +copy "en_US" > END LC_MESSAGES > > LC_PAPER > >Hm, first I thought that this might be a similar case to en_CA which has: > > LC_MESSAGES > % Accept both English "Yes" and French "Oui" as Canada is bilingual. > yesexpr "^[+1yYoO]" > % Accept both Engish "No" and French "Non" as Canada is bilingual. > noexpr "^[-0nN]" > % yes - Display only the English "yes". While Canada is bilingual it would be > % difficult to display two words e.g. yes|oui, where one word is expected. > % Thus given that the majority of the population is Anglophone we use only > % the English word for yesstr. > yesstr "yes" > % no - Display only the English "no". See the rationale for yesstr. > nostr "no" > END LC_MESSAGES > >But in Danish, "yes" would be "ja" and "no" would be "nej". >So > > yesexpr "^[+1jJyY]" > >might make sense, but I have no idea where "sSoO" could come >from. Apparently not from Faroese or Greenlandic either (These are >recognized minority languages in Denmark). > >Checking with git blame shows me that en_DK always had these yesexpr and >noexpr. > >So this seems to me just a mistake and “copy "en_US"” is probably OK. sS is in Spanish "si" yY is in English "yes" I believe my changes are ok
AKHILESH KUMAR <akhilesh.k@samsung.com> wrote: >>decoded: >> >> diff --git a/localedata/locales/en_DK b/localedata/locales/en_DK >> index 351c84b..2087786 100644 >> --- a/localedata/locales/en_DK >> +++ b/localedata/locales/en_DK >> @@ -128,10 +128,7 @@ first_weekday 2 >> END LC_TIME >> >> LC_MESSAGES >> -yesexpr "^[+1JjsSyYoO]" >> -noexpr "^[-0nN]" >> -yesstr "yes" >> -nostr "no" >> +copy "en_US" >> END LC_MESSAGES >> >> LC_PAPER >> >>Hm, first I thought that this might be a similar case to en_CA which has: >> >> LC_MESSAGES >> % Accept both English "Yes" and French "Oui" as Canada is bilingual. >> yesexpr "^[+1yYoO]" >> % Accept both Engish "No" and French "Non" as Canada is bilingual. >> noexpr "^[-0nN]" >> % yes - Display only the English "yes". While Canada is bilingual it would be >> % difficult to display two words e.g. yes|oui, where one word is expected. >> % Thus given that the majority of the population is Anglophone we use only >> % the English word for yesstr. >> yesstr "yes" >> % no - Display only the English "no". See the rationale for yesstr. >> nostr "no" >> END LC_MESSAGES >> >>But in Danish, "yes" would be "ja" and "no" would be "nej". >>So >> >> yesexpr "^[+1jJyY]" >> >>might make sense, but I have no idea where "sSoO" could come >>from. Apparently not from Faroese or Greenlandic either (These are >>recognized minority languages in Denmark). >> >>Checking with git blame shows me that en_DK always had these yesexpr and >>noexpr. >> >>So this seems to me just a mistake and “copy "en_US"” is probably OK. > > sS is in Spanish "si" > yY is in English "yes" Yes, and oO could come from French. But why Spanish and French in the yesexpr of en_DK> > I believe my changes are ok Yes,I think so, I could not find any reasons for this in the git log either, so I think it is just a mistake.
Mike FABIAN <mfabian@redhat.com> wrote: > AKHILESH KUMAR <akhilesh.k@samsung.com> wrote: > >>>decoded: >>> >>> diff --git a/localedata/locales/en_DK b/localedata/locales/en_DK >>> index 351c84b..2087786 100644 >>> --- a/localedata/locales/en_DK >>> +++ b/localedata/locales/en_DK >>> @@ -128,10 +128,7 @@ first_weekday 2 >>> END LC_TIME >>> >>> LC_MESSAGES >>> -yesexpr "^[+1JjsSyYoO]" >>> -noexpr "^[-0nN]" >>> -yesstr "yes" >>> -nostr "no" >>> +copy "en_US" >>> END LC_MESSAGES >>> >>> LC_PAPER >>> >>>Hm, first I thought that this might be a similar case to en_CA which has: >>> >>> LC_MESSAGES >>> % Accept both English "Yes" and French "Oui" as Canada is bilingual. >>> yesexpr "^[+1yYoO]" >>> % Accept both Engish "No" and French "Non" as Canada is bilingual. >>> noexpr "^[-0nN]" >>> % yes - Display only the English "yes". While Canada is bilingual it would be >>> % difficult to display two words e.g. yes|oui, where one word is expected. >>> % Thus given that the majority of the population is Anglophone we use only >>> % the English word for yesstr. >>> yesstr "yes" >>> % no - Display only the English "no". See the rationale for yesstr. >>> nostr "no" >>> END LC_MESSAGES >>> >>>But in Danish, "yes" would be "ja" and "no" would be "nej". >>>So >>> >>> yesexpr "^[+1jJyY]" >>> >>>might make sense, but I have no idea where "sSoO" could come >>>from. Apparently not from Faroese or Greenlandic either (These are >>>recognized minority languages in Denmark). >>> >>>Checking with git blame shows me that en_DK always had these yesexpr and >>>noexpr. >>> >>>So this seems to me just a mistake and “copy "en_US"” is probably OK. >> >> sS is in Spanish "si" >> yY is in English "yes" > > Yes, and oO could come from French. But why Spanish and French > in the yesexpr of en_DK> > >> I believe my changes are ok > > Yes,I think so, I could not find any reasons for this in the git log > either, so I think it is just a mistake. committed.
On 08/03/2017 10:54 AM, Mike FABIAN wrote: > Yes,I think so, I could not find any reasons for this in the git log > either, so I think it is just a mistake. The reason is that en_DK is used outside Denmark, as some sort of generic continental European English locale. Thanks, Florian
Florian Weimer <fweimer@redhat.com> wrote: > On 08/03/2017 10:54 AM, Mike FABIAN wrote: >> Yes,I think so, I could not find any reasons for this in the git log >> either, so I think it is just a mistake. > > The reason is that en_DK is used outside Denmark, as some sort of > generic continental European English locale. I reverted that patch and commented in the locale source why we want it like this.
3.08.2017 12:23 Florian Weimer <fweimer@redhat.com> wrote: > > > On 08/03/2017 10:54 AM, Mike FABIAN wrote: > > Yes,I think so, I could not find any reasons for this in the git log > > either, so I think it is just a mistake. > > The reason is that en_DK is used outside Denmark, as some sort of > generic continental European English locale. With all due respect, I can't see any reason why _DK was chosen to represent a generic continental European English locale. If such locale is actually needed, shouldn't we introduce en_EU instead? _EU can be understood either as Europe or as European Union, both could be assumed valid. On the other hand, we have multiple locale categories (LC_MESSAGES, LC_MONETARY etc.) to let the users choose that, for example, they want English messages while monetary and other measures specific for their proper countries. Can we introduce en_EU even if there is no ISO regulation defining EU as a territory/country/etc.? Regards, Rafal
On 08/08/2017 09:12 PM, Rafal Luzynski wrote: > 3.08.2017 12:23 Florian Weimer <fweimer@redhat.com> wrote: >> >> >> On 08/03/2017 10:54 AM, Mike FABIAN wrote: >>> Yes,I think so, I could not find any reasons for this in the git log >>> either, so I think it is just a mistake. >> >> The reason is that en_DK is used outside Denmark, as some sort of >> generic continental European English locale. > > With all due respect, I can't see any reason why _DK was chosen > to represent a generic continental European English locale. It predates the EU and the ISO reservation. > If such locale is actually needed, shouldn't we introduce en_EU > instead? _EU can be understood either as Europe or as European > Union, both could be assumed valid. ISO writes this about “EU”: “Refers to European Union and reserved at the request of ISO 4217/MA (March 1998) for ISO 6166, Securities - International securities identification numbering system (ISIN).” (See <https://www.iso.org/obp/ui/> under Country codes/Other codes/Exceptionally reserved.) Thanks, Florian
10.08.2017 14:43 Florian Weimer <fweimer@redhat.com> wrote: > > > On 08/08/2017 09:12 PM, Rafal Luzynski wrote: > > [...] > > With all due respect, I can't see any reason why _DK was chosen > > to represent a generic continental European English locale. > > It predates the EU and the ISO reservation. > > > If such locale is actually needed, shouldn't we introduce en_EU > > instead? _EU can be understood either as Europe or as European > > Union, both could be assumed valid. > > ISO writes this about “EU”: > > “Refers to European Union and reserved at the request of ISO 4217/MA > (March 1998) for ISO 6166, Securities - International securities > identification numbering system (ISIN).” > > (See <https://www.iso.org/obp/ui/> under Country codes/Other > codes/Exceptionally reserved.) Looks good. If I understand correctly, your opinion about my idea is "rather yes". I'll think about it a little longer and unless there are any opposite opinions I'll eventually introduce en_EU. It should include common features of as many as possible European countries. I am not going to remove en_DK although some of its sections may be reduced to "copy en_EU" and some features which are neither specific to English language nor Denmark (like attempts to support other European languages) may be removed. Regards, Rafal
On 08/17/2017 11:35 PM, Rafal Luzynski wrote: > 10.08.2017 14:43 Florian Weimer <fweimer@redhat.com> wrote: >> >> >> On 08/08/2017 09:12 PM, Rafal Luzynski wrote: >>> [...] >>> With all due respect, I can't see any reason why _DK was chosen >>> to represent a generic continental European English locale. >> >> It predates the EU and the ISO reservation. >> >>> If such locale is actually needed, shouldn't we introduce en_EU >>> instead? _EU can be understood either as Europe or as European >>> Union, both could be assumed valid. >> >> ISO writes this about “EU”: >> >> “Refers to European Union and reserved at the request of ISO 4217/MA >> (March 1998) for ISO 6166, Securities - International securities >> identification numbering system (ISIN).” >> >> (See <https://www.iso.org/obp/ui/> under Country codes/Other >> codes/Exceptionally reserved.) > > Looks good. If I understand correctly, your opinion about my idea > is "rather yes". Yes, I think using EU in locale identifiers makes sense. Thanks, Florian
18.08.2017 11:11 Florian Weimer <fweimer@redhat.com> wrote: > > > On 08/17/2017 11:35 PM, Rafal Luzynski wrote: > > 10.08.2017 14:43 Florian Weimer <fweimer@redhat.com> wrote: > >> > >> > >> On 08/08/2017 09:12 PM, Rafal Luzynski wrote: > >>> [...] > >>> With all due respect, I can't see any reason why _DK was chosen > >>> to represent a generic continental European English locale. > >> > >> It predates the EU and the ISO reservation. > >> > >>> If such locale is actually needed, shouldn't we introduce en_EU > >>> instead? _EU can be understood either as Europe or as European > >>> Union, both could be assumed valid. > >> > >> ISO writes this about “EU”: > >> > >> “Refers to European Union and reserved at the request of ISO 4217/MA > >> (March 1998) for ISO 6166, Securities - International securities > >> identification numbering system (ISIN).” > >> > >> (See <https://www.iso.org/obp/ui/> under Country codes/Other > >> codes/Exceptionally reserved.) > > > > Looks good. If I understand correctly, your opinion about my idea > > is "rather yes". > > Yes, I think using EU in locale identifiers makes sense. Filed here: https://sourceware.org/bugzilla/show_bug.cgi?id=22473 Regards, Rafal
diff --git a/localedata/locales/en_DK b/localedata/locales/en_DK index 351c84b..2087786 100644 --- a/localedata/locales/en_DK +++ b/localedata/locales/en_DK @@ -128,10 +128,7 @@ first_weekday 2 END LC_TIME LC_MESSAGES -yesexpr "<U005E><U005B><U002B><U0031><U004A><U006A><U0073><U0053><U0079><U0059><U006F><U004F><U005D>" -noexpr "<U005E><U005B><U002D><U0030><U006E><U004E><U005D>" -yesstr "<U0079><U0065><U0073>" -nostr "<U006E><U006F>" +copy "en_US" END LC_MESSAGES LC_PAPER