On Sunday 04 November 2007, Christian Perrier wrote: > 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. I would make it a list (possibly different per architecture) that is included when _images_ are built (in /etc/ somewhere), but which is used by localechooser. > > 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". In both cases it is _only_ usable for users who understand English, so that is why _I_ say it is not any better either! However, it _is_ completely misleading as we seem to offer an installation that is in their own language. > 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. Yes, and at that point it could be they have just formatted their hard disk, or even worse, they've just made a completely wrong choice and lost all their data because a key string was not translated. > > 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. A completely artificial and totally meaningless barrier... > > 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 ? Using this: > > And the splitting out into sublevels could be done by again first > > merging to a single master file and then using msggrep -C. > From what I get of tour proposal, we would tag the strings somewhere > (in the templates file?), then dispatch them into sublevel PO files. Yes, add a comment to indicate the level and then msggrep -C on that comment, first for the lowest level and then for the higher levels. Any strings that are left over are sublevel 1. > > 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. Sure, but with a _lot_ better split than we have currently.
Attachment:
signature.asc
Description: This is a digitally signed message part.