incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: How many languages will Apache OpenOffice support?
Date Sat, 17 Dec 2011 15:06:55 GMT
On Sat, Dec 17, 2011 at 9:43 AM, Marcus (OOo) <marcus.mail@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

Mime
View raw message