GNOME Bugzilla – Bug 601535
Categories not translated in menus
Last modified: 2010-06-19 00:39:33 UTC
the strings on Categories drop down menu cannot be translated as stated on bug 592313 ; I'm opening a new bug as requested there. example: http://launchpadlibrarian.net/33035707/evolution.png
I don't understand why categories can't be translated.
Ah, you probably mean that once the categories.xml file is populated, with a language you run it in for the first time, you see them in that language regardless which language you run the evolution later. Right? If so, then this is a duplicate of another bug already filled. It's pretty hard to do that, because categories is just a list of strings stored in a component (contact/calendar). Once you enter it in it's there. Then, for example, if you change your language, and possible some predefined category will also change its name, then searching for it will not pick the component, same as if some user sends you an event which has filled a category name in english and you've your categories named in japan or any other language, and vice versa. One possibility is to use the english forms in the background, but show translated strings in the UI. Maybe. But this is definitely part of the older bug report, which I do not have handy. Please search for it if you meant this. Thanks.
It's true that _some_ categories are getting translated on first startup, but most don't for some reason, though valid translations exist. (Tested on Evo 2.28.x and 2.30.x) While all weather events, the Birthday, Anniversary, Miscellaneous and Personal category are translated properly, the rest is not.
Created attachment 161738 [details] [review] Patch to fix it. While working on another problem related to eds, I've found a solution for the problem. Instead of calling gettext in load_default_categories, dgettext should be used to set the right translation domain.
Review of attachment 161738 [details] [review]: Thanks for a patch, though it doesn't work for me. I have written English categories on the disk. Running Evolution as "LANG=cs_CZ.utf8 evolution" doesn't translate categories in the popdown menu in Contacts view. The code you changed is even not invoked. You've right with one thing, as the e-categories is used as part of the library, then there should be used gi18n-lib.h file, instead of gi18n.h, and the gettext call should be replaced with simple _ call, which does pretty the same as you did, only in the usual way. Please reread comment #2 carefully, as the problem is much deeper.
I did not mean to translate categories.xml once it has been written - though this would be the ideal and this is maybe what you are talking about when refering to comment #2. My patch was meant to simply write a localized version of categories.xml when it does not yet exist. If you want to get the categories translated on-the-fly, there should be an english only categories-file written and all calls to values from it need a gettext call with proper (e-d-s) context, what is really not trivial. I'll see what I can do about it, but it'll take some time (and unfortunately my holidays are ending soon ;-) )
Yup, it's not trivial, and there are more implications on the change, like: - what to save to event/contact in categories? - how to search for a category? (localized/not localized/both) - and, of course, backward compatibility and interoperability As of now, the categories are used in the language in which the categories.xml file was created the first time. And we do not want to break it for them all, as it would seem like they lost their categories, when we would only translate default categories every time the file is loaded.
I've found out that it is rather easy to translate an english categories.xml on-the-fly, but I've not been able yet to preserve the english file when changing anything (e.g. adding a new category). Like said, my holidays are ending, so it will be harder to work on such changes (it's hard enough for me being a historian, not a computer-scientist ;-)) Concerning backward compatibility: my patch (or the changes you've suggested) at least restores the old behaviour for evo 2.30+.
Created attachment 161963 [details] [review] eds patch (correct gettext domain) for evolution-data-server; OK, I'm committing this patch, but as you found the issue then with you as an author. I'm keeping the bug opened, because it's just a partial fix.
Created commit 5cfce36 in eds master (2.31.3+) Created commit 52b53b7 in eds gnome-2-30 (2.30.2+)
Fixed on master and gnome-2-30 branches: http://git.gnome.org/browse/evolution-data-server/commit/?id=4b1d3d2941bc8e914592d595c854eddca8738830 http://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-2-30&id=1ba62f655446f87021aced6e9b009e752651b456 Solution: libedataserver doesn't have a central initialization function, so configure the gettext domain in e_categories_init() so gettext can find the category translations. Store UTF-8 collation keys in the category hash table and look up categories by their collation key. Save default categories to disk under their C-locale name with a default="1" attribute, and localize them while parsing categories.xml. Don't know if this fully repairs busted categories.xml files, but I don't really care that much. Better to just delete the file and let e-categories create a new one.