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

Re: Criteria to activate languages in D-I?

Quoting Frans Pop (elendil@planet.nl):

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

Just what I always did: nag the translator/translation team.

Most of the time, if they're responsive/still "alive", that will work
painlessly. What I fear is being forced to drop the entire language
because the one and only translator is not responsive at the moment we
needed him|her. Of course, there are cases where we will make
exceptions (Vietnamese manual....but in that case, we *knew* quite
early about the translator's unavailability).

I like your suggestion of "early warning" for incomplete
languages. For now, I can think of it as an hardcoded list in
localechooser, for simplicity. We would then releae localechooser at
the last minute, with a hardcoded list of languages that are
incomplete and then display a warning immediately after users pick up
a language.

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

Well, my reasoning was simple: if we drop a language, then the only
solution for users is installing in English, right?

So, the deal is between an installer where most of the installation
happens in the user's language with a few strings in English and using
English only. This is what I call "not worse".

Again, having a key string not translated at a key moment may be a
very bad surprise if the user is completely clueless in
English....which again brings the idea of an initial warning.

> > 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".

That never happened up to now. And not because we enforced 100%. For
the sarge installer, such 100% limit was never enforced and we still
reached a very good level of translations with translators doing their
best to reach 100%.

> 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 

My proposal is as strict as the previous policy. The difference is
where to put te barrier, only. 

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

Yeah, I think this brings a good improvement. Allowing us to still use
the translator's work (I hate seeing the amount of investment put by
someone just being dropped out because circumstances may not allow
him|her to follow a fairly strict policy), while preserving the
quality reputation of our product.

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

Sure, but how can we automate the process of building the "sublevel"
PO files ?

From what I get of tour proposal, we would tag the strings somewhere
(in the templates file?), then dispatch them into sublevel PO files.
This is that part of the process which I don't really see easy to achieve.

Unless of course you're imagining a fully manual process but, ahem, we
have 1686 strings, IIRC..:-)

> 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).

Well, that converges towards our current 2 sublevels.

> 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: Digital signature

Reply to: