This is exactly how gettext works. Yes, you can get crashes if the
translated string does not have the right arguments--and I would not be
at all surprised to hear of at least one privilege escalation bug
due to a bad message catalog, since printf format errors can be used in
such interesting ways.
Anyway, for printf-style formats, 'msgfmt' can be directed to check for
this situation:
$ cat bad.po
msgid ""
msgstr "Content-Type: text/plain; charset=UTF-8\n"
#,c-format
msgid "foo %s %d"
msgstr "föö %d %d"
$ msgfmt --check-format bad.po
bad.po:6: format specifications in 'msgid' and 'msgstr' for argument 1 are not the same
No, the ability of gettext+printf to use the right structure of the
user's language is a strength. For instance, consider the translation
into Yoda's locale of the following sentence:
printf("The %s is %s.\n", "Future", "Clouded");
The proper localized message is
Clouded the Future is.
Anything else will range from confusing to unintelligible to the
native speaker. You get that with gettext by writing
printf(_("The %s is %s.\n"), _("Future"), _("Clouded"));
together with the message catalog entry
msgid "The %s is %s.\n"
No, that one's a mistake. I did not take care when choosing which
strings to mark, because I was mostly interested in showing a
proof-of-concept for using gettext to translate core parts of git.
The amount of work to mark all the source files and then to keep the
marks up to date should not be underestimated--and that's just the work
to enable translators to localize the software. It is important to
gauge the interest in the git community in actually doing this work.
As my own primary language is English, I have only a theoretical
interest in this feature. However, the existence of translations for
gitk and git-gui indicates to me that the community probably does desire
this.
Jeff
--
