Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jancasacondor@gmail.com
 designates 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5089A8A1.3000301@apache.org>
References: 
 <CAK2iWdTs1dZjPTW=u9L0YqdLB74o7-yrNt3W0jvTtgnZwZcBKQ@mail.gmail.com>
	<5089A8A1.3000301@apache.org>
Date: Fri, 26 Oct 2012 11:14:58 +0200
Message-ID: 
 <CAK2iWdTHuWaa4+xRxDKNRfJ_RToRenY7TY06vWM_RqWjtC7beg@mail.gmail.com>
Subject: Re: proposal for new l10n workflow
From: jan iversen <jancasacondor@gmail.com>
To: ooo-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae93b608efef52e04ccf2c035

--14dae93b608efef52e04ccf2c035
Content-Type: text/plain; charset=ISO-8859-1

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 <pescetti@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.
>

--14dae93b608efef52e04ccf2c035--