GNOME Bugzilla – Bug 327983
lack of variable name in lib/userdb.py
Last modified: 2008-01-21 20:09:57 UTC
Currently in sabayon.pot: #: ../lib/userdb.py:52 #, python-format msgid "invalid type for setting %s in %s" It is suggestted that multiple placeholders should be replaced by correspoding variable names. Please notify gnome-i18n@ when you commitig the changes. Thanks.
I'm not sure what you mean. Could you give an example?
I need to change the order of placeholders in msgstr. That is, the second %s will be placed prior to the first %s. But I cannot do this because of lack of the variable names.
Alex: see bug #308363 You want something like: _("%(bar)s and %(foo)s") % { "foo" : foo, "bar" : bar }
Any news on this one?
Created attachment 59464 [details] [review] Fix I think this patch will work. Right? Anyway, we're past string freeze atm.
This patch still hasn't been applied. Any reason?
Applied, but I was unable to regenerate the .pot file the requirement for inttool is higher than anything I have availbale for Fedora Core 5. Kjartan since you bumped the requirement, please regenerate the .pot, thanks, Daniel
Reverted the patch: <uws> DV: You broke string freeze when fixing #327983. Since sabayon has not been branched for gnome-2-16 (or something like that, why doesn't it use gnome versioning?), please revert! Find someone else who understand the rules and commit on GNOME CVS, Daniel
I think this patch should be reverted because it breaks a string for nothing and introduces many new issues. This is not a bug. Variables names suck. Translators don't care about variables names. What's important is the meaning of the message, not the way it is coded. Translation must not depend on variables names. And now Daniel is not free anymore to change his code because of i18n. Moreover, named arguments are not checked by xgettext, so if the translator accidentally translated "%(bar)s" by "%(baz)s", he wouldn't get a warning. It's lose-lose situation. The correct way to clarify the meaning of this string doesn't require to break it. Just add a comment immediately before it by using the xgettext flag. intltools are able to extract these warnings that are intented to the translator. Likes this : # xgettext: 1st argument is the name of the settings, 2nd is the path So please revert this change and instead add an xgettext comment. No string freeze breakage then :) PS: fine, it's reverted :)
(it was me asking to revert the patch) The original problem is that the translator needs to swap the arguments, so that the second %s becomes the first %s in the translated message.
Using glibc's sprintf, the translator can use %1$s and %2$s to swap the arguments. However, in Python: >> '%2$s foo %1$s' % ('first', 'second') ValueError: unsupported format character '$' (0x24) at index 2 http://docs.python.org/lib/typesseq-strings.html doesn't mention this either.
Positional arguments would be great. But i still think that named arguments in format is a bad practice. I don't know anything about chinese, but if there's a problem with this string, i guess it occurs on many other strings in mostly every software, no ? I mean the common issue is '%s misses %s', but that string looks quite simple and its shape is very common. I'm surprised.
Sorry for the noise, i'm wrong. I confused with the new $ based format. Except for the string breakage, the dict solution is fine (but no xgettex checks :/), as long as no one does any silly "format % locals()".
this issue seems to be solved in r720 and r825