October 2012 - i18n-bugs - Fedora Mailing-Lists

[Fedora-i18n-bugs] [Bug 858591] anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=858591 --- Comment #43 from Akira TAGOH <tagoh(a)redhat.com> --- (In reply to comment #42) > One other hack idea: how about renaming the po files to (non-standard) local > based naming: > > en.po -> en_US.po > ja.po -> ja_JP.po > : > es.po -> es_ES.po > > (all the correct locales should be listed in the old lang-table file.) > > That should at least make the current implementation work like > the old lang-table approach giving valid locales. Of course > l10n people might not like this hack. That's true. this may makes some duplicate work and files. -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 858591] anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=858591 --- Comment #42 from Jens Petersen <petersen(a)redhat.com> --- (In reply to comment #40) > but I dunno if that data is available? Does pytz have locale info? I don't think tzdata has any locale info so it will not work and anyway as you know many countries have multiple locales. One other hack idea: how about renaming the po files to (non-standard) local based naming: en.po -> en_US.po ja.po -> ja_JP.po : es.po -> es_ES.po (all the correct locales should be listed in the old lang-table file.) That should at least make the current implementation work like the old lang-table approach giving valid locales. Of course l10n people might not like this hack. Anyway just offering it as an possible alternative to reverting to lang-table, which some might still consider the safest. -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 858591] anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=858591 --- Comment #41 from Jens Petersen <petersen(a)redhat.com> --- As for F18Beta - no further new info to add. Presumably firstboot crashing for a Japanese, etc installs is not a blocker until after Beta? Anyway I really really hope this can be fixed by Beta otherwise it is not going to be good. -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 858591] anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=858591 --- Comment #40 from Jens Petersen <petersen(a)redhat.com> --- I rather like the idea of using timezone selection to also set the locale but I dunno if that data is available? Does pytz have locale info? (Right, utf8 vs UTF-8 is not an issue here - either is fine.) If there are no other possible ideas then probably reverting back to using lang-table for now is probably the simplest viable solution at this point? -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 858591] anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=858591 --- Comment #39 from Mike FABIAN <mfabian(a)redhat.com> --- (In reply to comment #34) > I still not sure how can a locale be selected which have script modifier in > it like aa_ER@saaho, de_BE@euro, ks_IN@devanagari etc. aa_ER@saaho and ks_IN@devanagari use UTF-8: mfabian@ari:~ $ LC_ALL=aa_ER@saaho mfabian@ari:~ $ LC_ALL=aa_ER@saaho locale charmap UTF-8 mfabian@ari:~ $ LC_ALL=ks_IN@devanagari locale charmap UTF-8 mfabian@ari:~ But the xx_YY@euro locales use the legacy ISO-8859-15 encoding: mfabian@ari:~ $ LC_ALL=de_BE@euro locale charmap ISO-8859-15 mfabian@ari:~ $ So it is not a good idea to use xx_YY@euro locales, these are just legacy locales and should not be set as defaults, they are useful only for special purposes. -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 858591] anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=858591 --- Comment #38 from Mike FABIAN <mfabian(a)redhat.com> --- (In reply to comment #32) > I really can't find any decent reference on utf8 vs. UTF-8, it's extremely > confusing, but I *think* everything is expected to accept either. 'locale > -a' lists the utf8 form, but the UTF-8 form always seems to be recommended > when setting LANG or whatever. A bit confusing. Yes, "UTF-8" is the preferred spelling but "utf-8" or "utf8" work as well with glibc. mfabian@ari:~ $ LC_ALL=en_US.UTF-8 locale charmap UTF-8 mfabian@ari:~ $ LC_ALL=en_US.UTF8 locale charmap UTF-8 mfabian@ari:~ $ LC_ALL=en_US.utf-8 locale charmap UTF-8 mfabian@ari:~ $ LC_ALL=en_US.utf8 locale charmap UTF-8 mfabian@ari:~ $ LC_ALL=en_US.UtF8 locale charmap UTF-8 mfabian@ari:~ $ LC_ALL=en_US.UtF---8 locale charmap UTF-8 mfabian@ari:~ When a spelling is used which does not work with glibc, an error like this is seen: mfabian@ari:~ $ LC_ALL=en_US.UTF-9 locale charmap locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968 mfabian@ari:~ $ -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 858591] anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=858591 --- Comment #37 from Mike FABIAN <mfabian(a)redhat.com> --- (In reply to comment #35) > (In reply to comment #34) > > If locale is not > > available then only like current anaconda, locale should have set like > > LANG=es.utf8 > > In fact there are no locales which don't have a territory. in that case, > should fall back to POSIX IMHO. I think falling back to en_US.UTF-8 is better in that case because using POSIX uses ASCII encoding: mfabian@ari:~ $ LC_ALL=POSIX locale charmap ANSI_X3.4-1968 mfabian@ari:~ $ LC_ALL=en_US.UTF-8 locale charmap UTF-8 mfabian@ari:~ $ Therefore, using POSIX can cause problems with display of non-ASCII stuff in some cases: mfabian@ari:~/tmp/test $ LC_ALL=en_US.UTF-8 ls täst 日本語 mfabian@ari:~/tmp/test $ LC_ALL=POSIX ls t??st ????????? mfabian@ari:~/tmp/test $ and some software then gets ASCII as the default encoding, for example when reading files. I think using en_US.UTF-8 is a better fallback. -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 858591] anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=858591 --- Comment #36 from Steve Tyler <stephent98(a)hotmail.com> --- The GNU documentation says this: 2.3.1 Locale Names "A locale name usually has the form ‘ll_CC’. Here ‘ll’ is an ISO 639 two-letter language code, and ‘CC’ is an ISO 3166 two-letter country code." http://www.gnu.org/software/gettext/manual/html_node/Locale-Names.html#Lo... The 'C' and 'POSIX' locales are exceptions to the 'll_CC' form: $ locale -a | egrep '^C|POSIX' C POSIX The locale files are text files in /usr/share/i18n/locales/. -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 858591] anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=858591 --- Comment #35 from Akira TAGOH <tagoh(a)redhat.com> --- (In reply to comment #34) > Based on timezone and language (hope user will not try to mix this to ask > non-available locale), locale can be constructed. Say for Spanish language > selected locale is anyway going to start as "es_" then based on timezone, it > can be "es_CL" or "es_ES" or any other available locale. If locale is not > available then only like current anaconda, locale should have set like > LANG=es.utf8 In fact there are no locales which don't have a territory. in that case, should fall back to POSIX IMHO. -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 6 months

1
0
0 / 0

[Fedora-i18n-bugs] [Bug 858591] anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=858591 --- Comment #34 from Parag <pnemade(a)redhat.com> --- Chris, I have not looked into source code thoroughly. How about changing a anaconda UI a bit by adding available locales once a language is selected and let the user select his own preferred locale? OR Based on timezone and language (hope user will not try to mix this to ask non-available locale), locale can be constructed. Say for Spanish language selected locale is anyway going to start as "es_" then based on timezone, it can be "es_CL" or "es_ES" or any other available locale. If locale is not available then only like current anaconda, locale should have set like LANG=es.utf8 I still not sure how can a locale be selected which have script modifier in it like aa_ER@saaho, de_BE@euro, ks_IN@devanagari etc. -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs October 2012