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 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
