Junio C Hamano <gitster@xxxxxxxxx> schrieb am 27.07.2007 01:31:06:
> I have tried to address issues raised in Christian's comments on
> the first draft that was circulated privately.
Yes, this looks very nice, concise, and good to read. Thanks.
> +to test the resulting translation out. It also is a good idea to have
> +specialized so-called "po file editors" (e.g. emacs po-mode, KBabel,
> +poedit, GTranslator). Please install them.
I'd rephrase the very last sentence into: Please install at least one of
them, whichever you feel comfortably with.
> + - Often the messages being translated are format strings given to
> + "printf()"-like functions. Make sure "%s", "%d", and "%%" in your
> + translated messages match the original.
> +
> + When you have to change the order of words, you can add "<number>$"
> + between '%' and the conversion ('s', 'd', etc.) to say "<number>-th
> + parameter to the format string is used at this point". For example,
> + if the original message is like this:
> +
> + "Length is %d, Weight is %d"
> +
> + and if for whatever reason your translation needs to say weight first
> + and then length, you can say something like:
> +
> + "WEIGHT IS %2$d, LENGTH IS %1$d"
> +
> + [NEEDSWORK: this whole "parameter permutation" part needs to be
> + verified if it works with Tcl at all]
I agree it needs to be verified, although the msgcat documentation claims
it works. Nevertheless I'd rather question whether this text is helpful at
this point in the document. How about moving the "positional codes" issues
to a separate section at the end, under the topic "Advanced translation
tips" or something like this?
> +You can test your translation by running "make install", which would
> +create po/af.msg file and installs the result, and then running the
> +resulting git-gui under your locale:
> +
> + $ make install
> + $ LANG=af git-gui
Right, this should always work.
> +There is a trick to test your translation without first installing, if
> +you prefer. First, create this symbolic link in the source tree:
> +
> + $ ln -s ../po lib/msgs
> +
> +After setting up such a symbolic link, you can:
> +
> + $ make
> + $ LANG=af ./git-gui
> +
> +[NEEDSWORK: this symlink trick needs to be verified if it works.]
It does work, but as Nanako Shiraishi already pointed out, one has to call
./git-gui.sh in contrast to the version without suffix.
> + $ msgmerge -U po/af.po po/git-gui.pot
> +
> +[NEEDSWORK: who is responsible for updating po/git-gui.pot file by
> +running xgettext? IIRC, Christian recommended against running it
> +nilly-willy because it can become a source of unnecessary merge
> +conflicts. Perhaps we should mention something like "
> +
> +The po/git-gui.pot file is updated by the internationalization
> +coordinator from time to time. You _could_ update it yourself, but
> +translators are discouraged from doing so because we would want all
> +language teams to be working off of the same version of git-gui.pot.
> +
> +" here?]
I wouldn't have put git-gui.pot into git to start with. Translators who can
msgmerge their translation by definition have the gettext toolchain
available, so they could very well just have git-gui.pot generated
themselves. We can just as well give instructions here on how to regenerate
git-gui.pot: "make po/git-gui.pot"; in gnucash, we added a separate rule
"make pot" because that one is easier to type.
As for merging the po file: I would encourage every *translator* to
"msgmerge" their po file as often as they like. This rule will only run
into problems if translators forget to merge their po file regularly, and
continue to work on the old string; so far I have no solution to this
problem. I spoke up a few days ago to ask the maintainers not to merge the
*po* files, because this is where the translators work with, and merging
conflicts here will make translators unhappy. But this concerns the *po
file*. The pot file can just as well be updated by the maintainers or the
translators, but it would be best not to have it in SCM at all.
> + - The original text in English of an older message you already
> + translated might have been changed. You will notice a comment line
> + that begins with "#, fuzzy" in front of such a message. msgmerge
> + tool made its best effort to match your old translation with the
> + message from the updated software, but you may find cases that it
> + matched your old translated message to a new msgid and the pairing
> + does not make any sense -- you would need to fix them, and then
> + remove the "#, fuzzy" line from the message.
I would add the sentence (because people frequently forget about the
implications of the fuzzy marker): A translation prepended by the '#,
fuzzy" line will not show up in the program. Gettext will treat this
message as if no translation existed.
Overall this is very nice. Thanks a lot.
Christian
IBEO Automobile Sensor GmbH - Sitz: Hamburg - Handelsregister: Hamburg HRB
67903
Geschäftsführer: Dr. Ulrich S. Lages
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
