GNOME Bugzilla – Bug 613306
xgettext:no-c-format for string "%x"
Last modified: 2010-06-19 13:40:51 UTC
Created attachment 156541 [details] [review] Patch that adds xgettext:no-c-format markers Currently translators cannot really translate "%x" string because po-validation fails as xgettext marks the string as c-format (printf kind of formatting), which it is not (it is strftime formatting string).
According to interpretation on gnome-i18n list, this does not break string freeze because it only changes comments, and it does not change string freeze because it does not modify any strings: http://mail.gnome.org/archives/gnome-i18n/2010-March/msg00237.html
OK, I understood your issue is bug 614159. I think %x is not a translatable string. I think the msgstr is also "%x" so that LC_TIME can change the value instead of LC_MESSAGES. If %x doesn't work on your locale, I think the most issue is your locale issue instead of changing %x. The workaround is to modify the comment(# c-format) in your po file however I think it's better to keep %x for LC_TIME.
*** Bug 614159 has been marked as a duplicate of this bug. ***
Takao If we are not supposed to be able to change "%x" then why mark it for translation?
(In reply to comment #4) > If we are not supposed to be able to change "%x" then why mark it for > translation? My suggestion is to remove the gettext mark _() to use LC_TIME instead of LC_MESSAGES since someone sometimes file a bug to use LC_TIME. Probably now is a string freeze but msgstr "%x" might be no problem at the moment. E.g. IIRC, Evolution also removes gettext and use "%x" after got a bug. http://git.gnome.org/browse/evolution/tree/e-util/e-datetime-format.c#n111
*removing* strings from translation is never any problem under string freeze as no additional work is created for translators. There's a hardcode freeze currently though until 2.30.0 is released.
Yup, I guess we should have never marked it for translation. My mistake. Sorry guys.
Created attachment 157435 [details] [review] Patch for gdm-clock-widget.c Attached the patch for 2.30. Probably I think it's better to provide the option to choose LC_MESSAGES(%D, %d/%m/%y) or LC_TIME(%x) with another bug in the next release.
(In reply to comment #8) > Probably I think it's better to provide the option to choose LC_MESSAGES(%D, > %d/%m/%y) or LC_TIME(%x) with another bug in the next release. Thinking again, it may be better to use LC_TIME only for the date formats in the next release(2.32).
I noticed the gettext mark was removed in "%x" in git HEAD. I think you can commit .po files and close this bug.