incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Pescetti <pesce...@apache.org>
Subject Re: proposal for new l10n workflow
Date Thu, 25 Oct 2012 21:01:21 GMT
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.

Mime
View raw message