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 dave2wave@comcast.net
 designates 76.96.30.24 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: [Translate] Users for Pootle Server
From: Dave Fisher <dave2wave@comcast.net>
In-Reply-To: 
 <CAP-ksohAm1S2ecQUZpzn9A2zU=JmYTSk33UkGX9vq1pGmEc9Fw@mail.gmail.com>
Date: Sat, 10 Mar 2012 11:04:37 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <BCF889AE-B7E1-47C2-AE88-03301DB335BE@comcast.net>
References: <4F59E9C8.6050808@akerbeltz.org>
 <CAP-ksoink-dD14W6REFFUKJevSS3Bj6XGNzetV-+_kT5gGAzvQ@mail.gmail.com>
 <4F5A7F8A.3000604@akerbeltz.org>
 <CAP-ksoig=dAdpYSvoEyOwcM4CMQOrp7a7uRDZrswGgFOUg_-KA@mail.gmail.com>
 <8380CC9E-9CCB-42AF-9CA6-C994157288CB@comcast.net>
 <CAP-ksohAm1S2ecQUZpzn9A2zU=JmYTSk33UkGX9vq1pGmEc9Fw@mail.gmail.com>
To: ooo-dev@incubator.apache.org


On Mar 10, 2012, at 10:15 AM, Rob Weir wrote:

> On Sat, Mar 10, 2012 at 12:08 PM, Dave Fisher <dave2wave@comcast.net> =
wrote:
>> Hi Rob,
>>=20
>> My comments are meant to supplement and enhance your thoughts on =
measuring merit.
>>=20
>> On Mar 10, 2012, at 8:46 AM, Rob Weir wrote:
>>=20
>>> On Fri, Mar 9, 2012 at 5:09 PM, Michael Bauer <fios@akerbeltz.org> =
wrote:
>>>>=20
>>>> 09/03/2012 21:22, sgr=ECobh Rob Weir:
>>>>=20
>>>>> OK. I think we have a volunteer project admin for the AOO Pootle =
project.
>>>>> That is Raphael, right?
>>>>=20
>>>> 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.
>>>>=20
>>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>=20
>>> 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.
>>>=20
>>>>=20
>>>>> 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.
>>>>>=20
>>>>> What are we missing?
>>>>>=20
>>>>> Would it work, for example, if the translation leads become Apache
>>>>> committers?
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>=20
>>> 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.
>>>=20
>>> 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:
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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:
>>>=20
>>> a) Committer verifies the origin of the translation strings,e.g., =
they
>>> came from Pootle server from known contributors.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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".
>>>=20
>>> 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
>>> appoint.
>>>=20
>>> But we would need one more Committers to volunteer to lead the =
process
>>> of taking translation candidates through this process.
>>=20
>> Apache set up the Pootle server for more than one project and the =
needs for AOO are much different.
>>=20
>> Michael's description of alternative registration may be configurable =
while still allowing Apache LDAP. I don't how big a lift that would be =
for the Apache Infrastructure team. If it is possible then I think that =
would make it much easier to do translation under the guidance of a few =
PPMC members.
>>=20
>=20
> This would be good to understand.

http://translate.sourceforge.net/wiki/
http://translate.sourceforge.net/wiki/pootleusers
http://translate.sourceforge.net/wiki/pootle/ldap

I am guessing that the clue is here:

# Use the commented definition to authenticate first with an LDAP system =
and=20
# then to fall back to Django's authentication system.=20

>=20
>> Another possible way to prove merit would be to provide translation =
for some of the main components of the website.
>>=20
>> - topnav buttons.
>> - main page.
>> - branding.
>> - download page.
>>=20
>> Website work satisfies many of Rob's points, the work could be used =
by the PPMC when considering an individual's merit for Committer status.
>>=20
>=20
> But once the openoffice.org homepage is translated,how to we bring in
> new translators going forward?  Say, in 2 years we get a new
> translator for a rare language for AOO 5.0, but the website is already
> translated?  I could see your approach working initially, but not sure
> how that evolves.

We will certainly have news stories and marketing messages. ... We are =
trying to get one active committer per language and then allow them to =
build their team.

It would certainly be easier if we could do have two levels of login to =
the Apache Pootle server ...

>=20
> Skill levels differ as well.  To translate a website requires some
> basic HTML, so you can handle encodings, entities, etc., correctly,
> and not break the markup.  Using Pootle to translate strings requires
> no such knowledge.  It is more pure translation.

A good part of what I propose is already in mdtext:

David-Fishers-MacBook-Air:content dave$ more brand.mdtext
home:           home
search:         search
name:           Apache OpenOffice (incubating)
tagline:        (incubating) | The Free and Open Productivity Suite
logo:           ooo-logo.png
domain:         www.openoffice.org
divid:          bannera
David-Fishers-MacBook-Air:content dave$ more topnav.mdtext
divid:  topnava

- [Product][m0]
- [Download][m1]
- [Support][m2]
- [Extend][m3]
- [Develop][m4]
- [Focus Areas][m5]
- [Native Language][m6]


[m0]:     /product/index.html                                           =
"OpenOffice.org product description"
[m1]:     /download/index.html                                          =
"Download OpenOffice.org"
[m2]:     /support/index.html                                           =
"Find Support for OpenOffice.org"
[m3]:     http://extensions.openoffice.org/                             =
"Find Extensions and Templates"
[m4]:     http://incubator.apache.org/openofficeorg/get-involved.html   =
"Get involved in Apache OpenOffice (incubating)"
[m5]:     /projects/accepted.html                                       =
"OpenOffice.org development focus areas"
[m6]:     /projects/native-lang.html                                    =
"OpenOffice.org in your Native Language"

Perhaps my best next efforts would be to convert index.html and =
downloads/index.html into mdtext / html skeletons to make this process =
much easier.

I noticed that we have a Finnish translation now in bugzilla. I'll need =
to look at it soon.


>=20
>> I will help contributors to this NL areas of the website. I'll start =
another thread about this after I write some instructions. I should have =
cycles for that in the next two days. (My apologies to anyone currently =
waiting for this.)
>>=20
>> Regards,
>> Dave
>>=20
>>=20
>>>=20
>>>> I've done you some screenshots of what a locale admin account looks =
like in
>>>> Pootle (http://www.akerbeltz.org/Process.doc)
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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).
>>>>=20
>>>> 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.
>>>>=20
>>>> 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 :)
>>>>=20
>>>> Salude,
>>>>=20
>>>> Michael
>>=20