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 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. >> >> Apache set up the Pootle server for more than one project and the needs for >> AOO are much different. >> >> 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. >> > > 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 # then to fall back to Django's authentication system. > >> Another possible way to prove merit would be to provide translation for some >> of the main components of the website. >> >> - topnav buttons. >> - main page. >> - branding. >> - download page. >> >> 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. >> > > 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 ... > > 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. > >> 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.) >> >> Regards, >> Dave >> >> >>> >>>> 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 >>
