Proposal for new l10n workflow.

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

Proposal for new l10n workflow.

jan iversen
I have finally finished my proposal for a new workflow.

please have a look at:
http://wiki.openoffice.org/wiki/File:L10procNew.pdf

I have tried to implement the comments (on the document describing the
existing workflow) from the community, and at the same time avoid
non-essential themes that seems to open discussions :-)

The workflow I have proposed is based on my knowledge from large
organizations, so I am sure it can work....but I do not know if the
community as such want it.

It has advantages for everybody:
- developers dont really see a change
- our release manager saves a lot of manual work
- offline translators become a lot closer connected to the process, without
being bugged down with technical details.

My shoulders are pretty big, so please give me your opinions and
suggestions for improvement (I am here to learn, NOT to educate). Please
remember one thing the big silent majority does not count here.

I post this mail here to give translators and NLC a change to speak their
mind, it is also posted on dev, for the more technical parts.

Once we have agreed to the content, I will undertake the development, but I
do need heavy support from a committer (mostly to commit code and publish
php/web pages).

happy reading.
JanI
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for new l10n workflow.

jan iversen
Based on the comments I have received, I have updated the document.

The major changes are:

- removed l10n web page tools
- no auto-commit in any tools
- proposed changes to pootle server (based on request from andrea, to
use/change existing tools)
- added more text on the translation workflow, inkl. local teams

The document is available as pdf:
http://wiki.openoffice.org/wiki/File:L10procNew2.pdf
and (due to a polite hint) as a wiki page:
http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal
Furthermore a projectplan is available as a wiki page:
http://wiki.openoffice.org/wiki/Localization_AOO/workPlan

this mail is posted on both ooo-L10n and ooo-dev, but please use ooo-dev
for discussions.

Andrea:
I hope you have time to see if your suggestions are well represented now,
so this document could be used as discussion basis when you meet the pootle
people.


Have a nice evening.
jan I.

On 21 October 2012 18:12, jan iversen <[hidden email]> wrote:

> I have finally finished my proposal for a new workflow.
>
> please have a look at:
> http://wiki.openoffice.org/wiki/File:L10procNew.pdf
>
> I have tried to implement the comments (on the document describing the
> existing workflow) from the community, and at the same time avoid
> non-essential themes that seems to open discussions :-)
>
> The workflow I have proposed is based on my knowledge from large
> organizations, so I am sure it can work....but I do not know if the
> community as such want it.
>
> It has advantages for everybody:
> - developers dont really see a change
> - our release manager saves a lot of manual work
> - offline translators become a lot closer connected to the process,
> without being bugged down with technical details.
>
> My shoulders are pretty big, so please give me your opinions and
> suggestions for improvement (I am here to learn, NOT to educate). Please
> remember one thing the big silent majority does not count here.
>
> I post this mail here to give translators and NLC a change to speak their
> mind, it is also posted on dev, for the more technical parts.
>
> Once we have agreed to the content, I will undertake the development, but
> I do need heavy support from a committer (mostly to commit code and publish
> php/web pages).
>
> happy reading.
> JanI
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for new l10n workflow.

Andrea Pescetti-2
On 27/10/2012 jan iversen wrote:
> Based on the comments I have received, I have updated the document.
> ... Andrea:
> I hope you have time to see if your suggestions are well represented now,
> so this document could be used as discussion basis when you meet the pootle
> people.

Thank you for the updated document. I've just finished re-reading all of
it (wiki version) and it's really good.

I made some edits on the wiki page directly, but they are just minor
clarifications, see the history of
http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal

Thank you for clarifying my previous doubts about, for example, the need
to commit language files as part of the build and for integrating my
suggestions.

A couple of left doubts/remarks:

* "We have en-GB, en-ZA but no en-US[ and no].". What does this mean?
Simply that we don't have a BugZilla subcomponent under "l10n" for en-US
strings?

* Under "Snapshot build", "publish on openOffice.org". We'd rather host
snapshots builds somewhere else, where we can publish unreleased stuff.
And in general the snapshot builds are for community testing, so it will
be enough to make them available to the community.

* Under "Tools" - "generateLanguage" you describe --extract twice, the
second one is probably --generate.

* Under "Pootle server": what you call "download fileset" is actually
already available in a limited but probably sufficient way: you can
download a ZIP file of all PO files in a certain directory (sub)tree.
The same should hold for uploads, but I'm not sure.

As I understand, Juergen will now take over and continue the discussion,
but rest assured that we will find the time during ApacheCon EU next
week to discuss this and get feedback from the people who haven't had
time to comment here.

Thanks,
   Andrea.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for new l10n workflow.

jan iversen
See below please.

jan.


On 2 November 2012 22:43, Andrea Pescetti <[hidden email]> wrote:

> On 27/10/2012 jan iversen wrote:
>
>> Based on the comments I have received, I have updated the document.
>> ... Andrea:
>>
>> I hope you have time to see if your suggestions are well represented now,
>> so this document could be used as discussion basis when you meet the
>> pootle
>> people.
>>
>
> Thank you for the updated document. I've just finished re-reading all of
> it (wiki version) and it's really good.
>
Thanks for your kind words,  I simply try to document what we all want (and
as a consequence I try to listen hard)


> I made some edits on the wiki page directly, but they are just minor
> clarifications, see the history of
> http://wiki.openoffice.org/wiki/Localization_AOO/new_Sproposal<http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal>
>
Thanks for correcting my bad language and mistakes. I cannot find any
changes I disagree with. I have also got a comment from jsc, that in
chapter 4.1 it should be a build switch and not always, that is not a
problem and corrected in wiki.

>
> Thank you for clarifying my previous doubts about, for example, the need
> to commit language files as part of the build and for integrating my
> suggestions.
>
> A couple of left doubts/remarks:
>
> * "We have en-GB, en-ZA but no en-US[ and no].". What does this mean?
> Simply that we don't have a BugZilla subcomponent under "l10n" for en-US
> strings?
>
What I meant is that we have translation to en-GB and en-ZA but there are
no translation to en-US, that is quite puzzling to me, at least I learned
that e.g. color/colour is different in EN and US.

I have corrected wiki.

>
> * Under "Snapshot build", "publish on openOffice.org". We'd rather host
> snapshots builds somewhere else, where we can publish unreleased stuff. And
> in general the snapshot builds are for community testing, so it will be
> enough to make them available to the community.
>
My failure, it is on "
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds"
corrected in wiki.


>
> * Under "Tools" - "generateLanguage" you describe --extract twice, the
> second one is probably --generate.
>
ups, corrected.

>
> * Under "Pootle server": what you call "download fileset" is actually
> already available in a limited but probably sufficient way: you can
> download a ZIP file of all PO files in a certain directory (sub)tree. The
> same should hold for uploads, but I'm not sure.
>
I did not manage to download all da files as a zip file, but I might have
overseen something. If we can download all files for a language that is ok.

For upload you have to match the file with the database image, and having
looked also in the documentation I find no hint of being able to that with
a zip file.

>
> As I understand, Juergen will now take over and continue the discussion,
> but rest assured that we will find the time during ApacheCon EU next week
> to discuss this and get feedback from the people who haven't had time to
> comment here.
>
I am in contact with Juergen, who have given me much valuable input (as
many others on different subjects).

I for sure hope that we can get all the discussion settled before I get too
deep into the development, so thanks for reading and making it a theme on
apacheCon. This development is not "piece of cake", so I will rather have
the proposal discussed in length instead of  having a new l10n mishap.


>
> Thanks,
>   Andrea.
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for new l10n workflow.

Andrea Pescetti-2
On 02/11/2012 jan iversen wrote:
> On 2 November 2012 22:43, Andrea Pescetti wrote:
>> * "We have en-GB, en-ZA but no en-US[ and no].". What does this mean?
>> Simply that we don't have a BugZilla subcomponent under "l10n" for en-US
>> strings?
> What I meant is that we have translation to en-GB and en-ZA but there are
> no translation to en-US, that is quite puzzling to me

Ok, got it. "en" (or en-US) is the interface language. There are no
translations to en-US since en-US is the original. en-GB is a
translation. So the original (en-US) would say "color", the en-GB
translation would say "colour" and so on.

Note that this has an impact on l10n: when an English ("original")
string is spelled wrong, all translations must be synchronized after it
is corrected.

> I did not manage to download all da files as a zip file, but I might have
> overseen something. If we can download all files for a language that is ok.

Yes, it is just our configuration. So you don't see it in our current
instance but it's supported by Pootle.

> I for sure hope that we can get all the discussion settled before I get too
> deep into the development

Yes, at least let's make sure that before each development phase we
leave time to others to express their opinion.

Regards,
   Andrea.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for new l10n workflow.

Rob Weir
On Sat, Nov 3, 2012 at 4:54 AM, Andrea Pescetti <[hidden email]> wrote:

> On 02/11/2012 jan iversen wrote:
>
>> On 2 November 2012 22:43, Andrea Pescetti wrote:
>>>
>>> * "We have en-GB, en-ZA but no en-US[ and no].". What does this mean?
>>> Simply that we don't have a BugZilla subcomponent under "l10n" for en-US
>>> strings?
>>
>> What I meant is that we have translation to en-GB and en-ZA but there are
>> no translation to en-US, that is quite puzzling to me
>
>
> Ok, got it. "en" (or en-US) is the interface language. There are no
> translations to en-US since en-US is the original. en-GB is a translation.
> So the original (en-US) would say "color", the en-GB translation would say
> "colour" and so on.
>
> Note that this has an impact on l10n: when an English ("original") string is
> spelled wrong, all translations must be synchronized after it is corrected.
>

In particular note that the en-US "original" strings are authored by
an international team, not all native English, speakers and some of
whom might have studied British English.  So it is always possible for
there to be errors or inconsistencies in the en-US text.  And even a
native speaker can make spelling errors.  So from a translation
quality perspective I wonder if we want to treat it the same as the
translations?

>
>> I did not manage to download all da files as a zip file, but I might have
>> overseen something. If we can download all files for a language that is
>> ok.
>
>
> Yes, it is just our configuration. So you don't see it in our current
> instance but it's supported by Pootle.
>
>
>> I for sure hope that we can get all the discussion settled before I get
>> too
>> deep into the development
>
>
> Yes, at least let's make sure that before each development phase we leave
> time to others to express their opinion.
>
> Regards,
>   Andrea.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for new l10n workflow.

jan iversen
On 3 November 2012 14:43, Rob Weir <[hidden email]> wrote:

> On Sat, Nov 3, 2012 at 4:54 AM, Andrea Pescetti <[hidden email]>
> wrote:
> > On 02/11/2012 jan iversen wrote:
> >
> >> On 2 November 2012 22:43, Andrea Pescetti wrote:
> >>>
> >>> * "We have en-GB, en-ZA but no en-US[ and no].". What does this mean?
> >>> Simply that we don't have a BugZilla subcomponent under "l10n" for
> en-US
> >>> strings?
> >>
> >> What I meant is that we have translation to en-GB and en-ZA but there
> are
> >> no translation to en-US, that is quite puzzling to me
> >
> >
> > Ok, got it. "en" (or en-US) is the interface language. There are no
> > translations to en-US since en-US is the original. en-GB is a
> translation.
> > So the original (en-US) would say "color", the en-GB translation would
> say
> > "colour" and so on.
> >
> > Note that this has an impact on l10n: when an English ("original")
> string is
> > spelled wrong, all translations must be synchronized after it is
> corrected.
> >
>
> In particular note that the en-US "original" strings are authored by
> an international team, not all native English, speakers and some of
> whom might have studied British English.  So it is always possible for
> there to be errors or inconsistencies in the en-US text.  And even a
> native speaker can make spelling errors.  So from a translation
> quality perspective I wonder if we want to treat it the same as the
> translations?
>
I am used to from other products (commercial ones) to have a en-US -> en-US
translation, simple to divide the jobs. The developer is responsible for
the code, not the text as such, and by always having a translation,
handling seems easier (all language errors are handled identically).

It is actually no fun (and causing me major merge problems), when a
developer changes the text, in essence that is a new key, so to match with
existing translations is next to impossible (linenumber are not valid,
because the developer might also have changed line).

SO I am all in favor for such a translation. In one company we did it
really well (it had 3 letters so rob you might guess which company :-) ),
the developers added a number in the text, and a text suggestion, the
number was used a unique key in that source file. It worked real well,
dividing responsibilities, and the PC/RT got some nice feed back that the
text were real usefull.


>
> >
> >> I did not manage to download all da files as a zip file, but I might
> have
> >> overseen something. If we can download all files for a language that is
> >> ok.
> >
> >
> > Yes, it is just our configuration. So you don't see it in our current
> > instance but it's supported by Pootle.
> >
> >
> >> I for sure hope that we can get all the discussion settled before I get
> >> too
> >> deep into the development
> >
> >
> > Yes, at least let's make sure that before each development phase we leave
> > time to others to express their opinion.
> >
> > Regards,
> >   Andrea.
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for new l10n workflow.

jan iversen
I had a second thought on the idea from Rob.

Would it be an idea, to change all strings in the code to e.g. [en-DEV] and
then introduce [en-US] as a normal translation.

I could easily make a "if" in the merge process, and make [en-US] default
be a copy of [en-DEV].

That way developers should never change their texts, and we would have a
consistent division between programming and localization.

I do however not know, if [en-DEV] would have an effect on dictionaries
etc. ?

rgds
Jan I.

On 3 November 2012 14:50, jan iversen <[hidden email]> wrote:

>
>
> On 3 November 2012 14:43, Rob Weir <[hidden email]> wrote:
>
>> On Sat, Nov 3, 2012 at 4:54 AM, Andrea Pescetti <[hidden email]>
>> wrote:
>> > On 02/11/2012 jan iversen wrote:
>> >
>> >> On 2 November 2012 22:43, Andrea Pescetti wrote:
>> >>>
>> >>> * "We have en-GB, en-ZA but no en-US[ and no].". What does this mean?
>> >>> Simply that we don't have a BugZilla subcomponent under "l10n" for
>> en-US
>> >>> strings?
>> >>
>> >> What I meant is that we have translation to en-GB and en-ZA but there
>> are
>> >> no translation to en-US, that is quite puzzling to me
>> >
>> >
>> > Ok, got it. "en" (or en-US) is the interface language. There are no
>> > translations to en-US since en-US is the original. en-GB is a
>> translation.
>> > So the original (en-US) would say "color", the en-GB translation would
>> say
>> > "colour" and so on.
>> >
>> > Note that this has an impact on l10n: when an English ("original")
>> string is
>> > spelled wrong, all translations must be synchronized after it is
>> corrected.
>> >
>>
>> In particular note that the en-US "original" strings are authored by
>> an international team, not all native English, speakers and some of
>> whom might have studied British English.  So it is always possible for
>> there to be errors or inconsistencies in the en-US text.  And even a
>> native speaker can make spelling errors.  So from a translation
>> quality perspective I wonder if we want to treat it the same as the
>> translations?
>>
> I am used to from other products (commercial ones) to have a en-US ->
> en-US translation, simple to divide the jobs. The developer is responsible
> for the code, not the text as such, and by always having a translation,
> handling seems easier (all language errors are handled identically).
>
> It is actually no fun (and causing me major merge problems), when a
> developer changes the text, in essence that is a new key, so to match with
> existing translations is next to impossible (linenumber are not valid,
> because the developer might also have changed line).
>
> SO I am all in favor for such a translation. In one company we did it
> really well (it had 3 letters so rob you might guess which company :-) ),
> the developers added a number in the text, and a text suggestion, the
> number was used a unique key in that source file. It worked real well,
> dividing responsibilities, and the PC/RT got some nice feed back that the
> text were real usefull.
>
>
>>
>> >
>> >> I did not manage to download all da files as a zip file, but I might
>> have
>> >> overseen something. If we can download all files for a language that is
>> >> ok.
>> >
>> >
>> > Yes, it is just our configuration. So you don't see it in our current
>> > instance but it's supported by Pootle.
>> >
>> >
>> >> I for sure hope that we can get all the discussion settled before I get
>> >> too
>> >> deep into the development
>> >
>> >
>> > Yes, at least let's make sure that before each development phase we
>> leave
>> > time to others to express their opinion.
>> >
>> > Regards,
>> >   Andrea.
>>
>
>