|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: Criteria to activate languages in D-I?
Date: Sat Nov 03 2007 - 18:48:06 EDT
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 coordinator.
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?) orused 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.
-- To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.orgReceived on Sat Nov 3 18:48:31 2007
- application/pgp-signature attachment: This is a digitally signed message part.
This archive was generated by hypermail 2.1.8 : Wed Mar 19 2008 - 03:16:48 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |