Obscure texts and invalid translations

[Frédéric Delanoy]

2012/2/22 Francois Gouget <fgouget at free.fr>:
> On Wed, 22 Feb 2012, Frédéric Delanoy wrote:
>
>> 2012/2/22 Lauri Kenttä <lauri.kentta at gmail.com>:
>> > Hi,
>> >
>> > Wine has many texts, especially error messages, that are almost impossible
>> > to translate without knowing what they're really about. Some are also easy
>> > to misunderstand.
>> >
>> > An example from dlls/kernel32/winerror.mc:
>> > msgid "Notify change request in progress.\n"
> [...]
>> > 1) What should I do if I wanted to clarify a msgid? Just change the original
>> > .rc file?
>> Adding a message context. Wine translating page
>> (http://wiki.winehq.org/Translating) has some info on this. Not sure
>> if it applies to winerror messages, though
>
> Wine's winerror messages a pretty terse and usually not full sentences.
> One thing we noticed recently(*) is that the Windows ones are much
> longer and form full sentences and as a result are likely less
> ambiguous. So in the case of the winerror messages the correct fix is
> probably to simply rewrite the message so it is an unambiguous full
> sentence.

Or simply make it clearer (if needed). The fact that Windows uses
long/full sentences doesn't mean we have to mimic that per se.

>> > 2) Is there a way to add helpful comments to all language files at once
>> > without changing the msgid?
>> See above
>
> <pedantic-mode>
>
> In theory message contexts are not the right tool to pass commentary
> about the string to translate either.

I think they are (depending on your definition of commentary)
(from http://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Contexts.html#Contexts)
[speaking of short strings]
"The problem is that many of the strings which have to be translated
are very short. They have to appear in pull-down menus which restricts
the length. But strings which are not containing entire sentences or
at least large fragments of a sentence may appear in more than one
situation in the program but might have different translations. This
is especially true for the one-word strings which are frequently used
in GUI programs."

> Normally xgettext takes the
> comments preceding the string to be translated in a PO file as lines
> starting with '#. '. But in our case RC files are processed by wrc which
> I believe does not have a means to access the comments in the RC file.

Well in that case it's simply a feature missing in wrc. But that
probably won't be "fixed"
TBH "#." extracted comments and message contexts seem redundant, since
both would need to be examined by the translator.
But the need for extracted comments (#.) usually indicates that the
msgid needs to be clarified instead.

> This is why in Wine we normally use message contexts and will likely
> have to continue doing so. For now it works fine anyway.
>
> In the future we may get into trouble if we start doing that extensively
> and the same string gets two different 'comments' as this would result
> in different contexts, hence requiring translators to translate twice.
> For instance:
>
>    "msgctxt#Shown in the File Open dialog#OK"
> and
>    "msgctxt#Shown in the Print dialog#OK"
>
>  -> "OK" needs to be translated twice when that was not the intent
>
> For now we can avoid this by limiting our 'commenting' to the cases that
> really need it.

Obviously.
What we definitely want to avoid, though, is very short
"non-propositions", like one-word adjectives for example: this
can/will cause issues in languages where adjectives agreements are
used.

Frédéric