---------------------------------------------------------------------- This file describes how we want internationalization to work for the installation system. (debian-installer and base-config) ---------------------------------------------------------------------- Since most questions will be asked via some cdebconf implementation, most of the messages we need to localize will be the templates files. Each udeb will contain the messages which will be used by it. Moreover, we only need to fit on floppy the messages that will be used by udebs which initially reside (unpacked) on the floppy. This is as little as 5.7 KB (uncompressed!) per language (says Tollef Fog Heen, 11.09.2002). Additional udebs which will be retrieved by the installer from the cdrom or network will contain their messages, but this is not a big problem, since the ramdisk will be larger then the floppy image. That way there will not be a large messages file for each language, which are difficult to fit on a floppy (like there was in boot-floppies). Because of that there won't be a need to retrieve a separate "language udeb", and all languages will fit on the standard flopy. A rough roadmap: -> for udebs, we cannot afford having the iconv tables, which take approx 5MB of space, on a floppy. Therefore: * translators make the templates.ll files in whatever encoding they prefer (they could also use po-debconf) * udeb build procedure recodes (using iconv or po-debconf) the translated templates or po files to UTF-8 when creating the "combined" templates file, and the template fields will be in the form of "Description-ll_LL.UTF-8:" to denote that it is in UTF-8. * cdebconf (and thus whole debian-installer) runs in bterm [1] * then at run time, cdebconf simply copies the strings read from templates (now in UTF-8) to output at run time. That way cdebconf doesn't need the huge conversion tables. -> for debs (base system): The old way: * translators make the templates.ll files in whatever encoding their language default is set to. * package build procedure merges them into one (multiple encodings in single file). * when debconf sees a template without the mentioned header, it simply outputs the message hoping that the user's locale charset matches the encoding the translator used (current behavior). (We don't use libtext-iconv-perl because it is not implemented - there is a authorative mapping of lang->encoding for them). New way: * translators provide messages in po files (using po-debconf) in whatever encoding they prefer * package build procedure recodes the messages when producing the "combined" template file. The resulting templates file should have fields such as "Description-ll_LL.UTF-8:" * At debconf run time: - if the locale is "C" or uses UTF8 charset, debconf simply copies the strings to output, without using libtext-iconv-perl - if the locale is something else, debconf recodes the messages using libtext-iconv-perl before printing them. [2] ISSUES/TODOs: Problem : bterm does not currently run on all architectures (m68k, some sparcs?). : What about dumb terminals/headless systems? Answer1 : Philip Blundell says that bogl just needs to have support for the appropriate display types added Answer2 : it is always possible to run debian-installer outside of bterm, using an ASCII-only locale ("C"). slang/newt needs a special TERM variable set to use the + and - and | characters for the borders. Problem : If we allow installs without bterm, we should find a way to nicely let installer know whether main-menu should be ran within bterm or not? Answer1 : Maybe make a virtual package? Answer2 : Maybe run main-menu via some wrapper? * Some developers keep all translations in a single templates file, see 'adduser' for instance. See the old and new way, above. * setlocale(LC_ALL,"") needs to be called in d-i programs. * a locale definition that fits on floppy is required. from boot-floppies, there is C-at-utf-8.in, which results in 268kb locale file. localedef -i C-at-utf-8.in -f UTF-8 output-path/ * main-menu should ask debconf for debian-installer/locale instead of d-i/language. This will be more useful (could provide default values for keyboard, language, mirror, timezone). ] I would like to rename the debconf answer from ] debian-installer/language to debian-installer/locale, and store a real ] locale name (ll_CC) there. This way, we can actually use LANG=$locale ] after generating the required locale data file. We can also pass the ] content in /target/root/dbootstrap_settings as LANG_INST=$locale to ] tell base-config which language to use. There are basically two ways: we'd want every program to first db_get the locale and set the environment (or setlocale directly). have the variable set in cdebconf/main-menu, since those are the ones starting other processes. * add support for the LANGUAGE style variable listing several languages in priority order to be able to use other translations if the primary translation is missing * The Packages file parsing didn't support Description-ll_CC, only Description-ll (something I'm working on fixing) and I'm not sure about cdebconf as I get lost in the source code when I try to have a look. Packages file translation is done at ddtp, try mailing didesc@ddtp.debian.org with subject such as "GET 1 ll_LL" * debconf TITLE commands aren't translated at all. The new SETTITLE command deals with this, transition is in progress. * Should we even use debconf i18n (which is pretty limited) or po files as per gettext? -> probably advantageous in that we can get the charset conversion for free, but we can implement it anyway. -> using gettext is rather large and costly in terms of disk space, can we afford it? what about pointerize, that we used in boot-floppies? * How much i18n can we (and how much do we want to) fit on the floppy? That is why udebootstrap may be required. Note that debian-installer goes very far back from boot-floppies in respect to i18n. boot-floppies worked around the size constraints by loading locale information from file on CD-Rom, if it was available. (xlp.tgz).