8 maj 2013 kl. 14.57 skrev Daniel Shahaf:
> Apples and oranges. The issue you're talking about is that _("hello
> world") would have to be translated differently in two places within
> our
> code. Your patch potentially uses _() either on string literals from
> APR's future code (which, unlike string literals in our code, we can't
> review pre-release for appropriateness of the translation to both of
> them) or even on user input.
When was the last time any such review was done? I doubt any has ever
been performed.
But that doesn't actually matter. When a translator sees
#: somefile.c:123
msgid "some string"
in the .po file, his responsibility is to translate that string in
general and as used in that particular spot in the source in
particular. (Most of the time he will just write the obvious
translation right away without so much as looking at the source. Only
if the message is difficult to understand in isolation will the source
be consulted at all.)
In this case, what he will find in the Subversion source are the five
strings
"%s: invalid option: %s\n"
"%s: missing argument: %s\n"
"%s: erroneous argument: %s\n"
"%s: invalid option character: %c\n"
"%s: missing argument: %c\n"
in the command-line option parsing error handler. Those strings are
quite trivial to translate as they are, but a translator bothering to
look at the source would find that it confirms his intuition: these
are option parsing error messages, and can have only one meaning.
In other words, it does not matter how or why APR generates them, or
if this would change at any point in the future. The translation has
been done based on the strings' occurrence in the Subversion source,
not in APR.
I will gladly add a comment to translators looking that that part of
the source that they should not try to take the exact origin of those
strings in APR into account when translating, in the unlikely event
that anyone would ever contemplate such an endeavour.
Received on 2013-05-11 23:34:18 CEST