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"
Some interpretations: de, nb: "A request for notifications about changes is in progress." fr, sv: "A request to change a notification is in progress." it, pt: Both have their own versions, I think.
There are many more such cases, although the difference is usually in only one or two languages. (Unfortunately it didn't occur to me to put them down from the beginning, so I can't give you a list. I'll just mention "Challenge Password" before I forget that, too.)
1) What should I do if I wanted to clarify a msgid? Just change the original .rc file?
2) Is there a way to add helpful comments to all language files at once without changing the msgid?
3) What should I do if I spot a suspicious translation? Spam the Bugzilla, contact the Last-Translator personally, or send patches to add #fuzzy comments and hope I'm right? And if it's wrong in many of the languages I can read, it's probably wrong in some others as well; who would check them all?
4) There has been discussions about some translation websites. Is there a chance that such a website would allow easy tagging of potential errors?
2012/2/22 Lauri Kenttä lauri.kentta@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"
Some interpretations: de, nb: "A request for notifications about changes is in progress." fr, sv: "A request to change a notification is in progress." it, pt: Both have their own versions, I think.
There are many more such cases, although the difference is usually in only one or two languages. (Unfortunately it didn't occur to me to put them down from the beginning, so I can't give you a list. I'll just mention "Challenge Password" before I forget that, too.)
- 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
- Is there a way to add helpful comments to all language files at once
without changing the msgid?
See above
- What should I do if I spot a suspicious translation? Spam the Bugzilla,
contact the Last-Translator personally
Last-Translator is not reliable. It might be updated by some tools/manually, but it's not guaranteed. You can use git-blame to find the last author of a specific line Spamming bugzilla is not an option IMO.
, or send patches to add #fuzzy comments and hope I'm right?
If you only *hope* to be right, don't send such patches
And if it's wrong in many of the languages I can read, it's probably wrong in some others as well; who would check them all?
Their respective translators. Sadly many translations are not that well maintained.
- There has been discussions about some translation websites. Is there a
chance that such a website would allow easy tagging of potential errors?
Problem is attribution of changes to respective authors (+ potential license conflicts). Search the wine-devel archives for more info.
-- Lauri Kenttä
Frédéric
On Wed, 22 Feb 2012, Frédéric Delanoy wrote:
2012/2/22 Lauri Kenttä lauri.kentta@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"
[...]
- 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.
(*) http://www.winehq.org/pipermail/wine-devel/2012-January/093969.html
- 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. 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. 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.
</pedantic-mode>
- There has been discussions about some translation websites. Is there a
chance that such a website would allow easy tagging of potential errors?
Problem is attribution of changes to respective authors (+ potential license conflicts). Search the wine-devel archives for more info.
Good starting points: http://wiki.winehq.org/Translating#head-e1a500fef50a1801ecea706ebd9b51457943... and http://www.winehq.org/pipermail/wine-devel/2012-February/094302.html
2012/2/22 Francois Gouget fgouget@free.fr:
On Wed, 22 Feb 2012, Frédéric Delanoy wrote:
2012/2/22 Lauri Kenttä lauri.kentta@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"
[...]
- 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.
- 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....) [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
On Thu, 23 Feb 2012, Frédéric Delanoy wrote: [...]
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....)
Which is from a section about solving collisions where the same string is used in two contexts that should receive different translations.
[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."
That's just an explanation of why one tends to run into this collision issue.
[...]
TBH "#." extracted comments and message contexts seem redundant, since both would need to be examined by the translator.
They are not redundant as they are used for different things. For instance:
/* This refers to the France Telecom mobile offering */ offer = dpgettext("wine", "mobile offer", "Open");
-> #. This refers to the France Telecom mobile offering msgctxt "mobile offer" msgid "Open" msgstr "Open"
Putting the comment in the message context would be a serious abuse. Also, if you where to then replace 'France Telecom' with 'Orange' in the context you'd invalidate all the translations whereas if it be fine in the comment.
The comments can also be aggregated so you get information about exactly how the string is used in each instance. This can be helpful to detect that indeed there are conflicts.
On 2012-02-22 22:45, Frédéric Delanoy wrote:
- There has been discussions about some translation websites. Is
there a chance that such a website would allow easy tagging of potential errors?
Problem is attribution of changes to respective authors (+ potential license conflicts). Search the wine-devel archives for more info.
Yes, I know about that. This was a hypothetical question. Also, I was only thinking about reporting errors without suggesting fixes. That wouldn't require any attributions, right? The actual fixes could be sent just like before.
But thanks, I think I got the answers I was looking for.
-
Francois Gouget -
Frédéric Delanoy -
Lauri Kenttä