I have started running a script that can check for translation issues in PO files against Wine's PO files.
The issues it checks for include: * Mismatched printf format specifiers. * Mismatched trailing ellipsis. * Other mismatched trailing punctuation like full stop, question mark, space, etc. * Mismatched line feeds, trailing or not. * Spaces followed by line feeds. * Untranslated strings.
Obviously some of these result in false positives. For instance 'Document' is written exactly the same in English and in French so to the script it will look like it was not translated. If you send me the corresponding error lines I'll make sure they are ignored by putting them in an 'ignore' file.
So here's the web site:
http://fgouget.free.fr/wine-po/
A typical report looks like this:
L71: msgid or msgstr does not end in '[.]{3}' L75: msgid or msgstr does not end in '[.]{3}'
You'd typically have the report and the corresponding PO file (here pl.po) open side by side, and jump to the PO lines mentionned in the report to investigate each of them. These are two ellipsis issues by the way.
As you can see it's quite primitive. That's both because I'm not much of a web developer guy and because I'm still unsure how much interest there is in this.
Also there's an open-source tool that does the same type of checks and more, though it seems to lack a way to handle false positives. It's pofilter from the translate-toolkit package. This tool is integrated with Pootle (the online PO file editor), so maybe this will do all we need once we put our PO files online for translation.
In the meantime if any translator is interested in seeing what potential issues lie in their PO files... I'd particularly appreciate help with cleaning up the ellipsis, trailing spaces and untranslated string issues.
See wine-patches for a handful of patches I'm sending based on the initial reports.
On Wed, Jul 20, 2011 at 16:12, Francois Gouget fgouget@free.fr wrote:
I have started running a script that can check for translation issues in PO files against Wine's PO files.
The issues it checks for include: * Mismatched printf format specifiers. * Mismatched trailing ellipsis. * Other mismatched trailing punctuation like full stop, question mark, space, etc. * Mismatched line feeds, trailing or not. * Spaces followed by line feeds. * Untranslated strings.
Just wondering, does your tool also check for spaces before/after punctuation like e.g. "? . ; :" ? Or only for trailing spaces at the end of msgid/msgstr strings? IMHO the checks should only be made for trailing spaces because different languages have different punctuation rules (e.g. '?' demands a preceding space in French, but not in English)
Frédéric
On Wed, 20 Jul 2011, Frédéric Delanoy wrote:
On Wed, Jul 20, 2011 at 16:12, Francois Gouget fgouget@free.fr wrote:
I have started running a script that can check for translation issues in PO files against Wine's PO files.
The issues it checks for include: * Mismatched printf format specifiers. * Mismatched trailing ellipsis. * Other mismatched trailing punctuation like full stop, question mark, space, etc. * Mismatched line feeds, trailing or not. * Spaces followed by line feeds. * Untranslated strings.
Just wondering, does your tool also check for spaces before/after punctuation like e.g. "? . ; :" ? Or only for trailing spaces at the end of msgid/msgstr strings?
In the above, when I said 'trailing' I meant 'at the end of msgid/msgstr'. Sorry for the confusion.
Checking that ':;!?' are preceded by an unbreakable space in French would be nice. It would not be very hard to add that check.
But I wonder what's the official word is on unbreakable spaces. It's quite confusing because they seem to be used both in GUI elements (e.g. in comdlg32) and in things like usage and error messages that go to the terminal (e.g. cmd). Yet there is also about 205 locations that use a regular space or nothing instead. So is there circumstances where they must be avoided?
Checking that ':;!?' are preceded by an unbreakable space in French would be nice. It would not be very hard to add that check.
But I wonder what's the official word is on unbreakable spaces. It's quite confusing because they seem to be used both in GUI elements (e.g. in comdlg32) and in things like usage and error messages that go to the terminal (e.g. cmd). Yet there is also about 205 locations that use a regular space or nothing instead. So is there circumstances where they must be avoided?
I added simple non-breaking space due to a variety of display problems for different apps. In fact, it's even more complicated since there are thin non-breaking space and normal-sized breaking spaces in French typography, and some chars are not present in certain unicode versions IIRC (+ a couple of various Windows bugs as well).
For more information, see for instance
http://malaria.perso.sfr.fr/fines/fines.pdf http://listes.traduc.org/pipermail/traduc/2010-August/006615.html (for the associated thread) http://traduc.org/gnomefr/Typographie
Frédéric
On Wed, 20 Jul 2011, Frédéric Delanoy wrote: [...]
I added simple non-breaking space due to a variety of display problems for different apps.
Ah, that's interesting. So not using non-breaking spaces can break applications. I was more expecting the reverse to happen.
In fact, it's even more complicated since there are thin non-breaking space and normal-sized breaking spaces in French typography, and some chars are not present in certain unicode versions IIRC (+ a couple of various Windows bugs as well).
I think we can ignore thin non-breaking spaces like everyone else (Gnomefr for instance). At least for now. However, based on your previous comment and the fines.pdf report, it seems like putting non-breaking spaces everywhere in Wine should be safe enough. Does anyone object?
Francois Gouget fgouget@free.fr writes:
I think we can ignore thin non-breaking spaces like everyone else (Gnomefr for instance). At least for now. However, based on your previous comment and the fines.pdf report, it seems like putting non-breaking spaces everywhere in Wine should be safe enough. Does anyone object?
That's only necessary for messages that get wrapped automatically, i.e. in message boxes. In general you don't want it for things that are shown on the command line.
On Thu, 21 Jul 2011, Alexandre Julliard wrote:
Francois Gouget fgouget@free.fr writes:
I think we can ignore thin non-breaking spaces like everyone else (Gnomefr for instance). At least for now. However, based on your previous comment and the fines.pdf report, it seems like putting non-breaking spaces everywhere in Wine should be safe enough. Does anyone object?
That's only necessary for messages that get wrapped automatically, i.e. in message boxes. In general you don't want it for things that are shown on the command line.
It sounds like following these rules will be complex which means they won't really be followed. Also for places where it makes no difference I'd prefer to use the typographically correct string.
So my preference would be that we use non-breaking spaces everywhere except where they break things, and I'm hoping the exception is either 'never' or 'except in command line applications' which would be simple enough.
Do we actually have evidence that regular (non-thin) non-breaking spaces break things on the command line? According to the fines.pdf report they seem to be working everywhere (except in mrxvt which I'll just ignore). I suspect the author did not test any non-UTF8 locale however...
http://malaria.perso.sfr.fr/fines/fines.pdf
2011/7/20 Francois Gouget fgouget@free.fr:
On Wed, 20 Jul 2011, Frédéric Delanoy wrote: [...]
I added simple non-breaking space due to a variety of display problems for different apps.
Ah, that's interesting. So not using non-breaking spaces can break applications. I was more expecting the reverse to happen.
Huh. Must has mistyped... of course I meant using normal breaking spaces to prevent problems
Sorry about that.
Frédéric
-
Alexandre Julliard -
Francois Gouget -
Frédéric Delanoy