[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Criteria to activate languages in D-I?

On Monday 29 October 2007, Christian Perrier wrote:
> I know we may have many corner cases here and I agree partly on your
> rationale, though I think that we anyway know that modifying the most
> "common" strings is something we don't do without thinking deeply.

At least not shortly before RC releases. But we _do_ change them (or add new 
ones), eh, right now.
So the problem here is: what do you do when you're preparing an RC release 
and a translation has slowly drifted downwards (but not below your limits) 
and is missing translations for several key strings.

> What I want to avoid here is a language being dropped because only
> very few of its strings are missing.
> In such case, then the installer anyway becomes completely unusable
> for this language users....as their only choice is to use English.

Yes, and my statement is: if most of the installer is translated but one or 
more key dialogs are (partly) in English, the installer is almost as 
unusable! Or do you think that they will magically be able to understand 
those English bits just because there is little of it?

> Given that the fallback language is *always* English, the situation
> for the language with very few strings missing is not worse when we
> keep the 98%-translated file.

I don't understand what you're trying to say here.

> I really don't want to penalize users of a given language because, at
> the moment it was time to make the final adjustments to this language,
> the one and only translator was unavailable.

You know very well that I'm not talking about "final adjustments" here. 
Avoiding (and even reverting!) those if they have a major impact on 
translations and there is a real risk of even one translator not being able 
to update in time, is the responsibility of RMs and you as l10n 

What I'm worried about is that, because we will probably only have quite few 
real string changes, basically any language will remain above your limit 
even without _any_ updates and thus will be missing key strings.

> > Exceptions for sublevel1 can be made, but would explicitly have to be
> > judged on a case-by-case basis, taking into account exactly _which_
> > strings are fuzzy/missing.
> This introduces arbitrary judgement which I'd like to avoid as much as
> possible.

I strongly disagree with the "arbitrary" qualification.
IMO having a _person_ (or persons) judge the severity of missing 
translations on a case by case basis is a lot less arbitrary than setting 
some random percentage.
It also avoids the situation where a translator could say "ah, I'm not going 
to bother about those last strings; we're already above the limit, so the 
translation will be included anyway".

I still think that we've had *extremely* good results so far with the fairly 
strict policy, both for the installer itself and for the manual.
The trick is in having a strict policy, but still being able to be 
reasonable and fair by making exceptions when there are good reasons (as I 
did for the Vietnamese translation of the manual for Etch, which is 100% 
translated even when not 100% up-to-date; getting it that way probably cost 
me about 4 hours of work, which I was happy to do).

For me this is also about quality of our product: having a partially 
translated installer where users (from their PoV) are randomly confronted 
with English texts is _extremely_ unprofessional and would *never* be 
tollerated in any commercial product (yeah, I know, translations in 
commercial products can be horrible, but they are in general complete).

Let me throw out a wild suggestion: how about including a dialog early in 
the installation warning if a translation is incomplete which also informs 
what the fall back is. At least that would inform the user at an early 
stage and allow him/her to abandon it _before_ (s)he's for example 
formatted the hard disk...

> > An additional method you could consider implementing to further reduce
> > the size of sublevel1 is to "tag" strings as less important (e.g.
> > because they are architecture specific) and split individual strings
> > out based on that.
> Woot, that would require a lot of gettext hacking later in order to
> re-assemble things together.

Huh? Wouldn't you only need to merge all levels together into a (temporary) 
single master file before merging back to the individual packages? Seems 
simple enough to me...
And the splitting out into sublevels could be done by again first merging to 
a single master file and then using msggrep -C.

We could use something like the following levels:
- sublevel 1: default
- sublevel 2: general strings not used during default installs
- sublevel 3: expert strings (some low prio, some for e.g. RAID)
- sublevel 4: specific to less-popular arches (powerpc, mips, sparc?) or
  used in experimental features
- sublevel 5: same for high-end (hppa, ia64, s390) and hobby (m68k) arches

I'd personally like to aim for 100% for levels 1-3; the distinction between 
them mainly being useful to prioritize translation work. I'd be happy to 
leave translating levels 4 and 5 a decision of the translators (as long as 
we do display something like that warning for those arches).

I guess for some udebs (arch-specific ones) it would be nice to have the 
comment assigned automatically during the merge into the temp master file 
instead of having to add them in all template files individually.

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: