You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by jan iversen <ja...@gmail.com> on 2012/10/21 18:14:05 UTC
proposal for new l10n workflow
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 developers a change to speak their mind, it
is also posted on l10n, for the more translators who are of course heavily
influenced.
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
Re: proposal for new l10n workflow
Posted by jan iversen <ja...@gmail.com>.
Thanks a lot for your long and informative answer, I read it with a
positive attitude and will just make one comment, it is hard to be new
especially with the state of documentation we have. I will in the future
make a lot less noise.
I will work your comments into my proposal, and in general I agree it is
better to extend existing tools than to make new ones.
There is however one misunderstanding (probably due to my formulations)
that I need to correct, the l10n upload/download feature was NOT to
circumvent the system, but to allow contributors to upload files without
having to go through private mail adresses/bugzilla etc.
Thanks for using time on my proposal.
Jan.
On 25 October 2012 23:01, Andrea Pescetti <pe...@apache.org> wrote:
> On 21/10/2012 jan iversen wrote:
>
>> I have finally finished my proposal for a new workflow.
>> please have a look at:
>> http://wiki.openoffice.org/**wiki/File:L10procNew.pdf<http://wiki.openoffice.org/wiki/File:L10procNew.pdf>
>>
>
> It seems I'm the first one who replies after having read your document in
> full. And the quality of your proposal is not the issue here: on the
> contrary, it is a very good one and I'm answering in detail below. So the
> issue must be somewhere else. I'm confident you will understand that I'm
> not criticizing or lecturing you here, and I'm not implying any of the
> items below to be you fault (none is); but maybe this will help you in
> getting better feedback in future.
>
> 1) Unfortunate timing. We've just graduated, the Apache Conference is
> coming in about one week, we need to relocate all infrastructure... It's a
> busy period, so we may be less responsive than usual.
>
> 2) Excess of communication. If all people on this list had written as much
> as you did in the last 24 hours to the OpenOffice lists, ooo-dev would have
> received a message every 9 seconds! If you make yourself manageable it will
> be easier for us to answer your requests with less confusion.
>
> 3) Dispersion of communication. Discussion about your proposal is
> scattered in three different threads across ooo-dev and ooo-l10n (not
> counting private e-mails); if you need to send a message to multiple lists,
> and this is a good example, it's best to send one message to two lists (and
> specify which one should receive answers) since answers will be grouped in
> the same discussion for people who are reading e-mail by discussions.
>
> 4) Proposal format. Uploading a PDF is very convenient but it does not
> make others feel empowered to really contribute. I would have applied a
> dozen typo fixes to your proposal if it had been available as a wiki page.
> Others might have done the same.
>
> OK, enough said. The proposal has significant merit, so let's focus on
> that for the rest of this message. It won't be short: it's still a 20-page
> document.
>
> The main reasons to drive it forward are:
> - It puts us back in total control of the l10n process, with no need to
> rely on partially broken or lost tools.
> - It reduces the number of steps strings must go through for being
> translated and imported back.
> - It automates a number of operations that have been manual so far.
> - It allows to have a proper version control for translations.
>
> In general, I think the document would benefit from some knowledge about
> how the process works with established teams:
> - There is a "string freeze" date in the release schedule (this concept
> needn't be taken away: for sure we still want a string freeze even if tools
> allow a continuous localization; translators shouldn't have the surprise to
> see new strings appear in the last weeks before a release)
> - After string freeze, strings are made available in Pootle (and this
> happens automatically in your proposal)
> - Volunteers pick a file, usually a help file and the main application
> related to it (so, the "sw" module for Writer and its help file; and,
> answering another message from you, the subdivision you propose would be
> OK). Here indeed it is helpful to know that a file has been taken,
> something that volunteers track manually at the moment. Volunteers do not
> have time constraints and may well take two weeks to complete their
> assignments: the "4 days" you propose are not realistic for most teams.
> - Nobody works on Pootle. This has nothing to do with rights, it is
> totally incorrect to see Pootle as the "committers tool". The Pootle server
> used to be slow and not responsive and anyway, as a matter of fact, most
> people, including me, prefer to work with downloaded files.
> - Volunteers mark all strings they touched as "fuzzy" to distinguish them;
> if I understand correctly, a XLIFF based workflow here would suggest to
> mark the strings as "to be reviewed".
> - Other volunteers (in general one person per language) review the
> translations, collect all files and make them available to developers
> (Bugzilla, personal web space, e-mail...)
>
> So we already have a (kind of) "team coordinator" who reviews the files
> and is a committer. Again: you can assume that we have a person per
> language who is a committer (new languages go through a brief transition
> phase, but as you probably understood from the 20-30 daily answers you
> receive from committers, we try to be rather active in mentoring and
> helping in this transition phase).
>
> Now I don't see the need for the web application you propose for
> l10n.openoffice.org. It seems a way to circumvent the policy in order to
> allow non-committers to do something that committers can do: but if the
> policy is problematic, we'd rather discuss and change it than building
> tools to circumvent it. And, under the assumption that for each language we
> have a reviewer/committer, I would just use the Pootle functions for that.
> Pootle already offers: download, upload, visual representation of
> translation progress, integration with version control (but this might be
> simpler than what's required here). In short, instead of building new
> tools, I would investigate what's needed to configure/enhance Pootle to
> implement the workflow you envision, assuming we have a reviewer/committer
> for each language.
>
> A tool that, instead, would be extremely useful to our translators would
> be something where they can see the context of the string they are
> translating. I didn't see it in your document, but every string has a
> "KeyID" that makes it possible to identify it uniquely, and you can build
> OpenOffice making a "kid build" (possibly --with-lang=kid ?) which will add
> the key to every string. If we had a way, any way, where translators could
> see a screenshot showing their string in context (i.e., the "Next" I'm
> translating now is string KeyID "abc123" and thus the string "Next-abc123"
> displayed in this screenshot taken in the kid build) this would help them
> immensely. For the record, we removed Testtool from the sources recently
> but it allowed taking automated screenshots, and could maybe have been
> helpful here.
>
> The rest is fine, definitely.
>
> I'm only a bit reluctant on the idea that building OpenOffice (page 13)
> may result (if I get it right) in resources to be committed again. First,
> we don't want to depend on version control (I mean: the build can well be
> made on a "svn export", or an anonymous checkout, or two developers can
> build simultaneously); second, committing something from a partial build is
> probably best avoided; third, our snapshots are usually based on a specific
> revision or tag, so building them shouldn't create a new revision. I
> understand that the build will of course work even if the language files
> are not committed, but maybe there is some other way to enforce consistency
> between code and language files (or we just agree that we will enforce it
> just before tagging).
>
> For PO vs XLIFF, it would help to have a list of tools listed in each
> paragraph, but this is a tangential issue so far.
>
> Regards,
> Andrea.
>
Re: proposal for new l10n workflow
Posted by jan iversen <ja...@gmail.com>.
Just to keep you all informed, that project plan has been updated and
extended according to the latest request for change.
Jan.
http://wiki.openoffice.org/wiki/Localization_AOO/workPlan
On 30 October 2012 16:56, Jürgen Schmidt <jo...@gmail.com> wrote:
> On 10/30/12 2:45 PM, jan iversen wrote:
> > If my page needs updating, feel free to do so, I actually copied all the
> > scripts things from the other page.
>
> I see it now, I must have been blind earlier, sorry for the confusion
>
> Juergen
>
>
> >
> > jan.
> >
> > On 30 October 2012 14:28, Jürgen Schmidt <jo...@gmail.com> wrote:
> >
> >> On 10/30/12 1:33 PM, jan iversen wrote:
> >>> I just double checked:
> >>>
> >>> the pointer is: Localization
> >>> AOO<http://wiki.openoffice.org/wiki/Localization_AOO>, which clearly
> >>> stated (the very first lines of the document)
> >>>
> >>> "This document is based on and extents
> >>> Localization_for_developers<
> >> http://wiki.openoffice.org/wiki/Localization_for_developers>.
> >>> The document is work in progress showing the result of a detailed
> >> technical
> >>> analysis of the current process (version 3.4.1) . As such this document
> >>> should be seen as a replacement of
> >>> Localization_for_developers<
> >> http://wiki.openoffice.org/wiki/Localization_for_developers>
> >>> ."
> >>
> >> I simply missed some basic info how the tools have to be used etc.. I
> >> was confused...
> >>
> >>>
> >>>
> >>> But I will happely remove it if you prefer, but then where do I put a
> >> link
> >>> to the more detailed description of the CURRENT process.
> >>
> >> no need to remove it now, I know whats behind and as long as nobody
> >> delete it I am fine
> >>
> >> Juergen
> >>
> >>>
> >>> jan.
> >>>
> >>> On 30 October 2012 13:30, jan iversen <ja...@gmail.com> wrote:
> >>>
> >>>> I am guilty.
> >>>>
> >>>> see below.
> >>>>
> >>>>
> >>>> On 30 October 2012 13:22, Jürgen Schmidt <jo...@gmail.com>
> wrote:
> >>>>
> >>>>> On 10/27/12 10:51 PM, jan iversen wrote:
> >>>>>> 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.
> >>>>>
> >>>>> I noticed that somebody put an "outdated" template on
> >>>>> http://wiki.openoffice.org/wiki/Localization_for_developers which I
> >>>>> think is a little bit early.
> >>>>>
> >>>>> The new page is a great resource to discuss a new workflow and
> >> necessary
> >>>>> improvements. But the currently "Localization for developers" page
> >>>>> describes how it works today.
> >>>>>
> >>>> The page it points to, is NOT the new proposal, that would be wrong,
> but
> >>>> the first I made with a more detailed description of how it works
> today.
> >>>>
> >>>> I hope that is ok ?
> >>>>
> >>>>>
> >>>>> We should avoid confusion here, the new process is under development
> >> yet
> >>>>> but not available yet.
> >>>>>
> >>>> I totally agree, and I have not made links that suggest otherwise.
> >>>>
> >>>>
> >>>>>
> >>>>> Juergen
> >>>>>
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
Re: proposal for new l10n workflow
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 10/30/12 2:45 PM, jan iversen wrote:
> If my page needs updating, feel free to do so, I actually copied all the
> scripts things from the other page.
I see it now, I must have been blind earlier, sorry for the confusion
Juergen
>
> jan.
>
> On 30 October 2012 14:28, Jürgen Schmidt <jo...@gmail.com> wrote:
>
>> On 10/30/12 1:33 PM, jan iversen wrote:
>>> I just double checked:
>>>
>>> the pointer is: Localization
>>> AOO<http://wiki.openoffice.org/wiki/Localization_AOO>, which clearly
>>> stated (the very first lines of the document)
>>>
>>> "This document is based on and extents
>>> Localization_for_developers<
>> http://wiki.openoffice.org/wiki/Localization_for_developers>.
>>> The document is work in progress showing the result of a detailed
>> technical
>>> analysis of the current process (version 3.4.1) . As such this document
>>> should be seen as a replacement of
>>> Localization_for_developers<
>> http://wiki.openoffice.org/wiki/Localization_for_developers>
>>> ."
>>
>> I simply missed some basic info how the tools have to be used etc.. I
>> was confused...
>>
>>>
>>>
>>> But I will happely remove it if you prefer, but then where do I put a
>> link
>>> to the more detailed description of the CURRENT process.
>>
>> no need to remove it now, I know whats behind and as long as nobody
>> delete it I am fine
>>
>> Juergen
>>
>>>
>>> jan.
>>>
>>> On 30 October 2012 13:30, jan iversen <ja...@gmail.com> wrote:
>>>
>>>> I am guilty.
>>>>
>>>> see below.
>>>>
>>>>
>>>> On 30 October 2012 13:22, Jürgen Schmidt <jo...@gmail.com> wrote:
>>>>
>>>>> On 10/27/12 10:51 PM, jan iversen wrote:
>>>>>> 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.
>>>>>
>>>>> I noticed that somebody put an "outdated" template on
>>>>> http://wiki.openoffice.org/wiki/Localization_for_developers which I
>>>>> think is a little bit early.
>>>>>
>>>>> The new page is a great resource to discuss a new workflow and
>> necessary
>>>>> improvements. But the currently "Localization for developers" page
>>>>> describes how it works today.
>>>>>
>>>> The page it points to, is NOT the new proposal, that would be wrong, but
>>>> the first I made with a more detailed description of how it works today.
>>>>
>>>> I hope that is ok ?
>>>>
>>>>>
>>>>> We should avoid confusion here, the new process is under development
>> yet
>>>>> but not available yet.
>>>>>
>>>> I totally agree, and I have not made links that suggest otherwise.
>>>>
>>>>
>>>>>
>>>>> Juergen
>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
Re: proposal for new l10n workflow
Posted by jan iversen <ja...@gmail.com>.
If my page needs updating, feel free to do so, I actually copied all the
scripts things from the other page.
jan.
On 30 October 2012 14:28, Jürgen Schmidt <jo...@gmail.com> wrote:
> On 10/30/12 1:33 PM, jan iversen wrote:
> > I just double checked:
> >
> > the pointer is: Localization
> > AOO<http://wiki.openoffice.org/wiki/Localization_AOO>, which clearly
> > stated (the very first lines of the document)
> >
> > "This document is based on and extents
> > Localization_for_developers<
> http://wiki.openoffice.org/wiki/Localization_for_developers>.
> > The document is work in progress showing the result of a detailed
> technical
> > analysis of the current process (version 3.4.1) . As such this document
> > should be seen as a replacement of
> > Localization_for_developers<
> http://wiki.openoffice.org/wiki/Localization_for_developers>
> > ."
>
> I simply missed some basic info how the tools have to be used etc.. I
> was confused...
>
> >
> >
> > But I will happely remove it if you prefer, but then where do I put a
> link
> > to the more detailed description of the CURRENT process.
>
> no need to remove it now, I know whats behind and as long as nobody
> delete it I am fine
>
> Juergen
>
> >
> > jan.
> >
> > On 30 October 2012 13:30, jan iversen <ja...@gmail.com> wrote:
> >
> >> I am guilty.
> >>
> >> see below.
> >>
> >>
> >> On 30 October 2012 13:22, Jürgen Schmidt <jo...@gmail.com> wrote:
> >>
> >>> On 10/27/12 10:51 PM, jan iversen wrote:
> >>>> 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.
> >>>
> >>> I noticed that somebody put an "outdated" template on
> >>> http://wiki.openoffice.org/wiki/Localization_for_developers which I
> >>> think is a little bit early.
> >>>
> >>> The new page is a great resource to discuss a new workflow and
> necessary
> >>> improvements. But the currently "Localization for developers" page
> >>> describes how it works today.
> >>>
> >> The page it points to, is NOT the new proposal, that would be wrong, but
> >> the first I made with a more detailed description of how it works today.
> >>
> >> I hope that is ok ?
> >>
> >>>
> >>> We should avoid confusion here, the new process is under development
> yet
> >>> but not available yet.
> >>>
> >> I totally agree, and I have not made links that suggest otherwise.
> >>
> >>
> >>>
> >>> Juergen
> >>>
> >>>>
> >>>> 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.
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>
Re: proposal for new l10n workflow
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 10/30/12 1:33 PM, jan iversen wrote:
> I just double checked:
>
> the pointer is: Localization
> AOO<http://wiki.openoffice.org/wiki/Localization_AOO>, which clearly
> stated (the very first lines of the document)
>
> "This document is based on and extents
> Localization_for_developers<http://wiki.openoffice.org/wiki/Localization_for_developers>.
> The document is work in progress showing the result of a detailed technical
> analysis of the current process (version 3.4.1) . As such this document
> should be seen as a replacement of
> Localization_for_developers<http://wiki.openoffice.org/wiki/Localization_for_developers>
> ."
I simply missed some basic info how the tools have to be used etc.. I
was confused...
>
>
> But I will happely remove it if you prefer, but then where do I put a link
> to the more detailed description of the CURRENT process.
no need to remove it now, I know whats behind and as long as nobody
delete it I am fine
Juergen
>
> jan.
>
> On 30 October 2012 13:30, jan iversen <ja...@gmail.com> wrote:
>
>> I am guilty.
>>
>> see below.
>>
>>
>> On 30 October 2012 13:22, Jürgen Schmidt <jo...@gmail.com> wrote:
>>
>>> On 10/27/12 10:51 PM, jan iversen wrote:
>>>> 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.
>>>
>>> I noticed that somebody put an "outdated" template on
>>> http://wiki.openoffice.org/wiki/Localization_for_developers which I
>>> think is a little bit early.
>>>
>>> The new page is a great resource to discuss a new workflow and necessary
>>> improvements. But the currently "Localization for developers" page
>>> describes how it works today.
>>>
>> The page it points to, is NOT the new proposal, that would be wrong, but
>> the first I made with a more detailed description of how it works today.
>>
>> I hope that is ok ?
>>
>>>
>>> We should avoid confusion here, the new process is under development yet
>>> but not available yet.
>>>
>> I totally agree, and I have not made links that suggest otherwise.
>>
>>
>>>
>>> Juergen
>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>
>>>
>>
>
Re: proposal for new l10n workflow
Posted by jan iversen <ja...@gmail.com>.
I just double checked:
the pointer is: Localization
AOO<http://wiki.openoffice.org/wiki/Localization_AOO>, which clearly
stated (the very first lines of the document)
"This document is based on and extents
Localization_for_developers<http://wiki.openoffice.org/wiki/Localization_for_developers>.
The document is work in progress showing the result of a detailed technical
analysis of the current process (version 3.4.1) . As such this document
should be seen as a replacement of
Localization_for_developers<http://wiki.openoffice.org/wiki/Localization_for_developers>
."
But I will happely remove it if you prefer, but then where do I put a link
to the more detailed description of the CURRENT process.
jan.
On 30 October 2012 13:30, jan iversen <ja...@gmail.com> wrote:
> I am guilty.
>
> see below.
>
>
> On 30 October 2012 13:22, Jürgen Schmidt <jo...@gmail.com> wrote:
>
>> On 10/27/12 10:51 PM, jan iversen wrote:
>> > 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.
>>
>> I noticed that somebody put an "outdated" template on
>> http://wiki.openoffice.org/wiki/Localization_for_developers which I
>> think is a little bit early.
>>
>> The new page is a great resource to discuss a new workflow and necessary
>> improvements. But the currently "Localization for developers" page
>> describes how it works today.
>>
> The page it points to, is NOT the new proposal, that would be wrong, but
> the first I made with a more detailed description of how it works today.
>
> I hope that is ok ?
>
>>
>> We should avoid confusion here, the new process is under development yet
>> but not available yet.
>>
> I totally agree, and I have not made links that suggest otherwise.
>
>
>>
>> Juergen
>>
>> >
>> > 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.
>> >
>> >
>>
>>
>
Re: proposal for new l10n workflow
Posted by jan iversen <ja...@gmail.com>.
I am guilty.
see below.
On 30 October 2012 13:22, Jürgen Schmidt <jo...@gmail.com> wrote:
> On 10/27/12 10:51 PM, jan iversen wrote:
> > 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.
>
> I noticed that somebody put an "outdated" template on
> http://wiki.openoffice.org/wiki/Localization_for_developers which I
> think is a little bit early.
>
> The new page is a great resource to discuss a new workflow and necessary
> improvements. But the currently "Localization for developers" page
> describes how it works today.
>
The page it points to, is NOT the new proposal, that would be wrong, but
the first I made with a more detailed description of how it works today.
I hope that is ok ?
>
> We should avoid confusion here, the new process is under development yet
> but not available yet.
>
I totally agree, and I have not made links that suggest otherwise.
>
> Juergen
>
> >
> > 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.
> >
> >
>
>
Re: proposal for new l10n workflow
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 10/27/12 10:51 PM, jan iversen wrote:
> 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.
I noticed that somebody put an "outdated" template on
http://wiki.openoffice.org/wiki/Localization_for_developers which I
think is a little bit early.
The new page is a great resource to discuss a new workflow and necessary
improvements. But the currently "Localization for developers" page
describes how it works today.
We should avoid confusion here, the new process is under development yet
but not available yet.
Juergen
>
> 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.
>
>
Re: proposal for new l10n workflow
Posted by jan iversen <ja...@gmail.com>.
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 25 October 2012 23:01, Andrea Pescetti <pe...@apache.org> wrote:
> On 21/10/2012 jan iversen wrote:
>
>> I have finally finished my proposal for a new workflow.
>> please have a look at:
>> http://wiki.openoffice.org/**wiki/File:L10procNew.pdf<http://wiki.openoffice.org/wiki/File:L10procNew.pdf>
>>
>
> It seems I'm the first one who replies after having read your document in
> full. And the quality of your proposal is not the issue here: on the
> contrary, it is a very good one and I'm answering in detail below. So the
> issue must be somewhere else. I'm confident you will understand that I'm
> not criticizing or lecturing you here, and I'm not implying any of the
> items below to be you fault (none is); but maybe this will help you in
> getting better feedback in future.
>
> 1) Unfortunate timing. We've just graduated, the Apache Conference is
> coming in about one week, we need to relocate all infrastructure... It's a
> busy period, so we may be less responsive than usual.
>
> 2) Excess of communication. If all people on this list had written as much
> as you did in the last 24 hours to the OpenOffice lists, ooo-dev would have
> received a message every 9 seconds! If you make yourself manageable it will
> be easier for us to answer your requests with less confusion.
>
> 3) Dispersion of communication. Discussion about your proposal is
> scattered in three different threads across ooo-dev and ooo-l10n (not
> counting private e-mails); if you need to send a message to multiple lists,
> and this is a good example, it's best to send one message to two lists (and
> specify which one should receive answers) since answers will be grouped in
> the same discussion for people who are reading e-mail by discussions.
>
> 4) Proposal format. Uploading a PDF is very convenient but it does not
> make others feel empowered to really contribute. I would have applied a
> dozen typo fixes to your proposal if it had been available as a wiki page.
> Others might have done the same.
>
> OK, enough said. The proposal has significant merit, so let's focus on
> that for the rest of this message. It won't be short: it's still a 20-page
> document.
>
> The main reasons to drive it forward are:
> - It puts us back in total control of the l10n process, with no need to
> rely on partially broken or lost tools.
> - It reduces the number of steps strings must go through for being
> translated and imported back.
> - It automates a number of operations that have been manual so far.
> - It allows to have a proper version control for translations.
>
> In general, I think the document would benefit from some knowledge about
> how the process works with established teams:
> - There is a "string freeze" date in the release schedule (this concept
> needn't be taken away: for sure we still want a string freeze even if tools
> allow a continuous localization; translators shouldn't have the surprise to
> see new strings appear in the last weeks before a release)
> - After string freeze, strings are made available in Pootle (and this
> happens automatically in your proposal)
> - Volunteers pick a file, usually a help file and the main application
> related to it (so, the "sw" module for Writer and its help file; and,
> answering another message from you, the subdivision you propose would be
> OK). Here indeed it is helpful to know that a file has been taken,
> something that volunteers track manually at the moment. Volunteers do not
> have time constraints and may well take two weeks to complete their
> assignments: the "4 days" you propose are not realistic for most teams.
> - Nobody works on Pootle. This has nothing to do with rights, it is
> totally incorrect to see Pootle as the "committers tool". The Pootle server
> used to be slow and not responsive and anyway, as a matter of fact, most
> people, including me, prefer to work with downloaded files.
> - Volunteers mark all strings they touched as "fuzzy" to distinguish them;
> if I understand correctly, a XLIFF based workflow here would suggest to
> mark the strings as "to be reviewed".
> - Other volunteers (in general one person per language) review the
> translations, collect all files and make them available to developers
> (Bugzilla, personal web space, e-mail...)
>
> So we already have a (kind of) "team coordinator" who reviews the files
> and is a committer. Again: you can assume that we have a person per
> language who is a committer (new languages go through a brief transition
> phase, but as you probably understood from the 20-30 daily answers you
> receive from committers, we try to be rather active in mentoring and
> helping in this transition phase).
>
> Now I don't see the need for the web application you propose for
> l10n.openoffice.org. It seems a way to circumvent the policy in order to
> allow non-committers to do something that committers can do: but if the
> policy is problematic, we'd rather discuss and change it than building
> tools to circumvent it. And, under the assumption that for each language we
> have a reviewer/committer, I would just use the Pootle functions for that.
> Pootle already offers: download, upload, visual representation of
> translation progress, integration with version control (but this might be
> simpler than what's required here). In short, instead of building new
> tools, I would investigate what's needed to configure/enhance Pootle to
> implement the workflow you envision, assuming we have a reviewer/committer
> for each language.
>
> A tool that, instead, would be extremely useful to our translators would
> be something where they can see the context of the string they are
> translating. I didn't see it in your document, but every string has a
> "KeyID" that makes it possible to identify it uniquely, and you can build
> OpenOffice making a "kid build" (possibly --with-lang=kid ?) which will add
> the key to every string. If we had a way, any way, where translators could
> see a screenshot showing their string in context (i.e., the "Next" I'm
> translating now is string KeyID "abc123" and thus the string "Next-abc123"
> displayed in this screenshot taken in the kid build) this would help them
> immensely. For the record, we removed Testtool from the sources recently
> but it allowed taking automated screenshots, and could maybe have been
> helpful here.
>
> The rest is fine, definitely.
>
> I'm only a bit reluctant on the idea that building OpenOffice (page 13)
> may result (if I get it right) in resources to be committed again. First,
> we don't want to depend on version control (I mean: the build can well be
> made on a "svn export", or an anonymous checkout, or two developers can
> build simultaneously); second, committing something from a partial build is
> probably best avoided; third, our snapshots are usually based on a specific
> revision or tag, so building them shouldn't create a new revision. I
> understand that the build will of course work even if the language files
> are not committed, but maybe there is some other way to enforce consistency
> between code and language files (or we just agree that we will enforce it
> just before tagging).
>
> For PO vs XLIFF, it would help to have a list of tools listed in each
> paragraph, but this is a tangential issue so far.
>
> Regards,
> Andrea.
>
Re: proposal for new l10n workflow
Posted by Andrea Pescetti <pe...@apache.org>.
On 21/10/2012 jan iversen wrote:
> I have finally finished my proposal for a new workflow.
> please have a look at:
> http://wiki.openoffice.org/wiki/File:L10procNew.pdf
It seems I'm the first one who replies after having read your document
in full. And the quality of your proposal is not the issue here: on the
contrary, it is a very good one and I'm answering in detail below. So
the issue must be somewhere else. I'm confident you will understand that
I'm not criticizing or lecturing you here, and I'm not implying any of
the items below to be you fault (none is); but maybe this will help you
in getting better feedback in future.
1) Unfortunate timing. We've just graduated, the Apache Conference is
coming in about one week, we need to relocate all infrastructure... It's
a busy period, so we may be less responsive than usual.
2) Excess of communication. If all people on this list had written as
much as you did in the last 24 hours to the OpenOffice lists, ooo-dev
would have received a message every 9 seconds! If you make yourself
manageable it will be easier for us to answer your requests with less
confusion.
3) Dispersion of communication. Discussion about your proposal is
scattered in three different threads across ooo-dev and ooo-l10n (not
counting private e-mails); if you need to send a message to multiple
lists, and this is a good example, it's best to send one message to two
lists (and specify which one should receive answers) since answers will
be grouped in the same discussion for people who are reading e-mail by
discussions.
4) Proposal format. Uploading a PDF is very convenient but it does not
make others feel empowered to really contribute. I would have applied a
dozen typo fixes to your proposal if it had been available as a wiki
page. Others might have done the same.
OK, enough said. The proposal has significant merit, so let's focus on
that for the rest of this message. It won't be short: it's still a
20-page document.
The main reasons to drive it forward are:
- It puts us back in total control of the l10n process, with no need to
rely on partially broken or lost tools.
- It reduces the number of steps strings must go through for being
translated and imported back.
- It automates a number of operations that have been manual so far.
- It allows to have a proper version control for translations.
In general, I think the document would benefit from some knowledge about
how the process works with established teams:
- There is a "string freeze" date in the release schedule (this concept
needn't be taken away: for sure we still want a string freeze even if
tools allow a continuous localization; translators shouldn't have the
surprise to see new strings appear in the last weeks before a release)
- After string freeze, strings are made available in Pootle (and this
happens automatically in your proposal)
- Volunteers pick a file, usually a help file and the main application
related to it (so, the "sw" module for Writer and its help file; and,
answering another message from you, the subdivision you propose would be
OK). Here indeed it is helpful to know that a file has been taken,
something that volunteers track manually at the moment. Volunteers do
not have time constraints and may well take two weeks to complete their
assignments: the "4 days" you propose are not realistic for most teams.
- Nobody works on Pootle. This has nothing to do with rights, it is
totally incorrect to see Pootle as the "committers tool". The Pootle
server used to be slow and not responsive and anyway, as a matter of
fact, most people, including me, prefer to work with downloaded files.
- Volunteers mark all strings they touched as "fuzzy" to distinguish
them; if I understand correctly, a XLIFF based workflow here would
suggest to mark the strings as "to be reviewed".
- Other volunteers (in general one person per language) review the
translations, collect all files and make them available to developers
(Bugzilla, personal web space, e-mail...)
So we already have a (kind of) "team coordinator" who reviews the files
and is a committer. Again: you can assume that we have a person per
language who is a committer (new languages go through a brief transition
phase, but as you probably understood from the 20-30 daily answers you
receive from committers, we try to be rather active in mentoring and
helping in this transition phase).
Now I don't see the need for the web application you propose for
l10n.openoffice.org. It seems a way to circumvent the policy in order to
allow non-committers to do something that committers can do: but if the
policy is problematic, we'd rather discuss and change it than building
tools to circumvent it. And, under the assumption that for each language
we have a reviewer/committer, I would just use the Pootle functions for
that. Pootle already offers: download, upload, visual representation of
translation progress, integration with version control (but this might
be simpler than what's required here). In short, instead of building new
tools, I would investigate what's needed to configure/enhance Pootle to
implement the workflow you envision, assuming we have a
reviewer/committer for each language.
A tool that, instead, would be extremely useful to our translators would
be something where they can see the context of the string they are
translating. I didn't see it in your document, but every string has a
"KeyID" that makes it possible to identify it uniquely, and you can
build OpenOffice making a "kid build" (possibly --with-lang=kid ?) which
will add the key to every string. If we had a way, any way, where
translators could see a screenshot showing their string in context
(i.e., the "Next" I'm translating now is string KeyID "abc123" and thus
the string "Next-abc123" displayed in this screenshot taken in the kid
build) this would help them immensely. For the record, we removed
Testtool from the sources recently but it allowed taking automated
screenshots, and could maybe have been helpful here.
The rest is fine, definitely.
I'm only a bit reluctant on the idea that building OpenOffice (page 13)
may result (if I get it right) in resources to be committed again.
First, we don't want to depend on version control (I mean: the build can
well be made on a "svn export", or an anonymous checkout, or two
developers can build simultaneously); second, committing something from
a partial build is probably best avoided; third, our snapshots are
usually based on a specific revision or tag, so building them shouldn't
create a new revision. I understand that the build will of course work
even if the language files are not committed, but maybe there is some
other way to enforce consistency between code and language files (or we
just agree that we will enforce it just before tagging).
For PO vs XLIFF, it would help to have a list of tools listed in each
paragraph, but this is a tangential issue so far.
Regards,
Andrea.
Re: proposal for new l10n workflow
Posted by jan iversen <ja...@gmail.com>.
On 22 October 2012 00:01, Rob Weir <ro...@apache.org> wrote:
> On Sun, Oct 21, 2012 at 12:14 PM, jan iversen <ja...@gmail.com>
> 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'll take a closer look, but I did browse it quickly and had one question:
>
Hope you like what you read.
>
> Do we know more about what it means to have Pootle access Subversion?
> Does this need read/write access? If so, what SVN account is it
> using? Is it using credentials from the current logged in Pootle
> user? Does it need to store SVN login credentials?
>
According to the home page (I have no personal experience) will pootle use
the account you use on pootle
Yes it requires read/write access, otherwise you cannot commit your
changes, and would again have manual steps.
Andrea told me that you might meet the developer 4-5 november.
>
> Since Pootle and SVN are both ASF-wide services, managed by the
> Infrastructure team, we'll need to coordinate this carefully.
> Security concerns will weigh heavily on what is possible here.
>
I totally agree, but the real question is: how many are using pootle to
translate compared to the total number. Everybody have been telling me,
that most translation is done offline..so that is where I have put my
emphasis.
>
> -Rob
>
> > 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 developers a change to speak their mind, it
> > is also posted on l10n, for the more translators who are of course
> heavily
> > influenced.
> >
> > 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
>
Re: proposal for new l10n workflow
Posted by Rob Weir <ro...@apache.org>.
On Sun, Oct 21, 2012 at 12:14 PM, jan iversen <ja...@gmail.com> 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'll take a closer look, but I did browse it quickly and had one question:
Do we know more about what it means to have Pootle access Subversion?
Does this need read/write access? If so, what SVN account is it
using? Is it using credentials from the current logged in Pootle
user? Does it need to store SVN login credentials?
Since Pootle and SVN are both ASF-wide services, managed by the
Infrastructure team, we'll need to coordinate this carefully.
Security concerns will weigh heavily on what is possible here.
-Rob
> 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 developers a change to speak their mind, it
> is also posted on l10n, for the more translators who are of course heavily
> influenced.
>
> 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