[PATCH 1/1] Fix yesexpr in en_DK locale

[PATCH 1/1] Fix yesexpr in en_DK locale

[Akhilesh Kumar]

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
-- 
1.7.1

Re: [PATCH 1/1] Fix yesexpr in en_DK locale

[Mike FABIAN]

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.

-- 
Mike FABIAN <mfabian@redhat.com>

Re: [PATCH 1/1] Fix yesexpr in en_DK locale

[AKHILESH KUMAR]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

>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

[-- Attachment #2: rcptInfo.txt --]
[-- Type: application/octet-stream, Size: 1000 bytes --]


   =================================================================================================================================
      Subject    : Re: [PATCH 1/1] Fix yesexpr in  en_DK locale
      From       : null
      Sent Date  : 2017-08-02 22:41  GMT+5:30
   =================================================================================================================================
                  Name                Type          Job Title                       Dept.                               Company                
   =================================================================================================================================
      AKHILESH KUMAR                 TO         Chief Engineer             SRI-Delhi-Platform S/W 1 Team             Samsung Electronics
      libc-alpha@sourceware.org      CC
   =================================================================================================================================

Re: [PATCH 1/1] Fix yesexpr in en_DK locale

[Mike FABIAN]

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>

Re: [PATCH 1/1] Fix yesexpr in en_DK locale

[Mike FABIAN]

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.

-- 
Mike FABIAN <mfabian@redhat.com>

Re: [PATCH 1/1] Fix yesexpr in en_DK locale

[Florian Weimer]

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

Re: [PATCH 1/1] Fix yesexpr in en_DK locale

[Mike FABIAN]

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.

-- 
Mike FABIAN <mfabian@redhat.com>

Introduce en_EU? (was: [PATCH 1/1] Fix yesexpr in en_DK locale)

[Rafal Luzynski]

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

Re: Introduce en_EU?

[Florian Weimer]

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

Re: Introduce en_EU?

[Rafal Luzynski]

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

Re: Introduce en_EU?

[Florian Weimer]

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

Re: Introduce en_EU?

[Rafal Luzynski]

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