Red Hat Bugzilla – Bug 246325
need LANGUAGE settings for translation fallbacks
Last modified: 2013-01-09 23:22:01 EST
system-config-language is aimed at the system-wide language settings. But it should be able to set the users prefered language which may differ from the system-wide settings. It should also allow system-wide and user fallback settings for LANGUAGE i.e. export LANGUAGE=zu:xh:af:en_ZA:en So that administrators can easily setup a fallback policy. We need that in South Africa where Xhosa translations are relatively good but Zulu is available. And where many users second language is Afrikaans (af) and not English.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This problem is still present in F9. You can set a single system wide default language but cannot set fallbacks. The same is present when a user logs in, they can select a single language but are unable to select fallback languages.
Fallbacks are generally useful when one language fails, but when you select language using s-c-l if language supports is available s-c-l installs that support so i think no need of fallbacks for s-c-l can you elaborate following para.. >So that administrators can easily setup a fallback policy. We need that in >South Africa where Xhosa translations are relatively good but Zulu is available. >And where many users second language is Afrikaans (af) and not English.
The point that you are missing is that by default fallback is to English. Thus if no translations are available in your given language you will get English even if you can't understand English. Local languages in West Africa (French), South America (Spanish), Middle East (Arabic) are all affected. Users in there regions trying to use and develop local language translations will fallback to English instead of the regional lingua franca. We have that situation in South Africa. The current issue with s-c-l is that it doesn't allow you to do that from the interface.
requested by Jens Petersen (#27995)
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(In reply to comment #4) > Local languages in West Africa (French), South America (Spanish), Middle East > (Arabic) are all affected. Users in there regions trying to use and develop > local language translations will fallback to English instead of the regional > lingua franca. We have that situation in South Africa. I don't think users should have to do this in general it should be done by the system automatically, eg zu:xh, en_AU:en_GB, should be hardcoded somewhere. So maybe s-c-l could set LANGUAGE fallbacks for certain languages, but really this should be done by gettext/glibc/gdm at runtime since otherwise it only works for the system locale anyway.
@petersen: The gettext/glibc/gdm solution does seem like the correct long term approach for the correct behaviour. We're still faced however with the immediate that a user can't set this at all unless they know something about LANGUAGES, most localisers don't even know anything about that :). We'd still need the ability for a admin or user to override such a setting if it emerges in the future.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The LANGUAGE variable can be set in ~/.profile and it would override the LANG variable gdm sets (http://www.gnu.org/software/hello/manual/gettext/The-LANGUAGE-variable.html#The-LANGUAGE-variable). However I can imagine a user friendly interface for this. During the session startup GDM reads from ~/.dmrc clauses like: LanguageFallback[zu] = xh:af:en_ZA:en LanguageFallback[ua] = ru And if the current Language preference matches any fallback clause the corresponding LANGUAGE variable is set up. Though this certainly should be configured with some gnome utility, not through the GDM welcome screen. Reasonable defaults (as /etc/skel/.dmrc) are welcome. Finally a user has a way to set up a fallback list for locale languages. I think this should be considered as a feature request to upstream.
(In reply to comment #10) > The LANGUAGE variable can be set in ~/.profile and it would override the LANG > variable gdm sets Right > However I can imagine a user friendly interface for this. During the session > startup GDM reads from ~/.dmrc clauses like: > > LanguageFallback[zu] = xh:af:en_ZA:en > LanguageFallback[ua] = ru We need a table of defaults but not in "~/.dmrc". Of course if users what to override those in "~/.i18n" or "~/.dmrc" that is fine. > And if the current Language preference matches any fallback clause the > corresponding LANGUAGE variable is set up. Though this certainly should be > configured with some gnome utility, not through the GDM welcome screen. > Reasonable defaults (as /etc/skel/.dmrc) are welcome. I think a config tool is a separate issue: the first thing is to setup LANGUAGE currently for the different locales and that could be done by a table in gdm for now anyway and would be a valuable i18n UX improvement. > I think this should be considered as a feature request to upstream. Yep
If you set LANGUAGE in /etc/sysconfig/i18n, GDM loads the system locale. Probably my suggestion is, if $HOME/.i18n exists and $HOME/.dmrc doesn't exist, to load .i18n file.
If you like to set $LANGUAGE besides the system locale of /etc/sysconfig/i18n, my suggestion is: 1. s-c-l exports $LANGUAGE file per locale, e.g. a new file /usr/share/system-config-language/locale/$LANG/locale_file, which includes $LANGUAGE value - The similar implementation has been done in a UNIX. 2. s-c-l is able to write $LANGUAGE in /etc/sysconfig/i18n besides $LANG Then I think GDM could implement to load the language file per locale besides i18n file. The latest GDM or 2.20 base already can load the i18n file.
Doesn't seem to be a GDM bug anyway, reassigning from gdm to basesystem. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Why basesystem? Basesystem is just dependency metapackage with no content - it makes no sense to me.
Hmm, I thought it's a good place to dispatch down from. Sorry if I'm wrong and please reassing to the right component if needed.
Basesystem is definitely wrong. I'm not sure what is the right component - as this is more RFE than bug report. Reassigning to distribution. If you find something better, feel free to reassign it there.
This is something that spreads deeper than just a few packages, unfortunately. What we ask when installing is what *language* you want, not *where* you are. Given that, there's no way to specifically pick what the proper fallback would be. Even if you're operating on the language + timezone to attempt to auto-determine the country, and therefore the fallback language list, you can't do it reliably. French + CET could land you in France, Switzerland, Belgium, or even Algeria, all of which would have vastly different lists of fallback languages. In any case, the first step would be to generate these lists for a particular country. Assigning to iso-codes, although I can see it ending up in glibc-common somewhere.
This is probably now a duplicate of rfe bug 624158. Dwayne do you have a list of fallbacks you need. Would be nice if it could done in a less distro-specific way though.
*** This bug has been marked as a duplicate of bug 624158 ***