Am 12/17/2011 04:06 PM, schrieb Rob Weir:
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?
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 OpenOffice.org 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
release.
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).
Absolutely.
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.
Marcus
