Tool Standards

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Tool Standards

David Farning
I am working on making Launchpad, Ubuntu's translation tool, capable of
handling Mozilla type translations.

Launchpad is a .po based product.  There is a very good tool set,
translate toolkit, available that can can do the moz2po and po2moz
transformations for us.  In preparation for this rollout I have been
doing some quality assurance which can be found at
http://www.rtklib.org/roundtriptests/ At this stage I am just running a
straightforward moz2po -> po2moz transformation and running diff across
the original and new .xpi files.

I am finding two types of differences. One, Errors in data
transformation.  These can be dealt with by fixing bugs in the translate
toolkit code.  And two, differences in the layout and format of the .dtd
and .properties files.  These can be dealt with by establishing coding
standards which all translation tools follow.

I have started a wiki page on code standards at
http://wiki.mozilla.org/L10n:ToolStandards

thanks
-dtf

_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Tool Standards

Axel Hecht
David Farning wrote:

> I am working on making Launchpad, Ubuntu's translation tool, capable of
> handling Mozilla type translations.
>
> Launchpad is a .po based product.  There is a very good tool set,
> translate toolkit, available that can can do the moz2po and po2moz
> transformations for us.  In preparation for this rollout I have been
> doing some quality assurance which can be found at
> http://www.rtklib.org/roundtriptests/ At this stage I am just running a
> straightforward moz2po -> po2moz transformation and running diff across
> the original and new .xpi files.
>
> I am finding two types of differences. One, Errors in data
> transformation.  These can be dealt with by fixing bugs in the translate
> toolkit code.  And two, differences in the layout and format of the .dtd
> and .properties files.  These can be dealt with by establishing coding
> standards which all translation tools follow.
>
> I have started a wiki page on code standards at
> http://wiki.mozilla.org/L10n:ToolStandards
>

Do me a favour, and, just for a minute, look at what you propose here
and think of an HTML editor while doing so.

You wouldn't even shortly consider using an HTML editor that would bork
your html because you didn't stick to it's whitespacing style, right?

If we made up rules for source code formatting, I'd make up completely
different rules, like, l10n files need to be copies of the en-US files
with modifications just in the contributor section and the values of the
localizations strings.

But this is not what the world looks like, with hetorgenous tools from
vim to Mozilla Translator to po-roundtrips.

Thus, the rules are "stick to the format the parser parses, and still
use numeric encoding in properties".
If we change that rule, it's likely to start with that additional
sentence, but that needs a wider discussion.

Axel
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Tool Standards

Dwayne Bailey
On Tue, 2005-11-15 at 11:52 +0100, Axel Hecht wrote:

> David Farning wrote:
> > I am working on making Launchpad, Ubuntu's translation tool, capable of
> > handling Mozilla type translations.
> >
> > Launchpad is a .po based product.  There is a very good tool set,
> > translate toolkit, available that can can do the moz2po and po2moz
> > transformations for us.  In preparation for this rollout I have been
> > doing some quality assurance which can be found at
> > http://www.rtklib.org/roundtriptests/ At this stage I am just running a
> > straightforward moz2po -> po2moz transformation and running diff across
> > the original and new .xpi files.
> >
> > I am finding two types of differences. One, Errors in data
> > transformation.  These can be dealt with by fixing bugs in the translate
> > toolkit code.  And two, differences in the layout and format of the .dtd
> > and .properties files.  These can be dealt with by establishing coding
> > standards which all translation tools follow.
> >
> > I have started a wiki page on code standards at
> > http://wiki.mozilla.org/L10n:ToolStandards
> >
>
> Do me a favour, and, just for a minute, look at what you propose here
> and think of an HTML editor while doing so.
>
> You wouldn't even shortly consider using an HTML editor that would bork
> your html because you didn't stick to it's whitespacing style, right?
>
> If we made up rules for source code formatting, I'd make up completely
> different rules, like, l10n files need to be copies of the en-US files
> with modifications just in the contributor section and the values of the
> localizations strings.
>
> But this is not what the world looks like, with hetorgenous tools from
> vim to Mozilla Translator to po-roundtrips.
>
> Thus, the rules are "stick to the format the parser parses, and still
> use numeric encoding in properties".
> If we change that rule, it's likely to start with that additional
> sentence, but that needs a wider discussion.

Actually a more important step for me would be for coders to follow a
naming convention for accelerator entities.

What works well now is:

saveAs.label
saveAs.accesskey

But in some files you get

saveAs
saveas_accesskey

and lots and lots of alternatives.

--
Dwayne Bailey
Translate.org.za

+27-12-460-1095 (w)
+27-83-443-7114 (cell)

_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Tool Standards

Ognyan Kulev
Dwayne Bailey wrote:
> Actually a more important step for me would be for coders to follow a
> naming convention for accelerator entities.

There is tracking bug for that:
<https://bugzilla.mozilla.org/show_bug.cgi?id=314785>, but I won't work
on it before 1.5 is released and I start tracking HEAD in my locale (bg).

Regards,
ogi
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Tool Standards

Axel Hecht
In reply to this post by Axel Hecht
Dwayne Bailey wrote:

> On Tue, 2005-11-15 at 11:52 +0100, Axel Hecht wrote:
>> David Farning wrote:
>>> I am working on making Launchpad, Ubuntu's translation tool, capable of
>>> handling Mozilla type translations.
>>>
>>> Launchpad is a .po based product.  There is a very good tool set,
>>> translate toolkit, available that can can do the moz2po and po2moz
>>> transformations for us.  In preparation for this rollout I have been
>>> doing some quality assurance which can be found at
>>> http://www.rtklib.org/roundtriptests/ At this stage I am just running a
>>> straightforward moz2po -> po2moz transformation and running diff across
>>> the original and new .xpi files.
>>>
>>> I am finding two types of differences. One, Errors in data
>>> transformation.  These can be dealt with by fixing bugs in the translate
>>> toolkit code.  And two, differences in the layout and format of the .dtd
>>> and .properties files.  These can be dealt with by establishing coding
>>> standards which all translation tools follow.
>>>
>>> I have started a wiki page on code standards at
>>> http://wiki.mozilla.org/L10n:ToolStandards
>>>
>> Do me a favour, and, just for a minute, look at what you propose here
>> and think of an HTML editor while doing so.
>>
>> You wouldn't even shortly consider using an HTML editor that would bork
>> your html because you didn't stick to it's whitespacing style, right?
>>
>> If we made up rules for source code formatting, I'd make up completely
>> different rules, like, l10n files need to be copies of the en-US files
>> with modifications just in the contributor section and the values of the
>> localizations strings.
>>
>> But this is not what the world looks like, with hetorgenous tools from
>> vim to Mozilla Translator to po-roundtrips.
>>
>> Thus, the rules are "stick to the format the parser parses, and still
>> use numeric encoding in properties".
>> If we change that rule, it's likely to start with that additional
>> sentence, but that needs a wider discussion.
>
> Actually a more important step for me would be for coders to follow a
> naming convention for accelerator entities.
>
> What works well now is:
>
> saveAs.label
> saveAs.accesskey
>
> But in some files you get
>
> saveAs
> saveas_accesskey
>
> and lots and lots of alternatives.
>

File bugs on those please, probably component-wise, and CC
[hidden email]. Patches should be easy to do, and I'd probably want to
see one patch covering the mozilla /cvsroot code and a separate one
fixing the localizations, as I may take the freedom to check those in
across all locales, maybe with a short warning.

These fixes will not go on the 1.5 branch, though.

Axel
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Tool Standards

David Farning
In reply to this post by Axel Hecht
On Tue, 2005-11-15 at 11:52 +0100, Axel Hecht wrote:

> David Farning wrote:
> > I am working on making Launchpad, Ubuntu's translation tool, capable of
> > handling Mozilla type translations.
> >
> > Launchpad is a .po based product.  There is a very good tool set,
> > translate toolkit, available that can can do the moz2po and po2moz
> > transformations for us.  In preparation for this rollout I have been
> > doing some quality assurance which can be found at
> > http://www.rtklib.org/roundtriptests/ At this stage I am just running a
> > straightforward moz2po -> po2moz transformation and running diff across
> > the original and new .xpi files.
> >
> > I am finding two types of differences. One, Errors in data
> > transformation.  These can be dealt with by fixing bugs in the translate
> > toolkit code.  And two, differences in the layout and format of the .dtd
> > and .properties files.  These can be dealt with by establishing coding
> > standards which all translation tools follow.
> >
> > I have started a wiki page on code standards at
> > http://wiki.mozilla.org/L10n:ToolStandards
> >
>
> Do me a favour, and, just for a minute, look at what you propose here
> and think of an HTML editor while doing so.
>
> You wouldn't even shortly consider using an HTML editor that would bork
> your html because you didn't stick to it's whitespacing style, right?

I maybe should have use the term coding style rather than coding standard.
I am not at all advocating that non-compliant code bork the parser.
Rather, I am suggesting the translators and translation tools agree on
some formatting styles to reduce 'false positives' differences in cvs.

> If we made up rules for source code formatting, I'd make up completely
> different rules, like, l10n files need to be copies of the en-US files
> with modifications just in the contributor section and the values of the
> localizations strings.
>
> But this is not what the world looks like, with hetorgenous tools from
> vim to Mozilla Translator to po-roundtrips.

This is exactly the situation at which I am looking.  If we can agree on
some formatting standards, translators can use whatever tool the feel
most comfortable with.  Knowing that only the data that they are
changing is trigging diffs in the cvs.


> Thus, the rules are "stick to the format the parser parses, and still
> use numeric encoding in properties".
> If we change that rule, it's likely to start with that additional
> sentence, but that needs a wider discussion.
>
The gcc parser can accept an entire program that is written on one line.
Yet, all major projects have established coding standards which make it
easier for their developer to work together.  

thanks
-dtf

_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Tool Standards

Robert Kaiser
In reply to this post by Axel Hecht
David Farning schrieb:
> The gcc parser can accept an entire program that is written on one line.
> Yet, all major projects have established coding standards which make it
> easier for their developer to work together.  

Yes, and we have the basic rule that localized files should basically
look exactly like the original en-US files with just the strings
themselves changed to the translated versions (and maybe the localizer
added to the "Contributors" section of the license header).

We can't force tools to follow that exectly though, as we are already
using a big bunch of tools that don't respect that (some because it's
hard, some because of historical development where xpi packages were
more important than L10n source files).

We'd like to encourage new tools to follow that though.

Robert Kaiser
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n