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