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 everyone happy. You can see what we're starting from: Only committers can log in, and everyone else can only make suggestions. I assume that is not your preferred way of doing things. Given that as the starting point, I think your best bet is to work with me, and others trying to figure this out. But it won't be identical to how it was before. I can only hope it is not identical to how it is right now. -Rob > Michael
