Quoting Frans Pop (elendil@planet.nl): (good convergence of ideas, even if there are points where we probably still disagree) > > 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, great. Let's say that we use /etc/partial-l10n. May someone suggest a better name? /etc/localechooser/partial (that would need /etc/localechooser to exist which could be overkill even if we have other stuff that could be moved there). If wonder if we could manage to generate that file's content automatically...but that also could be overkill and we could decide to manage it manually. > > 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. IMHO, you're exxagerating here about the real consequences. Particularly if we add the feature of warning users at localechooser's stage. But I suggest we drop this debate here as we're not likely to agree on the criticity of 100% translations and we'd better focus on a good method to support "nearly complete" translations with the other ideas you bringed in your comments. > 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. Well, despite your later comment about this not being feasible as is, I think we more or less have a method, yes. Yesterday, I tried to explore the possibility of having different templates files and different debian/po directories in packages...but that does not seem to be easily feasible with the current po-debconf. So, for the long term, there could be interesting ideas to share with po-debconf maintainer, such as more than one debian/po directory with a notion of "priority" for debconf templates. Again, here, as for many features of po-debconf, d-i could be an interesting testbed for such new features. In the meantime, we could need to use a more hacky method such as your comments suggestion. > > Well, that converges towards our current 2 sublevels. > > Sure, but with a _lot_ better split than we have currently. Definitely. This is something I dislike in our current 2 sublevels: we keep non critical messages in sublevel1 just because they belong to packages that happen to be on the "critical" path. --
Attachment:
signature.asc
Description: Digital signature