Red Hat Bugzilla – Bug 224074
address book does not work properly when language is set to Dutch
Last modified: 2007-11-30 17:11:53 EST
Description of problem:
When I have my system set to Dutch the address book doesn't work properly.
Contacts do not show up when "any category" is selected. It does work when the
system is set to English. I have to support a few people whose knowledge of
English is not that good and this really bugs them.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set system language to Dutch
2. add contacts
3. make new message
Contacts do not show up in "any category"
Contacts should be visible in the "any category", no matter what language is
I don't know if just Dutch is affected. I will try with other languages, at
least the once I can decipher :P
I tested some more with various languages (German, Spanish, Afrikaans). There it
works, but it seems that for those languages the category selector was not
translated. If I choose there I get "Any Category" in English instead of "Any
Category" in $LANGUAGE.
It must be some weird translation thing that is preventing the correct working.
How can I test this better (as in, how can I regenerate the .po files?)
This actually happens in the dataserver, changing
msgid "Any Category"
msgstr "Alle categorieën"
in nl.po should indicate where the error is. None of the other languages have
this string translated, only the Dutch one. This is also the part where the
error seems to occur.
Removing this line (and thus defaulting to English in this piece of the user
interface) gets rid of my problem. So, I now have confirmation that it happens
because of this translation. Why it happens I don't know...
Same problem in french.
The proposed temporary bypass by suppressing the "Toute catégorie" translation
is satisfactory for now.
I just note that both translations have a non-ASCII character (accentuated e).
This might be the problem, although I did not tested it.
Created attachment 148535 [details]
Patch fixing the problem.
This patch fixes the problem properly (without affecting translations).
The bug was not accent-related: the translated string in the menu was compared
to the untranslated "Any Category" string at menu change time, causing failure
for non-english strings.
The solution retained in the patch is to check the menu item index being 0
rather than comparing strings; this is possible since we know that the "Any
category" menu item is always the first.
Thanks for the patch! As it turns out, I just recently fixed this upstream .
The string "Any Category" is already translated in other places; it appears
this instance was simply overlooked. But your solution would work as well.
I'll get this fixed in Fedora Core 6 and Rawhide.
Fixed in evolution-data-server-1.8.3-2.fc6.
This should hit Fedora Updates Testing in the next day or so.