GNOME Bugzilla – Bug 249844
"New" submenu entries need to have fully qualified names
Last modified: 2008-08-06 15:45:07 UTC
English is one of few languages that doesn't differ between genders for nouns. In many other languages, it's absolutely essential to use the correct gender and correct gender adjectives for the noun. Thus, the "New" menu and "New" button in Evolution are *very* problematic for translation, as the adjective "new" can (and in the case of Evolution very much does) refer to many different types of objects and words, words that are nouns and that have different genders, and that thus needs different variants of the adjective "new" to be anything remotely similar to correct language. Because of this, the entire concept of having a single "New" menu and a single "New" button for creating many different types of objects is fundamentally flawed from a linguistic point of view. Still, the current situation in Evolution could be improved would the "New" menu entries be altered so that their meaning could be self-contained. So instead of the current menu layout: New -> Mail Message New -> All Day Appointment New -> Contact New -> Contact List New -> Appointment New -> Meeting New -> Post Message New -> Task New -> Folder New -> Shortcut New -> Evolution Window one would also add "New" to the submenu entry names to make them fully qualifed and make it possible to at least translate the messages in the submenus correctly: New -> New Mail Message New -> New All Day Appointment New -> New Contact New -> New Contact List New -> New Appointment New -> New Meeting New -> New Post Message New -> New Task New -> New Folder New -> New Shortcut New -> New Evolution Window
Retargeting 1.5.3->1.5.4 bug reports. Sorry for the spam.
what does outlook do in foreign languages?
Outlook seems to do it as current Evolution ie. New -> Mail Message New -> All Day Appointment which looks really silly in swedish since you get the grammar wrong as Christian explained.
Created attachment 43408 [details] [review] Patch for the bug:New Sub menu entries should have fully qualified names
Please submit your patch to evolution-patches mailing list. You may need to subscribe. Please see http://lists.ximian.com
i dunno if this really falls into ui/product-design, but can you guys comment either way? i'm inclined to just take the patch fwiw.
Ugh, Christian makes a good point as usual. However adding the word "New" to every menu item decreases the readability in English. It prevents the eye from quickly scanning the item names as they all start with the same 3 letters and a space. If the translators wanted to translate those items into "New ..." for each language where it makes sense then I think that would be the best idea. However for English this would be a step back.
I'm going to go with Bryan's comments here, we can revisit in 2.1.0 time frame.
Regarding Bryan's comment, I don't think it's currently possible for a translator to diverge from the original here. "Task" cannot be translated into the equivalent of "New Task", since gettext allows any unique string to be translated only once for the whole gettext domain/application (since translations are hash key/value pairs where the unique original string is the key), and a string like "Task" and the other ones are likely to occur in other places aswell, where translating them with "New..." may be incorrect. AFAIK the only way to resolve this without rewriting the original English strings would be to use context markers in these messages (http://bugzilla.gnome.org/show_bug.cgi?id=97556), so that they can be translated seperately from the other occurrences elsewhere of these strings.
...so moving milestone from 2.1 to 2.3 (pretty sure it will be moved further into future as time goes by... ;-)
Apologies for any spam... cc'ing usability-maint on all Evolution usability bugs. Filter on EVO-USABILITY-SPAM to ignore.
at least retargetting from 2.3 to 2.5
did not happen in 2.5 timeframe, changing target milestone to "future". this will not be fixed in 2.6 because we're under string freeze.
Regarding comment #9, couldn't we prefix the translated "New" menu item strings to make them unique? e.g. Q_("New|Mail Message") See: http://library.gnome.org/devel/glib/unstable/glib-I18N.html#Q-:CAPS
Yes, except it would have to be: Q_("Mail Message|New") Q_("Contact|New") etc. It is the word "New" that needs adopting to the context.
Bumping version to a stable release.
Created attachment 115717 [details] [review] Proposed patch Attempting to implement Christian's suggestion in comment #9. Marks "New" submenu entries with a "New" translation prefix, so they can be distinguished from other uses of the same text in the application. e.g. - menuDescription = _("_Task"); + menuDescription = Q_("New|_Task"); So if the language calls for it, "New|_Task" could be translated to have a fully qualified name, as shown in comment #0.
gettext now natively supports adding context to strings, with the msgctxt() call. We will most likely switch to this gettext way of marking context elsewhere in GNOME (however this is not yet finally decided), but perhaps it would make sense to use the C_ macro instead of the Q_ macro when patching this (if requirements allow it). See http://live.gnome.org/GnomeGoals/MsgctxtMigration
Created attachment 115751 [details] [review] Revised patch Revised patch uses C_() instead of Q_(). Also finishes off the GNOME Goal, though I only found one string already using Q_() where the wiki claims two.
Looks fine to commit.
Patch committed to SVN trunk as r35897 http://svn.gnome.org/viewvc/evolution?view=revision&revision=35897 Please close the bug after announcing string change to gnome-doc-list and gnome-i18n.
Announced, and MsgctxtMigration page updated.
This change made compiler a bit unhappy: addressbook-component.c: In function ‘impl__get_userCreatableItems’: addressbook-component.c:229: warning: assignment discards qualifiers from pointer target type addressbook-component.c:237: dtto addressbook-component.c:245: dtto memos-component.c: In function ‘impl__get_userCreatableItems’: memos-component.c:1261: dtto memos-component.c:1269: dtto memos-component.c:1277: dtto tasks-component.c: In function ‘impl__get_userCreatableItems’: tasks-component.c:1326: dtto tasks-component.c:1334: dtto tasks-component.c:1342: dtto mail-component.c: In function ‘impl__get_userCreatableItems’: mail-component.c:917: dtto mail-component.c:925: dtto btw, you missed the calendar-component.c :) When fixing these warnings, I got rid of this one too: em-event.c: In function ‘em_event_target_new_custom_icon’: em-event.c:198: warning: assignment discards qualifiers from pointer target type
Created attachment 115970 [details] [review] proposed evo patch for evolution; I didn't find any better way that cast the return of C_ macro to 'char *'. Is there any better possibility?
That's weird that using C_() throws warnings but Q_() doesn't. Both return a const gchar * (I thought). Anyway, not worth worrying about a better way. The Bonobo code is not long for this world. ;) Please commit, Milan.
Committed to trunk. Committed revision 35916.