Re: [Translate] Users for Pootle Server

2012-03-12 Thread Paolo Pozzan
2012/3/11 Gavin McDonald ga...@16degrees.com.au:

 -Original Message-
 From: Paolo Pozzan [mailto:pa...@z2z.it]
 Sent: Sunday, 11 March 2012 7:02 AM
 To: ooo-dev@incubator.apache.org
 Subject: Re: [Translate] Users for Pootle Server

 Il 09/03/2012 22:22, Rob Weir ha scritto:
  On Fri, Mar 9, 2012 at 6:30 AM, Michael Bauerf...@akerbeltz.org  wrote:
 [cut]
  2) Allow account creating as on other Pootle servers without any
  hoops to jump through other than the usual signup process.
 
  In essence, handle Pootle and l10n as it was handled before.
 
 
  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.
 
  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.

 It's not useful to give causal contributors write access to
 translations: they usually don't know what writing style to follow and don't
 know the correct terminology. This will only mess up things or give more
 work to do to the translators. Please don't let submit rights to non-logged
 users.

 In your mind, what do you think 'submit rights' mean?

I mean the right to push the submit button of the pootle interface
when trying to modify a string. This leads to overwriting the previous
translation.

 To me it means submit a translation for approval by a committer, without such
 approval it does nothing and harms nothing. Why are you against such actions
 whilst the rest of the people in this thread are trying to open up access 
 even more?

You are talking about the suggest feature (and button). Right now
anybody can overwrite the translations without logging in at all.
I am favorable to open up access but only to translators, not everyone.

Paolo


Re: [Translate] Users for Pootle Server

2012-03-12 Thread Roberto Salomon
Opening up the editing of strings for all does not seem like a good idea.
We also need the translators to be properly identified in order to be able
to track translations to their original contributors.

Back in the good old days, the Brazilian community organized the
translation in a tree structure where volunteers translated the strings in
the PO files that would be sent to reviewers for approval before being
uploaded to the source code tree.

The use of tools such as POEdit was tedious and there was a long learning
curve for new users. Pootle is a much friendlier interface where community
volunteers can quickly contribute with suggestions, as it is.

A workable model could be deployed in such a way where reviewers would have
write access to the server in order to accept or reject translations
suggested by the community. This would keep the group of authorized users
at a manageable size while not preventing the community at large from
contributing with their translations. Local translation mailing lists could
be used to identify most of the active volunteers by asking them to
subscribe to the list in order to receive credit for their work.

Most of the community in Brazil is made up of non-programmers and being
able to recognize volunteer participation from these non-techs would be a
great help in restarting the community.


2012/3/12 Paolo Pozzan pa...@z2z.it

 2012/3/11 Gavin McDonald ga...@16degrees.com.au:
 
  -Original Message-
  From: Paolo Pozzan [mailto:pa...@z2z.it]
  Sent: Sunday, 11 March 2012 7:02 AM
  To: ooo-dev@incubator.apache.org
  Subject: Re: [Translate] Users for Pootle Server
 
  Il 09/03/2012 22:22, Rob Weir ha scritto:
   On Fri, Mar 9, 2012 at 6:30 AM, Michael Bauerf...@akerbeltz.org
  wrote:
  [cut]
   2) Allow account creating as on other Pootle servers without any
   hoops to jump through other than the usual signup process.
  
   In essence, handle Pootle and l10n as it was handled before.
  
  
   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.
  
   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.
 
  It's not useful to give causal contributors write access to
  translations: they usually don't know what writing style to follow and
 don't
  know the correct terminology. This will only mess up things or give more
  work to do to the translators. Please don't let submit rights to
 non-logged
  users.
 
  In your mind, what do you think 'submit rights' mean?

 I mean the right to push the submit button of the pootle interface
 when trying to modify a string. This leads to overwriting the previous
 translation.

  To me it means submit a translation for approval by a committer, without
 such
  approval it does nothing and harms nothing. Why are you against such
 actions
  whilst the rest of the people in this thread are trying to open up
 access even more?

 You are talking about the suggest feature (and button). Right now
 anybody can overwrite the translations without logging in at all.
 I am favorable to open up access but only to translators, not everyone.

 Paolo




-- 
Roberto Salomon
http://notaslivres.webhop.net


Re: [Translate] Users for Pootle Server

2012-03-11 Thread Claudio Filho
Hi

2012/3/10 Paolo Pozzan pa...@z2z.it:
 I think it can work. Better yet: back in OOo days various teams were able to
 choose between pootle or direct SDF submission (as Claudio said). Maybe in
 this phase of reorganization it would be helpful for the teams to choose
 their preferred method.

Is a good idea, Paolo! +1

And more that it, i think that a next step for our next release, IMHO,
is to see how we use PO or XLIFF directly, removing the SDF layer.

And, about the reorganization, i believe that understanding of tools
and workflow is a good thing, so i am also studing Pootle and other
tools, like Jürgen.

Bests,
Claudio


Re: [Translate] Users for Pootle Server

2012-03-10 Thread Michael Bauer

09/03/2012 4:52, sgrìobh filh...@gmail.com:

1) Really Pootle can be useful and we can win produtivity with it, BUT 
is possible work with other tools too;
Yes, no one is denying that. But as a base it's useful. I don't 
usually translate within Pootle myself, I export the po and work in 
Virtaal and the commit the file back.


2) This instance of Pootle, without a minimum of one person per 
language as committer, is unusable.


It's not even that. Currently the model is Anyone is a suggester, 
heaven knows who is a committer. That's one of the things I've been 
criticizing, AFAIK, there is currently no such thing as a locale 
leader/committer.


Michael


Re: [Translate] Users for Pootle Server

2012-03-10 Thread Rob Weir
On Fri, Mar 9, 2012 at 5:09 PM, Michael Bauer f...@akerbeltz.org 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
appoint.

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 (http://www.akerbeltz.org/Process.doc)

 The Overview (page 1) is, well, the 

Re: [Translate] Users for Pootle Server

2012-03-10 Thread Dave Fisher
Hi Rob,

My comments are meant to supplement and enhance your thoughts on measuring 
merit.

On Mar 10, 2012, at 8:46 AM, Rob Weir wrote:

 On Fri, Mar 9, 2012 at 5:09 PM, Michael Bauer f...@akerbeltz.org 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
 appoint.
 
 But we would need one more Committers to volunteer to lead the process
 of 

Re: [Translate] Users for Pootle Server

2012-03-10 Thread Rob Weir
On Sat, Mar 10, 2012 at 12:08 PM, Dave Fisher dave2w...@comcast.net wrote:
 Hi Rob,

 My comments are meant to supplement and enhance your thoughts on measuring 
 merit.

 On Mar 10, 2012, at 8:46 AM, Rob Weir wrote:

 On Fri, Mar 9, 2012 at 5:09 PM, Michael Bauer f...@akerbeltz.org 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
 appoint.

 But we would need one 

Re: [Translate] Users for Pootle Server

2012-03-10 Thread Michael Bauer

10/03/2012 08:45 sgrìobh Rob Weir
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. 
shrugs that never seems to have been a problem previously. There 
usually are many more translators, some who contribute only one or two 
translations, than can be listed.
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.


That doesn't ensure anything. I could regularly contribue stuff that 
looks very much like, say, Navajo but no one has any way of knowing if 
it's good or bad if I'm the only one providing Navajo transalations.
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. 
That will result in very long delays cause you're in effect doing the 
same job twice and I can't see a language like Gaelic or Bambara being 
very high up anyone's list of priorities.


d) We have some sort of community review procedure. We rely on native 
speakers to test the translations.


And how do you identify native speakers? Especially for smaller 
languages, localization work is often done by fluent learners anyway, 
it's just the sociolinguistics of the small languages.


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.


Again, that dooms small languages. How many times do I need to repeat 
that with all the pushing in the world, small languages usually consist 
of a team of 1, maybe two. If I had to wait for 2+ votes on any Gaelic 
localization I've been involved in, I'd still be waiting for a release. 
Two years on, I have a team of two who will, if they have the time, 
install a pre-release and do some light testing and I already consider 
myself lucky having them.


May I ask why you're trying so hard to change a model that worked 
reasonably well before?


Michael


Re: [Translate] Users for Pootle Server

2012-03-10 Thread Dave Fisher

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

 On Sat, Mar 10, 2012 at 12:08 PM, Dave Fisher dave2w...@comcast.net wrote:
 Hi Rob,
 
 My comments are meant to supplement and enhance your thoughts on measuring 
 merit.
 
 On Mar 10, 2012, at 8:46 AM, Rob Weir wrote:
 
 On Fri, Mar 9, 2012 at 5:09 PM, Michael Bauer f...@akerbeltz.org 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 

Re: [Translate] Users for Pootle Server

2012-03-10 Thread Rob Weir
On Sat, Mar 10, 2012 at 1:42 PM, Michael Bauer f...@akerbeltz.org wrote:
 10/03/2012 08:45 sgrìobh Rob Weir

 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.

 shrugs that never seems to have been a problem previously. There usually
 are many more translators, some who contribute only one or two translations,
 than can be listed.


I think, as a policy, we should credit all translators, unless they
wish to omitted.

But from the IP perspective, I don't think we can be accepting
anonymous (e..g, non-logged in users) submitting translations for
inclusion into Apache releases.  This is not a matter of review.  It
is a question of origin of the translations.  For example, an
anonymous user could accidentally and innocently contribute
translations from LibreOffice, not knowing that the license is not
compatible.  But if we don't know who is actually doing the
contributions, we have no easy way of contacting them to explain the
issue.  On the other hand, a translator might legitimately contribute
their own translations to both projects.  But if they are anonymous,
we have no way of telling the difference between these two cases.

 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.

 That doesn't ensure anything. I could regularly contribue stuff that looks
 very much like, say, Navajo but no one has any way of knowing if it's good
 or bad if I'm the only one providing Navajo transalations.


That's why I suggested the committee review phase, described later.

 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.

 That will result in very long delays cause you're in effect doing the same
 job twice and I can't see a language like Gaelic or Bambara being very high
 up anyone's list of priorities.


Is it a duplicate to have developers do smoke tests and unit tests,
and QA run formal tests and also have users report bugs during a beta
release?  Does it slow us down?  Yes, of course this is redundant,
duplicate effort.  And it takes time.  But it all goes toward
improving the quality of what we deliver.  So I make no apologies for
review work.


 d) We have some sort of community review procedure. We rely on native
 speakers to test the translations.

 And how do you identify native speakers? Especially for smaller languages,
 localization work is often done by fluent learners anyway, it's just the
 sociolinguistics of the small languages.


From users, I hope.

Remember, even with widespread languages like Spanish we find errors.
 For example, the issue with reversed icon set names.  This isn't a
question of fluency.  It is merely a fact that in knowledge work of
any kind there is an error rate of 1-5%. This is true of coding,
translating, even testing.  We can't prevent it entirely.  All we can
do is account for it in the process.


 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.

 Again, that dooms small languages. How many times do I need to repeat that
 with all the pushing in the world, small languages usually consist of a team
 of 1, maybe two. If I had to wait for 2+ votes on any Gaelic localization
 I've been involved in, I'd still be waiting for a release. Two years on, I
 have a team of two who will, if they have the time, install a pre-release
 and do some light testing and I already consider myself lucky having them.


That's fine.  When Armin wrote the new SVG code, that was a team of
one doing the coding.  But we found others to help test the results.
We might have only one person on the project who translate Gaelic, but
I hope we can find 2-3 users who are willing to download a candidate
language pack and give us feedback on it.   I think it is part of the
responsibility for a translator of less-used languages to find their
own reviewers from the broader user community.

 May I ask why you're trying so hard to change a model that worked reasonably
 well before?


Actually, I'm trying to find a solution that will make 

Re: [Translate] Users for Pootle Server

2012-03-10 Thread Paolo Pozzan

Il 09/03/2012 22:22, Rob Weir ha scritto:

On Fri, Mar 9, 2012 at 6:30 AM, Michael Bauerf...@akerbeltz.org  wrote:

[cut]

2) Allow account creating as on other Pootle servers without any hoops to
jump through other than the usual signup process.

In essence, handle Pootle and l10n as it was handled before.



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.

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.


It's not useful to give causal contributors write access to 
translations: they usually don't know what writing style to follow and 
don't know the correct terminology. This will only mess up things or 
give more work to do to the translators. Please don't let submit rights 
to non-logged users.



What are we missing?

Would it work, for example, if the translation leads become Apache committers?


I think it can work. Better yet: back in OOo days various teams were 
able to choose between pootle or direct SDF submission (as Claudio 
said). Maybe in this phase of reorganization it would be helpful for the 
teams to choose their preferred method.


Paolo


RE: [Translate] Users for Pootle Server

2012-03-10 Thread Gavin McDonald


 -Original Message-
 From: Paolo Pozzan [mailto:pa...@z2z.it]
 Sent: Sunday, 11 March 2012 7:02 AM
 To: ooo-dev@incubator.apache.org
 Subject: Re: [Translate] Users for Pootle Server
 
 Il 09/03/2012 22:22, Rob Weir ha scritto:
  On Fri, Mar 9, 2012 at 6:30 AM, Michael Bauerf...@akerbeltz.org  wrote:
 [cut]
  2) Allow account creating as on other Pootle servers without any
  hoops to jump through other than the usual signup process.
 
  In essence, handle Pootle and l10n as it was handled before.
 
 
  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.
 
  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.
 
 It's not useful to give causal contributors write access to
 translations: they usually don't know what writing style to follow and don't
 know the correct terminology. This will only mess up things or give more
 work to do to the translators. Please don't let submit rights to non-logged
 users.

In your mind, what do you think 'submit rights' mean?

To me it means submit a translation for approval by a committer, without such
approval it does nothing and harms nothing. Why are you against such actions
whilst the rest of the people in this thread are trying to open up access even 
more?

Gav...

 
  What are we missing?
 
  Would it work, for example, if the translation leads become Apache
 committers?
 
 I think it can work. Better yet: back in OOo days various teams were able to
 choose between pootle or direct SDF submission (as Claudio said). Maybe in
 this phase of reorganization it would be helpful for the teams to choose their
 preferred method.
 
 Paolo



Re: [Translate] Users for Pootle Server

2012-03-09 Thread Michael Bauer

Be constructive. What would be the top 3 things that we should change?

-Rob


Gladly, though I may be repeating myself :)

1) Allow some for a small number of locale leads which initially are 
given freely like candy but allow for revisting that if lead turns out 
to be inactive or rogue. These leads administer the access levels of 
their fellow translators (if there are any). These need Project Admin 
(https://cwiki.apache.org/confluence/display/INFRA/translate+pootle+service+auth+levels) 
access but I'm sure they'd be quite happy to have that restricted to AOO 
Pootle only. As I said before, I doubt a lot of translators will do much 
in the way of committing code.
2) Allow account creating as on other Pootle servers without any hoops 
to jump through other than the usual signup process.


In essence, handle Pootle and l10n as it was handled before.

3) Once that basic sort of l10n infrastructure is in place, find some 
people skilled in code who are willing to keep a closeish look on l10n 
issues and decamp l10n from the main dev mailing list.


Cheers,

Michael


Re: [Translate] Users for Pootle Server

2012-03-09 Thread Paolo Pozzan
2012/3/9 Michael Bauer f...@akerbeltz.org:
 Be constructive. What would be the top 3 things that we should change?

 -Rob

 Gladly, though I may be repeating myself :)

 1) Allow some for a small number of locale leads which initially are given
 freely like candy but allow for revisting that if lead turns out to be
 inactive or rogue. These leads administer the access levels of their fellow
 translators (if there are any). These need Project Admin
 (https://cwiki.apache.org/confluence/display/INFRA/translate+pootle+service+auth+levels)
 access but I'm sure they'd be quite happy to have that restricted to AOO
 Pootle only. As I said before, I doubt a lot of translators will do much in
 the way of committing code.

+1

 2) Allow account creating as on other Pootle servers without any hoops to
 jump through other than the usual signup process.

 In essence, handle Pootle and l10n as it was handled before.

+1

 3) Once that basic sort of l10n infrastructure is in place, find some people
 skilled in code who are willing to keep a closeish look on l10n issues and
 decamp l10n from the main dev mailing list.

+1

Paolo


Re: [Translate] Users for Pootle Server

2012-03-09 Thread Rob Weir
On Fri, Mar 9, 2012 at 6:30 AM, Michael Bauer f...@akerbeltz.org wrote:
 Be constructive. What would be the top 3 things that we should change?

 -Rob

 Gladly, though I may be repeating myself :)

 1) Allow some for a small number of locale leads which initially are given
 freely like candy but allow for revisting that if lead turns out to be
 inactive or rogue. These leads administer the access levels of their fellow
 translators (if there are any). These need Project Admin
 (https://cwiki.apache.org/confluence/display/INFRA/translate+pootle+service+auth+levels)
 access but I'm sure they'd be quite happy to have that restricted to AOO
 Pootle only. As I said before, I doubt a lot of translators will do much in
 the way of committing code.

OK.  I think we have a volunteer project admin for the AOO Pootle
project.  That is Raphael, right?


 2) Allow account creating as on other Pootle servers without any hoops to
 jump through other than the usual signup process.

 In essence, handle Pootle and l10n as it was handled before.


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.

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?

 3) Once that basic sort of l10n infrastructure is in place, find some people
 skilled in code who are willing to keep a closeish look on l10n issues and
 decamp l10n from the main dev mailing list.


We discussed this a while back, that it may be necessary at some point
to have an ooo-10n mailing list.

Regards,

-Rob

 Cheers,

 Michael


Re: [Translate] Users for Pootle Server

2012-03-09 Thread Michael Bauer


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.



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.


I've done you some screenshots of what a locale admin account looks like 
in Pootle (http://www.akerbeltz.org/Process.doc)


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


Re: [Translate] Users for Pootle Server

2012-03-09 Thread Claudio Filho
Hi

I wish to talk about two points.

1) Really Pootle can be useful and we can win produtivity with it, BUT
is possible work with other tools too;

2) This instance of Pootle, without a minimum of one person per
language as committer, is unusable.

Explaining:

1) How we haven't a functional pootle instance, or by lack of admin or
by method/process, i am revising the translation in the old way,
with the convertion of SDF to PO, using the old pt-BR SDF file as
translation memory (TM) and continuing the revision/translation. Is
possible to share this files between the team and, at final, join all
files and reconvert to SDF.

I used translate-toolkit, to convert, and lokalize (the localization
tool of KDE) for revision, automatic translation (reusing TM) and new
translations . Today, the situation is total of 72696 strings (UI +
help), 59263 translated (81,5%), 10385 fuzzy (14,3%) and 3048
untranslated (4,2%). With a good team, one week of work.

2) I agree with many people that explained the question of a manager
per language, because in this situation is impossible for one person
with skills in all languages. Same that one person could know many
languages, the details about the region, coloquial language or
habits/common expressions isn't in his domain.

In any way, we have more one problem: how recognize the contributions
and efforts of this volunteers? This volunteer profile isn't technical
(maybe a language manager/leader), and he need to be the bridge
between the tecnical and localization parts of project.

And if need more someone to help in Pootle, i can help.

Best,
Claudio


Re: [Translate] Users for Pootle Server

2012-03-08 Thread Rob Weir
On Thu, Mar 8, 2012 at 6:53 PM, Michael Bauer f...@akerbeltz.org wrote:
 I don't think any community engagement will be too successful with the
 current setup. It may be that the setup has worked very well for Apache so
 far but looking at the list of projects
 (http://projects.apache.org/indexes/alpha.html) I can't really see anything
 that looks like a project that has a localization effort comparable to OO
 (admittely, I did not check them *all*).

 AOO seems to be quite different and has its own community history of
 localization if you will. Putting the two together the way they currently
 are feels very much like a square peg in a round hole.


Be constructive.   What would be the top 3 things that we should change?

-Rob

 Michael


 I am sorry if this has already been discussed but I lost a few messages...

 With the Pootle server on-line, I plan on calling on the pt_BR community
 to revise and improve the Brazilian translation for AOO.

 User registration on Apache's Pootle server, however is manual so my
 question is: how should we engage the community to assist in the translation
 process?

 -- Roberto Salomon


Re: [Translate] Users for Pootle Server

2012-03-08 Thread Jürgen Schmidt

On 3/8/12 9:23 PM, Roberto Salomon wrote:

I am sorry if this has already been discussed but I lost a few messages...

With the Pootle server on-line, I plan on calling on the pt_BR community to
revise and improve the Brazilian translation for AOO.

User registration on Apache's Pootle server, however is manual so my
question is: how should we engage the community to assist in the
translation process?

wait until we give the ok. I have prepared a new set of English strings 
(UI and help) and this files have to be uploaded first. I don't have 
command line access so far...


But it is important that we have a definite start point with an English 
version that is related to the current sources. Then we can compare 
everything else to this version.


I hope it is not too annoying for our translation volunteers but I think 
the start is very important. But once we have it up and running it 
should be easy in the future. We want to work with the localization 
community to make it as easy as possible for all of us.


Localization was and is an important piece for the success of OpenOffice 
in the past and tomorrow. Let us work together to build a strong 
community and make Apache OpenOffice availabel in as many languages as 
possible. And that we can reach as much as possible people all over the 
world.


The only problem at the moment is that we have to cover some lost of 
knowledge and tooling.


Juergen