incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <>
Subject Re: How many languages will Apache OpenOffice support?
Date Sat, 17 Dec 2011 15:56:29 GMT
Am 12/17/2011 04:06 PM, schrieb Rob Weir:
> On Sat, Dec 17, 2011 at 9:43 AM, Marcus (OOo)<>  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?

I've told this already.

> Was it to encourage translators by giving an incentive to reach a
> certain % of completion?

I don't think so.

> Was it to protect the brand by ensuring that only
> translations with certain quality level were released?

I don't see a connection between l10n and trademarks here.

> Was it to reduce the load on release management both on infrastructure
> (mirrrors) and release engineers?

Yes, yes, and time.

It's a difference when releng has to do and monitor building a handful 
(while the lunch break) or thousands of builds (hours and days).

It's a difference when you have to archive some or thousands files per 

It's a difference when you have to convince mirror admins again and 
again not to quit because of hundreds of GB for every new release.

> And do we have the same constraints here at Apache?  And do we have

Disk space is also worthwhile for Apache software serving mirrors. The 
admins are not special. And now everybody could be a release engineer. 
IMHO it hasn't really changed.

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

We had tried this before. At some point in time we had always requests 
to build also full install sets because it's easier for the endusers to 
install only 1 file. I'm pretty sure it would  come back as the 
situation wouldn't be different.

But from the technial side, yes, maybe the only good shortterm solution 
for releasing every lanuage that has strings in Pootle. Of course only 
until we have a smarter packahres and installer that need less space on 
mirrors. Then we can create a generic install build that downloads 
resource files for every wished language.

> 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

I don't know if I like this public labeling as it could also be 
interpreted as "Doesn't make sense to use it, it's just poorly 
translated". A general hint that some languages are not yet completely 
localized would be more friendly.

> schema.   Then allow NL projects (external to Apache or as their own
> Apache projects) to distribute integrated builds on their own.

And name it also "Apache OpenOffice"? Hm, could be (again) a problem of 
the "Am I allowed to use the name?" thingy. ;-)

 > What makes the most sense now?

Good point. IMHO we should concentrate on that what we all can 
accomplish. And, sorry, it's on a different level than before.


View raw message