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.
