GNOME Bugzilla – Bug 542658
Add translator comments in fm-properties-window.c
Last modified: 2009-02-12 23:05:49 UTC
I suggest adding translator comment when using contextual markup in strings. The following patch also adds more "--" marked for translation.
Created attachment 114434 [details] [review] Add translator comments and some more strings for translation
Thanks for your bug report. I am a bit skeptical - how do you want to translate this? If you want to use a textual string, we should also use a string in the original (C) locale. I think the idea was not to use "None" or "Unknown" because that would clutter the user interface with elements indicating that information is not available.
You talk about "--"? I saw that one was already marked for translation, and not the others. So either all or none should be marked. But if you think that they should not be marked at all, I see no problem. But on the other hand, it's always difficult to assume that "--" means "nothing" in all languages/cultures.
> You talk about "--"? Yes. > it's always difficult to assume that "--" means "nothing" in all languages/cultures. Every language except vietnamese seems to translate this to "--". In vietnamese, it is a nice dash. I just committed a patch that removes the gettext call, and replaces the "--" by a dash: http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14351 Thanks, closing.
Fine for me, but: * you omitted the translator comment at line 1363 (first change in my diff) * you have a left-over gettext call at line 3262 (_(INCONSISTENT_STATE_STRING))
The first change shouldn't be necessary as it's explained by the Q_() macros' definition, but it may be a good idea to add it anyways for those using translator services. I'm not sure how well that plays with reality though. Do any of the other Q_() strings have comments like that? The second point is definitely correct and is fixed now.
In general, I prefer that all Q_() macros have translator comment. Experienced translators should not need it, but you know... :-) But as the Q_() macro should soon become deprecated, you could also replace it by the new C_() macro, and so the comment would be no more necessary. See http://live.gnome.org/GnomeGoals/MsgctxtMigration
Created attachment 114678 [details] [review] bump intltool req, use C_() instead Here's the patch to do just that. I didn't commit it directly as I'm not sure if there's a procedure to do when bumping module requirements though.
Sounds perfect to me.
The patch has been committed some time ago by A. Walton. Thanks for staying tuned. Closing.
I'm so sorry to reopen this, but I just discovered yesterday that C_ support in intltool was broken (#543665). It will be corrected in intltool 0.40.1, but I suggest we keep the Q_ macro for 2.24. We will probably launch a gnome-love campaign to replace Q_ by C_ during 2.25 cycle.
Thanks, I have reverted the patch in Nautilus 2.23.5.1, which I am rolling ATM.
A comment for the first string in Claude's patch has been committed to trunk for the 2.24 release, along with a FIXME comment referring to this bug.
Bug 543665 has been fixed, and gnome-i18n may be pushing this for 2.26, so I think this is probably safe to go in now.
Ping, the Q_ to C_ change could be applied, and then this bug can be safely closed.
Committed to trunk a version of the patch that requires intltool 0.40.1. 2009-02-13 Cosimo Cecchi <cosimoc@gnome.org> * configure.in: require intltool 0.40.1. * src/file-manager/fm-properties-window.c (value_field_update_internal): use C_() to handle translator comments. Patch by A. Walton (#542658).