Bug 246325 - need LANGUAGE settings for translation fallbacks [NEEDINFO]
Summary: need LANGUAGE settings for translation fallbacks
Keywords:
Status: CLOSED DUPLICATE of bug 624158
Alias: None
Product: Fedora
Classification: Fedora
Component: i18n
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: i18n Engineering List
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-30 10:42 UTC by Dwayne Bailey
Modified: 2013-01-10 04:22 UTC (History)
13 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-12-21 05:58:47 UTC
Type: ---
Embargoed:
petersen: needinfo?


Attachments (Terms of Use)

Description Dwayne Bailey 2007-06-30 10:42:12 UTC
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.

Comment 1 Bug Zapper 2008-05-14 13:20:54 UTC
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

Comment 2 Dwayne Bailey 2008-05-22 14:50:56 UTC
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.

Comment 3 Pravin Satpute 2008-07-07 07:05:46 UTC
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.



Comment 4 Dwayne Bailey 2008-07-07 08:20:52 UTC
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.

Comment 5 Tony Fu 2008-09-10 03:09:46 UTC
requested by Jens Petersen (#27995)

Comment 6 Bug Zapper 2009-06-09 22:40:54 UTC
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

Comment 7 Jens Petersen 2009-06-23 07:27:39 UTC
(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.

Comment 8 Dwayne Bailey 2009-07-15 09:35:21 UTC
@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.

Comment 9 Bug Zapper 2009-11-16 07:56:05 UTC
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

Comment 10 Sergey Rudchenko 2010-01-24 09:03:04 UTC
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.

Comment 11 Jens Petersen 2010-01-25 01:27:00 UTC
(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

Comment 12 fujiwara 2010-01-25 02:11:15 UTC
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.

Comment 13 fujiwara 2010-01-25 06:46:34 UTC
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.

Comment 14 Sergey Rudchenko 2010-07-09 05:25:15 UTC
Doesn't seem to be a GDM bug anyway, reassigning from gdm to basesystem.

---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 15 Ondrej Vasik 2010-07-09 05:45:39 UTC
Why basesystem? Basesystem is just dependency metapackage with no content - it makes no sense to me.

Comment 16 Sergey Rudchenko 2010-07-09 08:34:42 UTC
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.

Comment 17 Ondrej Vasik 2010-07-09 14:16:05 UTC
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.

Comment 18 Bill Nottingham 2010-07-09 18:01:00 UTC
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.

Comment 19 Jens Petersen 2010-12-09 05:28:01 UTC
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.

Comment 20 Jens Petersen 2010-12-21 05:58:47 UTC

*** This bug has been marked as a duplicate of bug 624158 ***


Note You need to log in before you can comment on or make changes to this bug.