incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [Translate] Users for Pootle Server
Date Sat, 10 Mar 2012 16:46:21 GMT
On Fri, Mar 9, 2012 at 5:09 PM, Michael Bauer <> wrote:
> 09/03/2012 21:22, sgrìobh Rob Weir:
>> OK. I think we have a volunteer project admin for the AOO Pootle project.
>> That is Raphael, right?
> As an l10n admin you mean? Which would be fine. However, a single person
> can't realistically be admin to oversee all language projects from a
> linguistic point of view. While many of us can handle more than one
> language, there's no one that can handle all of them.
>> Most of us are not familiar with how it was handled before, so it is
>> good to discuss the details, so we all understand it.
> Which is why I suggested that the interested/involved parties sign up for
> accounts over on the LibreOffice Pootle server just so they see how it
> works. I *don't know* all the technicalities of how Pootle works either.

I am more interested in a high level understanding of the roles, etc.
The technical details of the exotic is something else, how we extract
strings from the build, using different tools and formats, convert
them to SDF, then to PO, then translate, then back to PO and then to
SDF and to resource files.

>> Right now it is configured so all Apache committers can login and have
>> review and commit rights.  Non-logged in users (everyone else) can
>> view, suggest and submit translations.
>> What are we missing?
>> Would it work, for example, if the translation leads become Apache
>> committers?
> This is all making localization of OO unnecessarily complicated. Looking at
> it another way - is there a way of separating the signup and rights
> management of Pootle on Apache from the rest of the rights management on
> Apache? All the necessary localization tools and processes are there within
> Pootle. The only problem we're facing is that the only signup and rights
> management path at the moment is via the standard Apache signup etc. We need
> to make the two separate.

Certainly Apache projects understand the need for there to be
contributors as well as committers.  We have many systems where
anyone, even on their first day in the project, can contribute. For
example, the wiki, the forums,submitting patches for the website, even
patches for the code.  None of these require being a committer.

However, submitting strings for localization is something that
requires more consideration than just updating a wiki page.  These
strings eventually become part of Apache releases, so we need to make
sure these contributions are given more attention.  At the very least
I think they require:

1) We know who made the contribution.  This is good from IP
perspective, but also from a community perspective.  Contributors
should get recognition for their work.  If they can only contribute
anonymously, this is a problem.  It also hinders the PMC from
recognizing active contributors and offering them committer rights.

2) We need the translations to be contributed under the Apache 2.0
license. This does not necessarily require a signed iCLA.  It could be
done with a proper notice on the Pootle server.

3) We need some mechanism for a Committer to review and commit
contributed translations.  This doesn't necessarily mean that we must
have committers that can read 110 different languages.  But it does
mean that we need a process that a Committer can follow to ensure that
the translations are of sufficient quality to be included in a
release. An example of such a process could be:

a) Committer verifies the origin of the translation strings,e.g., they
came from Pootle server from known contributors.

b) Committer verifies the integrity and completeness of the
translation.  In other words, whatever can be checked by tools without
understanding the underlying language.  If an automated smoke test can
be executed to verify that the strings don't break the build, then we
should do that as well at this stage.

c) At this point the language strings are considered "candidates" and
the committer can check the strings into SVN.  They are included in
dev snapshots as "candidate" translations, but they are not yet
included in releases yet.

d) We have some sort of community review procedure.  We rely on native
speakers to test the translations.  We probably need a proactive RTC
rather than lazy consensus.  So maybe we just wait until we get 3 +1's
votes from volunteers who have tested the translation.  When we have
that, then the translation becomes "approved" rather than "candidate".

Would something like the above work?  In this process there is no
formal "leader" for a given language.  But in practice the leader
emerges from their actions and the recognition that others working on
that language give them.  It is not something we (the AOO PMC) need to

But we would need one more Committers to volunteer to lead the process
of taking translation candidates through this process.

> I've done you some screenshots of what a locale admin account looks like in
> Pootle (
> The Overview (page 1) is, well, the overview, it shows you what projects a
> project admin has enabled for your locale cause not every locale does all
> projects. Gaelic for example isn't bothering with the Help files.
> Page 2, Permissions, is where a locale adming adminsiters which other
> registered users (the dropdown on the left) they want to assign what rights
> to. Pootle is very efficient here. It allows for very flexible handling of
> user input, ranging from pure viewing and suggesting (for folk with
> questionable language skills for example) to committing and overwriting.
> Within Pootle I hasten to add, although I can commit translations to Pootle
> or overwrite files does not mean I automatically have the rights to
> overwrite LibreOffice code.
> Page 3 is the Review screen which flags various issues such as missed
> placeholders etc. Also allows zip download of the po files (probably not to
> every users though, not sure, I've only ever had a locale leader account).
> Page 4, Overview, is where I drill down to individual po files, either to
> then translate strings online OR to upload a po file I've edited offline.
> There's more but I think those are the important bits for this discussion.
> The only thing we really need, the way I see it, is to keep the two rights
> management processes separate, then enable all the Pootle features and just
> go with what Pootle offers. At some point, someone picks up all the
> translations and ports them to wherever the black magic happens to create
> builds. Simples :)
> Salude,
> Michael

View raw message