* English locale for Europe – en_150 @ 2020-07-06 23:38 Eidur Eidsson 2020-07-07 0:28 ` Carlos O'Donell 2020-07-07 17:28 ` English locale for Europe ? en_150 Keld Simonsen 0 siblings, 2 replies; 7+ messages in thread From: Eidur Eidsson @ 2020-07-06 23:38 UTC (permalink / raw) To: libc-locales Hello to you all and thank you for your efforts I have been wondering whether it would be feasible to include the locale "en_150" in glibc. This is a standard CLDR/ICU-defined locale (not a personal invention) that has been mentioned here before: https://sourceware.org/legacy-ml/libc-locales/2016-q2/msg00245.html . I have prepared the following prototype by visually inspecting the ICU demonstration at https://icu4c-demos-7hxm2n5zgq-uc.a.run.app/icu-bin/locexp . Of course it would be better to automatically derive the locale from the library itself, but this shows what it could look like. The only immediate problem I can see is the use of "XXX" as a currency code. Perhaps "EUR" could be used instead (and "@euro" appended to the name) although this is strictly not an EU locale. ---------- comment_char % escape_char / % This file is part of the GNU C Library and contains locale data. % The Free Software Foundation does not claim any copyright interest % in the locale data contained in this file. The foregoing does not % affect the license of the GNU C Library as a whole. It does not % exempt you from the conditions of the license if your use would % otherwise be governed by that license. % This locale is based on English for region 150 within ICU (icu-project.org). It is characterized by a decimal point, 24-hour clock, little-endian dates, and ISO week-numbering. LC_IDENTIFICATION title "English locale for Europe" source "Free Software Foundation, Inc." address "https:////www.gnu.org//software//libc//" contact "" email "bug-glibc-locales@gnu.org" tel "" fax "" language "English" territory "Europe" revision "0.1" date "2020-07-06" category "i18n:2012";LC_IDENTIFICATION category "i18n:2012";LC_CTYPE category "i18n:2012";LC_COLLATE category "i18n:2012";LC_TIME category "i18n:2012";LC_NUMERIC category "i18n:2012";LC_MONETARY category "i18n:2012";LC_MESSAGES category "i18n:2012";LC_PAPER category "i18n:2012";LC_NAME category "i18n:2012";LC_ADDRESS category "i18n:2012";LC_TELEPHONE category "i18n:2012";LC_MEASUREMENT END LC_IDENTIFICATION LC_CTYPE copy "i18n" END LC_CTYPE LC_COLLATE copy "iso14651_t1" END LC_COLLATE LC_MONETARY int_curr_symbol "XXX "%causes a warning% currency_symbol "<U00A4>" mon_decimal_point "." mon_thousands_sep "," mon_grouping 3;3 positive_sign "" negative_sign "-" int_frac_digits 2 frac_digits 2 p_cs_precedes 0 p_sep_by_space 1 n_cs_precedes 0 n_sep_by_space 1 p_sign_posn 1 n_sign_posn 1 END LC_MONETARY LC_NUMERIC decimal_point "." thousands_sep "," grouping 3;3 END LC_NUMERIC LC_TIME abday "Sun";"Mon";"Tue";"Wed";"Thu";"Fri";"Sat" day "Sunday";/ "Monday";/ "Tuesday";/ "Wednesday";/ "Thursday";/ "Friday";/ "Saturday" abmon "Jan";"Feb";/ "Mar";"Apr";/ "May";"Jun";/ "Jul";"Aug";/ "Sep";"Oct";/ "Nov";"Dec" mon "January";/ "February";/ "March";/ "April";/ "May";/ "June";/ "July";/ "August";/ "September";/ "October";/ "November";/ "December" d_t_fmt "%A, %e %B %Y %T" date_fmt "%A, %e %B %Y %T %Z" d_fmt "%d//%m//%Y" t_fmt "%T" am_pm "am";"pm" t_fmt_ampm "" first_weekday 2 week 7;19971201;1 END LC_TIME LC_MESSAGES yesexpr "^[+1yY]" noexpr "^[-0nN]" yesstr "yes" nostr "no" END LC_MESSAGES LC_PAPER copy "i18n" END LC_PAPER LC_TELEPHONE copy "i18n" END LC_TELEPHONE LC_MEASUREMENT copy "i18n" END LC_MEASUREMENT LC_NAME copy "i18n" END LC_NAME LC_ADDRESS copy "i18n" END LC_ADDRESS ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: English locale for Europe – en_150 2020-07-06 23:38 English locale for Europe – en_150 Eidur Eidsson @ 2020-07-07 0:28 ` Carlos O'Donell 2020-07-07 1:36 ` Eidur Eidsson 2020-07-07 17:28 ` English locale for Europe ? en_150 Keld Simonsen 1 sibling, 1 reply; 7+ messages in thread From: Carlos O'Donell @ 2020-07-07 0:28 UTC (permalink / raw) To: Eidur Eidsson, libc-locales On 7/6/20 7:38 PM, Eidur Eidsson via Libc-locales wrote: > Hello to you all and thank you for your efforts > > I have been wondering whether it would be feasible to include the > locale "en_150" in glibc. This is a standard CLDR/ICU-defined locale > (not a personal invention) that has been mentioned here before: > https://sourceware.org/legacy-ml/libc-locales/2016-q2/msg00245.html > . > > I have prepared the following prototype by visually inspecting the > ICU demonstration at > https://icu4c-demos-7hxm2n5zgq-uc.a.run.app/icu-bin/locexp . Of > course it would be better to automatically derive the locale from the > library itself, but this shows what it could look like. The only > immediate problem I can see is the use of "XXX" as a currency code. > Perhaps "EUR" could be used instead (and "@euro" appended to the > name) although this is strictly not an EU locale. Thanks for submitting this work. We are currently in the freeze period for glibc 2.32 which will release on August 1st, and so many developers are busy with the release. Is it OK to wait until after August 1st to resume this discussion and review the changes for glibc 2.33? -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: English locale for Europe – en_150 2020-07-07 0:28 ` Carlos O'Donell @ 2020-07-07 1:36 ` Eidur Eidsson 0 siblings, 0 replies; 7+ messages in thread From: Eidur Eidsson @ 2020-07-07 1:36 UTC (permalink / raw) To: Carlos O'Donell, libc-locales Absolutely, there is no need to rush with this matter. In any case, there is not much more that I can add. This is merely a suggestion and the draft might contain errors. ________________________________ From: Carlos O'Donell <carlos@redhat.com> Sent: Tuesday, July 7, 2020 12:28 AM To: Eidur Eidsson <eidurkr@outlook.com>; libc-locales@sourceware.org <libc-locales@sourceware.org> Subject: Re: English locale for Europe – en_150 On 7/6/20 7:38 PM, Eidur Eidsson via Libc-locales wrote: > Hello to you all and thank you for your efforts > > I have been wondering whether it would be feasible to include the > locale "en_150" in glibc. This is a standard CLDR/ICU-defined locale > (not a personal invention) that has been mentioned here before: > https://sourceware.org/legacy-ml/libc-locales/2016-q2/msg00245.html > . > > I have prepared the following prototype by visually inspecting the > ICU demonstration at > https://icu4c-demos-7hxm2n5zgq-uc.a.run.app/icu-bin/locexp . Of > course it would be better to automatically derive the locale from the > library itself, but this shows what it could look like. The only > immediate problem I can see is the use of "XXX" as a currency code. > Perhaps "EUR" could be used instead (and "@euro" appended to the > name) although this is strictly not an EU locale. Thanks for submitting this work. We are currently in the freeze period for glibc 2.32 which will release on August 1st, and so many developers are busy with the release. Is it OK to wait until after August 1st to resume this discussion and review the changes for glibc 2.33? -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: English locale for Europe ? en_150 2020-07-06 23:38 English locale for Europe – en_150 Eidur Eidsson 2020-07-07 0:28 ` Carlos O'Donell @ 2020-07-07 17:28 ` Keld Simonsen 2020-07-09 22:38 ` Eidur Eidsson 1 sibling, 1 reply; 7+ messages in thread From: Keld Simonsen @ 2020-07-07 17:28 UTC (permalink / raw) To: Eidur Eidsson; +Cc: libc-locales what is the difference of this locale from the standard iso 30112 i19n locale? also what is the difference in purpose? keld On Mon, Jul 06, 2020 at 11:38:26PM +0000, Eidur Eidsson via Libc-locales wrote: > Hello to you all and thank you for your efforts > > I have been wondering whether it would be feasible to include the locale "en_150" in glibc. This is a standard CLDR/ICU-defined locale (not a personal invention) that has been mentioned here before: https://sourceware.org/legacy-ml/libc-locales/2016-q2/msg00245.html . > > I have prepared the following prototype by visually inspecting the ICU demonstration at https://icu4c-demos-7hxm2n5zgq-uc.a.run.app/icu-bin/locexp . Of course it would be better to automatically derive the locale from the library itself, but this shows what it could look like. The only immediate problem I can see is the use of "XXX" as a currency code. Perhaps "EUR" could be used instead (and "@euro" appended to the name) although this is strictly not an EU locale. > > ---------- > > comment_char % > escape_char / > > % This file is part of the GNU C Library and contains locale data. > % The Free Software Foundation does not claim any copyright interest > % in the locale data contained in this file. The foregoing does not > % affect the license of the GNU C Library as a whole. It does not > % exempt you from the conditions of the license if your use would > % otherwise be governed by that license. > > % This locale is based on English for region 150 within ICU (icu-project.org). It is characterized by a decimal point, 24-hour clock, little-endian dates, and ISO week-numbering. > > LC_IDENTIFICATION > title "English locale for Europe" > source "Free Software Foundation, Inc." > address "https:////www.gnu.org//software//libc//" > contact "" > email "bug-glibc-locales@gnu.org" > tel "" > fax "" > language "English" > territory "Europe" > revision "0.1" > date "2020-07-06" > > category "i18n:2012";LC_IDENTIFICATION > category "i18n:2012";LC_CTYPE > category "i18n:2012";LC_COLLATE > category "i18n:2012";LC_TIME > category "i18n:2012";LC_NUMERIC > category "i18n:2012";LC_MONETARY > category "i18n:2012";LC_MESSAGES > category "i18n:2012";LC_PAPER > category "i18n:2012";LC_NAME > category "i18n:2012";LC_ADDRESS > category "i18n:2012";LC_TELEPHONE > category "i18n:2012";LC_MEASUREMENT > END LC_IDENTIFICATION > > LC_CTYPE > copy "i18n" > END LC_CTYPE > > LC_COLLATE > copy "iso14651_t1" > END LC_COLLATE > > LC_MONETARY > int_curr_symbol "XXX "%causes a warning% > currency_symbol "<U00A4>" > mon_decimal_point "." > mon_thousands_sep "," > mon_grouping 3;3 > positive_sign "" > negative_sign "-" > int_frac_digits 2 > frac_digits 2 > p_cs_precedes 0 > p_sep_by_space 1 > n_cs_precedes 0 > n_sep_by_space 1 > p_sign_posn 1 > n_sign_posn 1 > END LC_MONETARY > > LC_NUMERIC > decimal_point "." > thousands_sep "," > grouping 3;3 > END LC_NUMERIC > > LC_TIME > abday "Sun";"Mon";"Tue";"Wed";"Thu";"Fri";"Sat" > day "Sunday";/ > "Monday";/ > "Tuesday";/ > "Wednesday";/ > "Thursday";/ > "Friday";/ > "Saturday" > abmon "Jan";"Feb";/ > "Mar";"Apr";/ > "May";"Jun";/ > "Jul";"Aug";/ > "Sep";"Oct";/ > "Nov";"Dec" > mon "January";/ > "February";/ > "March";/ > "April";/ > "May";/ > "June";/ > "July";/ > "August";/ > "September";/ > "October";/ > "November";/ > "December" > d_t_fmt "%A, %e %B %Y %T" > date_fmt "%A, %e %B %Y %T %Z" > d_fmt "%d//%m//%Y" > t_fmt "%T" > am_pm "am";"pm" > t_fmt_ampm "" > first_weekday 2 > week 7;19971201;1 > END LC_TIME > > LC_MESSAGES > yesexpr "^[+1yY]" > noexpr "^[-0nN]" > yesstr "yes" > nostr "no" > END LC_MESSAGES > > LC_PAPER > copy "i18n" > END LC_PAPER > > LC_TELEPHONE > copy "i18n" > END LC_TELEPHONE > > LC_MEASUREMENT > copy "i18n" > END LC_MEASUREMENT > > LC_NAME > copy "i18n" > END LC_NAME > > LC_ADDRESS > copy "i18n" > END LC_ADDRESS ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: English locale for Europe ? en_150 2020-07-07 17:28 ` English locale for Europe ? en_150 Keld Simonsen @ 2020-07-09 22:38 ` Eidur Eidsson 2020-07-12 15:57 ` Keld Simonsen 0 siblings, 1 reply; 7+ messages in thread From: Eidur Eidsson @ 2020-07-09 22:38 UTC (permalink / raw) To: Keld Simonsen; +Cc: libc-locales >what is the difference of this locale >from the standard iso 30112 i19n locale? >also what is the difference in purpose? > >keld Well, the default values in ISO 30112 are not associated with any language, so the i18n file cannot be used with locale-gen as far as I've tried. A regional locale is useful for those who want to quickly apply language-specific features while skipping most country-specific features. There are two English language CLDR locales for a region rather than a country: en_001 (world) and en_150 (Europe). Most importantly, they use a point as a decimal separator, which is not the case with i18n. They also don't display the ISO 8601 date format. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: English locale for Europe ? en_150 2020-07-09 22:38 ` Eidur Eidsson @ 2020-07-12 15:57 ` Keld Simonsen 2020-07-13 19:19 ` Eidur Eidsson 0 siblings, 1 reply; 7+ messages in thread From: Keld Simonsen @ 2020-07-12 15:57 UTC (permalink / raw) To: Eidur Eidsson; +Cc: libc-locales On Thu, Jul 09, 2020 at 10:38:20PM +0000, Eidur Eidsson wrote: > >what is the difference of this locale > >from the standard iso 30112 i18n locale? > >also what is the difference in purpose? > > > >keld > > Well, the default values in ISO 30112 are not associated with any language, so > the i18n file cannot be used with locale-gen as far as I've tried. why not? I used a similar locale to build many national locales, incl da_DK for my own language - Danish, and about 60 other. > A regional locale is useful for those who want to quickly apply language-specific > features while skipping most country-specific features. There are two English > language CLDR locales for a region rather than a country: en_001 (world) and > en_150 (Europe). Most importantly, they use a point as a decimal separator, > which is not the case with i18n. The comma is the most widely used decimal separator, only a number of English speeking countries deviate, actually many countries use a non breaking space, which i find error prone, and I have not seen it used in monetary environments - banks etc. > They also don't display the ISO 8601 date format. That is in my eyes an error, iso 8601 is a standard in most countries of the world, inc Britain. if you speak english in a non-natively English country, iso 8601 is the most likely format to be well understood. Also with the y2k problem, many international organisations decided to use iso 8601 in the future. keld ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: English locale for Europe ? en_150 2020-07-12 15:57 ` Keld Simonsen @ 2020-07-13 19:19 ` Eidur Eidsson 0 siblings, 0 replies; 7+ messages in thread From: Eidur Eidsson @ 2020-07-13 19:19 UTC (permalink / raw) To: Keld Simonsen; +Cc: libc-locales I don't want to start a spat. All we are talking about is whether to make an externally defined locale available to users. Our personal opinions on how it should look are irrelevant. In a perfect world, everyone would use ISO dates, and every human language and every programming language used the same decimal separator. But this is not the case, which is why we have locales in the first place. The locale in question, en_150, is not fully ISO compliant and probably not meant to be. It cannot suit everyone, but for some users, it may be close enough to what they prefer. It is easier to change one or two variables to "C" than to set up an intricate mix of en_US, en_GB (which oddly import from one another), and other languages. Most users have no desire to build their own locales; they just want to select one of the included ones and move on. Best regards ee >> Well, the default values in ISO 30112 are not associated with any language, so >> the i18n file cannot be used with locale-gen as far as I've tried. > why not? I used a similar locale to build many national locales, incl da_DK > for my own language - Danish, and about 60 other. >> A regional locale is useful for those who want to quickly apply language-specific >> features while skipping most country-specific features. There are two English >> language CLDR locales for a region rather than a country: en_001 (world) and >> en_150 (Europe). Most importantly, they use a point as a decimal separator, >> which is not the case with i18n. > The comma is the most widely used decimal separator, only a number of English speeking countries deviate, > actually many countries use a non breaking space, which i find error prone, and I have not seen it > used in monetary environments - banks etc. >> They also don't display the ISO 8601 date format. > That is in my eyes an error, iso 8601 is a standard in most countries of the world, inc Britain. > if you speak english in a non-natively English country, iso 8601 is the most likely format > to be well understood. Also with the y2k problem, many international organisations decided to use iso 8601 > in the future. > keld ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-07-13 19:19 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-06 23:38 English locale for Europe – en_150 Eidur Eidsson 2020-07-07 0:28 ` Carlos O'Donell 2020-07-07 1:36 ` Eidur Eidsson 2020-07-07 17:28 ` English locale for Europe ? en_150 Keld Simonsen 2020-07-09 22:38 ` Eidur Eidsson 2020-07-12 15:57 ` Keld Simonsen 2020-07-13 19:19 ` Eidur Eidsson
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).