GNOME Bugzilla – Bug 362754
[calendars][contacts] the language of some part cannot be changed when update system language
Last modified: 2010-04-02 13:55:39 UTC
Please describe the problem: Log in a system with some other locales, such as CJK/Indic languages, launch evolution to configure. Change the language to en_US or other language and log in system. Launch Calendars and Contacts (Even use 'LANG=en_US.UTF-8 evolution' in g-t), you will find the language of some part in Calendars and Contacts cannot be changed to English or other language, it is always the language you used to configure evolution before. Pls refer to the attached screenshot. Steps to reproduce: 1. Log in a system with some other locales, such as CJK/Indic languages. 2. Launch evolution to setup mail account. 3. Log out and change language in login window. 4. Launch Calendars and Contacts. Actual results: The language of some part in Calendars and Contacts is always the language you used to configure evolution before. Expected results: The language of Calendars and Contacts is expected to be changed according to the system language update. Does this happen every time? Yes Other information: Evolution is no problem when change system language.
what is "some part"? can you please be more specific, or provide a screenshot? thanks in advance!
Created attachment 75051 [details] Pls note the left panel
Created attachment 75052 [details] Pls note the left panel There is an easy way to reproduce the problem that is to retest in a fresh install system with CJK or Indic as system default lanugage. Then first launch evolution to setup mail account, log out to change language then log in.
New calendar - two things can happen 1) While creating an evo account, the setup wizard can create one for you 2) A user creates a calendar by himself if (1) happens, according to current locale, the setup druid picks up right translation of "Personal" & adds it to GConf. if (2) happens, the user creates a new calendar (english or native language) & evo adds this string to the GConf. NOTE that this string cannot be translated at runtime, so evo adds it as-it-is to GConf. Hence as per (2), point (1) also becomes a correct behaviour. Though i *think* that the translation consistance for "On this computer" and "personal" strings (which we are calling right now as a bug) can be fixed (temporarily) by instead of adding their translated version to GConf, we can add their english version. BUT, this will only confuse the end user. As if he uses Evo in any other locale than en_US, he'll be consistantly be using it in the same locale. Hence, I think this *should* not be a bug. Andre, Nicole, what do you say...?
Another thing... I dont think this is l10n bug... rather more of engineering effort (if atall this is a bug.) :) makuchaku
Reported it as a bug due to two reasons: 1. As a tester, I found Evolution Email has not the problem. 2. As an end user, I always switch between two locales (English and native language), the problem makes me a little bit inconvenient.
Srag on #evo also mentioned a point that during mass deployments of clients in corporates, generally network admins do the installation (in their own locale - en_US for eg.) & then users run the application (evo in our case) in their own locale (maybe ja_JP). So the best solution for this bug would be... the strings like "On This Computer", "Personal" should always be stored in gconf in en_US than the language in which evo account was setup. If this is fine, I can go ahead & try to create a patch for this bug. Andre? Chen?
Here's another idea. The strings in question all seem to be source group names. The standard set of source group names that Evolution installs also have fixed base URIs. Some examples: Base URI Name --------------------------------- ------------------ "file://$HOME/.evolution/*/local" "On This Computer" "caldav://" "CalDAV" "contacts://" "Contacts" "ldap://" "On LDAP Servers" "weather://" "Weather" "webcal://" "On The Web" Evolution should stop writing these standard names to GConf. At the same time, when reading source keys from GConf, Evolution should first try to derive the source group name from the "base_uri" attribute. It should know how to derive all of the standard names listed above for the current locale. If that fails, then and only then should it look for the source group's "name" attribute in GConf. This approach is backward-compatible for existing configurations.
Created attachment 112064 [details] [review] proposed evo patch for evolution; It was very simple for the groups and sources, but for categories, it will be much harder. But I guess it's in the other bug, not this one. Does anybody know the number?
maybe(TM) also fixes bug 539467 as a side effect. we'll see.
similar one is bug #333023
Patch looks good to commit. I guess the patch only marks already existing strings for translation. If thats true, please commit it to stable as well. Please announce the string changes if any new string was added.
Committed to trunk. Committed revision 37117. Committed to gnome-2-24. Committed revision 37118. No new string has been added, and if so, then rather as a typo. :) I dropped a CalDAV part, it's there already in trunk, and doesn't worth it in gnome-2-24.
*** Bug 501945 has been marked as a duplicate of this bug. ***