Re: [babel-dev] Release strategy needed

[Jens Seidel <jensseidel@xxxxxxxxxxxx>]

On Wed, Oct 15, 2008 at 01:45:31PM -0400, Denis Roy wrote:
> My comments follow...

I will need some time to carefully read it but let me clarify one point.

> Jens Seidel wrote:
>> This means that invalid PO files will never be used. It is of course possible
>> that a translation is wrong, contains typos
> This is exactly the problem we are tackling here -- a bad *translation*.  
> The English string is OK. 

I considered a bad syntax, e.g. wrong usage of string template
parameters (e.g. "{1}") in translations as syntax error and not as
ordinary translation error (but it is of course an error made by a
translator).

I tried to say that a wrong translation of
"{0} ({1})" into "{0}{{1}}"
can be easily tested by checking some syntax rules.

These rules could be:
 * If the English text contains "{d}" where d is a diget, ensure that
   the translation contains it as well (and only once?).
 * Ensure that invalid constructs such as {{d}} so not happen (is {(d)}
   legal?).
 * If the translation contains {d} the English string should contain it
   as well.

Of course it's possible that a verbatim "{1}" in the output text is
allowed (which may be translated into some random string) and not used as
variable but this is probably a rare case.

> Unless I'm misunderstanding your points, I think you have a  
> misconception about Babel.  Eclipse, and the Eclipse projects that are  

Maybe :-) Will check your ressources.

>> So I suggest you just add a similar check to your Java format strings.
>>   
> Yes, that is what I was suggesting...  We know the English string is  
> good, we simply need something to evaluate the translated values,  
> syntactically.

I thought you wrote about either manual proofreads of each string (very
time consuming and suggested but not strictly required) or something
as unit tests for the translation infrastructure (is "hello world"
properly translated into "Hallo Welt" in the UI?).

If you suggested indeed some automatic syntax checks of translations
which can happen all the time (not only during a string freeze) than
I have to confess I didn't understand it :-)

> The scope of Babel is to leverage the community to translate those  
> externalized strings.  The web UI translation tool (at  

I consider syntax checks of translations as part of the translation
process. As "{0} ({1})" can be bogusly translated this process is
currently incomplete.

http://en.wikipedia.org/wiki/.properties
contains a link to prop2po which converts Java properties files
into PO files. You could now use PO file syntax checkers such as
"msgfmt --check" on the PO file or even more advanced tools
such as pofilter (http://en.wikipedia.org/wiki/Translate_Toolkit,
http://translate.sourceforge.net/wiki/toolkit/pofilter)
which checks for matching capitalisation, accelerators, variables,
punctuation marks, ...

I don't know if PO files resulting from prop2po can be properly
checked but at least a few tests could probably be reused.

>> I only once tried to translate an Eclipse plugin (Subclipse) and it was
>> hard. The file to be translated wasn't even a simple text file
>> (contained a funny encoding) and did not even contained English strings
>> as template.
>>   
> It probably wasn't i8lized properly as I have described above.

Yep, the problem was that Subclipse is an external project and I think
cannot be used with babel that's why (I'm not completely sure).
The most funny issue: My translation wasn't committed because the
author (who knows Java well) has no knowledge of i18n and wanted
first to develop a method to allow users to easily disable usage of
translations (gettext equivalent would be setting the environment
variable LANG=C).

Jens