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

Re: other fallback languages Re: Deactivated languages

Jens Seidel wrote:
On Wed, Nov 22, 2006 at 12:29:49PM -0500, Matthias Julius wrote:
Christian Perrier <bubulle@debian.org> writes:
Quoting Matthias Julius (lists@julius-net.net):
This could be avoided if the user gets to decide: "Not all messages
have been translated into the language you have chosen. Please select
a fallback language."

Indeed, this was what I thought.

Theoretically, yes, but how would the installer "know" in advance that
debconf templates are not translated competely? D-I is modular by
nature so, at the moment localechooser is run, there is no possible
way to know whether udebs are fully translated, or not, for the chosen

Right, I first assumed that the udebs are created at the same time so
that the translation status of all packages can be put into localechooser.
Probably this approach works at least roughly, especially for official
releases and release candidates.

But I agree that putting these information into localechooser is not
good idea.

This information would need to be stored somewhere in a file created
by the build process.

No, not necessarily. I can imagine at least two solutions:
 * Let localechooser scan all udebs found in the initrd. The list of
   found udebs could probably provided by a debian-installer component
   itself (there must be already a component of d-i which scans all/most
   udebs to create the main menu). The contained "templates" file could
   be analysed on the fly ...
   This would miss all incomplete translations loaded from outside the initrd,
   such as via network.

And the gain is where? You still need the translations of the languages from which you choose. So no space gain there.

Also, your choice of available languages is based on the available languages in the translation of the following packages: anna, base-installer, (countrychooser,) cdebconf, debian-installer, di-utils-reboot, ethdetect, hw-detect, (languagechooser,) kbd-chooser, lowmem, mirror, netcfg, localechooser, preseed, retriever and save-logs (and probably some other arch specific packs).

i am not sure if this is such a good idea.

 * Let debconf handle the alternative language approach and ask for an
   alternative if one debconf string is not translated! Of course not

This must be first implemented :-)

   directly, but it would be possible to provide a hook script to
   debconf which is called once a translation is missing. This script
   needs to be provided by localechooser.

Sounds nice.

"Imagination is more important than knowledge" A.Einstein

Reply to: