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 <firstname.lastname@example.org> writes:
Quoting Matthias Julius (email@example.com):
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
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
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.
"Imagination is more important than knowledge" A.Einstein