On Sat, Dec 17, 2011 at 9:43 AM, Marcus (OOo) <marcus.m...@wtnet.de> wrote: > Am 12/17/2011 01:13 PM, schrieb Michael Bauer: > >>> When the localization ratio is not high enough (we have to define this >>> limit), then we should only build a langpack for this language. >>> Otherwise you have, e.g., 30% localized UI and an English-only help. >>> This doesn't help any user. >> >> Yes, I agree that a cutoff is sensible though at present it's, from the >> localization point of view, hard to handle this sensibly because, even >> though a 50% translation may cover the strings most users use most often >> (i.e. Writer), it's very hard to tell which strings you should localize >> in. > > > This depends which strings were localized first. IMHO you cannot know what > it is, except you ask everybody what they have done. Maybe you can see this > with Pootle, I don't know. So yes, 50% could be OK when you know which parts > of AOO are effected. >
Backing up for a second. Why exactly did OOo make rules like this? Was it to encourage translators by giving an incentive to reach a certain % of completion? Was it to protect the OpenOffice.org brand by ensuring that only translations with certain quality level were released? Was it to reduce the load on release management both on infrastructure (mirrrors) and release engineers? And do we have the same constraints here at Apache? And do we have other opportunities here that we did not have before? For example, I'm pretty sure that we don't have a full time release engineer to build and manage hundreds of different release artifacts. (Of course, if someone volunteers to do that, then that would be wonderful). What if we took a more decentralize approach? For example, produce only language packs. Release all languages packs, but label them based on degree of completeness. For example: gold, silver, bronze, or level 1, level 2, level 3, etc. In other words, we don't hold back partial work, but set expectations based on some consistent labeling schema. Then allow NL projects (external to Apache or as their own Apache projects) to distribute integrated builds on their own. Again, I'm not saying what OOo was wrong. I'm just saying it was a solution based on the opportunities and constraints that existed at that time, and was enabled by subsidized release engineering from Sun/Oracle. We're in a different situation now. What makes the most sense now? -Rob
