* [PATCH 1/1] Fix yesexpr in en_DK locale
[not found] <CGME20170731063951epcas5p3d3910a93ab4af53aac061b7e5c04b4a6@epcas5p3.samsung.com>
@ 2017-07-31 8:49 ` Akhilesh Kumar
2017-08-02 17:11 ` Mike FABIAN
[not found] ` <CGME20170731063951epcas5p3d3910a93ab4af53aac061b7e5c04b4a6@epcms5p5>
0 siblings, 2 replies; 12+ messages in thread
From: Akhilesh Kumar @ 2017-07-31 8:49 UTC (permalink / raw)
To: libc-alpha; +Cc: 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] Fix yesexpr in en_DK locale
2017-07-31 8:49 ` [PATCH 1/1] Fix yesexpr in en_DK locale Akhilesh Kumar
@ 2017-08-02 17:11 ` Mike FABIAN
[not found] ` <CGME20170731063951epcas5p3d3910a93ab4af53aac061b7e5c04b4a6@epcms5p5>
1 sibling, 0 replies; 12+ messages in thread
From: Mike FABIAN @ 2017-08-02 17:11 UTC (permalink / raw)
To: Akhilesh Kumar; +Cc: libc-alpha
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>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] Fix yesexpr in en_DK locale
[not found] ` <CGME20170731063951epcas5p3d3910a93ab4af53aac061b7e5c04b4a6@epcms5p5>
@ 2017-08-03 3:40 ` AKHILESH KUMAR
2017-08-03 8:54 ` Mike FABIAN
0 siblings, 1 reply; 12+ messages in thread
From: AKHILESH KUMAR @ 2017-08-03 3:40 UTC (permalink / raw)
To: Mike FABIAN; +Cc: libc-alpha
[-- 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
=================================================================================================================================
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] Fix yesexpr in en_DK locale
2017-08-03 3:40 ` AKHILESH KUMAR
@ 2017-08-03 8:54 ` Mike FABIAN
2017-08-03 10:17 ` Mike FABIAN
2017-08-03 10:24 ` Florian Weimer
0 siblings, 2 replies; 12+ messages in thread
From: Mike FABIAN @ 2017-08-03 8:54 UTC (permalink / raw)
To: AKHILESH KUMAR; +Cc: libc-alpha
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>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] Fix yesexpr in en_DK locale
2017-08-03 8:54 ` Mike FABIAN
@ 2017-08-03 10:17 ` Mike FABIAN
2017-08-03 10:24 ` Florian Weimer
1 sibling, 0 replies; 12+ messages in thread
From: Mike FABIAN @ 2017-08-03 10:17 UTC (permalink / raw)
To: AKHILESH KUMAR; +Cc: libc-alpha
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>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] Fix yesexpr in en_DK locale
2017-08-03 8:54 ` Mike FABIAN
2017-08-03 10:17 ` Mike FABIAN
@ 2017-08-03 10:24 ` Florian Weimer
2017-08-03 11:47 ` Mike FABIAN
2017-08-08 19:12 ` Introduce en_EU? (was: [PATCH 1/1] Fix yesexpr in en_DK locale) Rafal Luzynski
1 sibling, 2 replies; 12+ messages in thread
From: Florian Weimer @ 2017-08-03 10:24 UTC (permalink / raw)
To: Mike Fabian; +Cc: libc-alpha, Akhilesh Kumar
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/1] Fix yesexpr in en_DK locale
2017-08-03 10:24 ` Florian Weimer
@ 2017-08-03 11:47 ` Mike FABIAN
2017-08-08 19:12 ` Introduce en_EU? (was: [PATCH 1/1] Fix yesexpr in en_DK locale) Rafal Luzynski
1 sibling, 0 replies; 12+ messages in thread
From: Mike FABIAN @ 2017-08-03 11:47 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-alpha, Akhilesh Kumar
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>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Introduce en_EU? (was: [PATCH 1/1] Fix yesexpr in en_DK locale)
2017-08-03 10:24 ` Florian Weimer
2017-08-03 11:47 ` Mike FABIAN
@ 2017-08-08 19:12 ` Rafal Luzynski
2017-08-10 12:43 ` Introduce en_EU? Florian Weimer
1 sibling, 1 reply; 12+ messages in thread
From: Rafal Luzynski @ 2017-08-08 19:12 UTC (permalink / raw)
To: Mike Fabian, Florian Weimer; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Introduce en_EU?
2017-08-08 19:12 ` Introduce en_EU? (was: [PATCH 1/1] Fix yesexpr in en_DK locale) Rafal Luzynski
@ 2017-08-10 12:43 ` Florian Weimer
2017-08-17 21:35 ` Rafal Luzynski
0 siblings, 1 reply; 12+ messages in thread
From: Florian Weimer @ 2017-08-10 12:43 UTC (permalink / raw)
To: Rafal Luzynski, Mike Fabian; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Introduce en_EU?
2017-08-10 12:43 ` Introduce en_EU? Florian Weimer
@ 2017-08-17 21:35 ` Rafal Luzynski
2017-08-18 9:11 ` Florian Weimer
0 siblings, 1 reply; 12+ messages in thread
From: Rafal Luzynski @ 2017-08-17 21:35 UTC (permalink / raw)
To: Mike Fabian, Florian Weimer; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Introduce en_EU?
2017-08-17 21:35 ` Rafal Luzynski
@ 2017-08-18 9:11 ` Florian Weimer
2017-11-22 6:38 ` Rafal Luzynski
0 siblings, 1 reply; 12+ messages in thread
From: Florian Weimer @ 2017-08-18 9:11 UTC (permalink / raw)
To: Rafal Luzynski, Mike Fabian; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Introduce en_EU?
2017-08-18 9:11 ` Florian Weimer
@ 2017-11-22 6:38 ` Rafal Luzynski
0 siblings, 0 replies; 12+ messages in thread
From: Rafal Luzynski @ 2017-11-22 6:38 UTC (permalink / raw)
To: Mike Fabian, Florian Weimer; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-11-22 6:38 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CGME20170731063951epcas5p3d3910a93ab4af53aac061b7e5c04b4a6@epcas5p3.samsung.com>
2017-07-31 8:49 ` [PATCH 1/1] Fix yesexpr in en_DK locale Akhilesh Kumar
2017-08-02 17:11 ` Mike FABIAN
[not found] ` <CGME20170731063951epcas5p3d3910a93ab4af53aac061b7e5c04b4a6@epcms5p5>
2017-08-03 3:40 ` AKHILESH KUMAR
2017-08-03 8:54 ` Mike FABIAN
2017-08-03 10:17 ` Mike FABIAN
2017-08-03 10:24 ` Florian Weimer
2017-08-03 11:47 ` Mike FABIAN
2017-08-08 19:12 ` Introduce en_EU? (was: [PATCH 1/1] Fix yesexpr in en_DK locale) Rafal Luzynski
2017-08-10 12:43 ` Introduce en_EU? Florian Weimer
2017-08-17 21:35 ` Rafal Luzynski
2017-08-18 9:11 ` Florian Weimer
2017-11-22 6:38 ` Rafal Luzynski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).