Notes taken during the discussion about D-I modularization (jfs)
There was an extensive discussion on how to improve the way d-i handles translations so that it will be possible, in the future, to provide as many translations as we are provided with. The current d-i mechanism is:
- the data for all the languages for which translations are available is distributed for all the "core" udebs in d-i in the main initrd. This includes the translation of localechooser which includes all available countries / languages translated to all languages. Translations are included for all messages (expert and normal modes)
- when the user selects new components (after having selected, and configured, their data sources), the udebs include the translations for all languages regardless of their language selection.
With the current d-i mechanism there are some limitations since new translations impact:
- in the size of the initrd RAM disk
- in the memory available for installation tasks (since each new component is downloaded in the RAM disk, with translations taking some space here too)
- the bandwidth required (in network-based installations) since the translations take up space in the components themselves.
Some alternatives were discussed:
- separate translations from components into different udebs so the d-i would install the component and would only download the translation for the language the user selected. This seems feasible to do although it would mean modifying the udeb generation (so different udebs are generated for the translations) as well as ANNA (so it is 'intelligent' enough to know it has to download an additional component base on the user's selected language).
- Pros: translations can be installed / downloaded independently, users do not have to download translations they will not use (RAM and bandwith use decrease)
- Cons: may more udebs (# of components x # of languages), requires changes to build process and component download mechanisms, requires changes to how cdebconf manages messages (udebs with translations will be installed before/after the actual package with the debconf messages), is not possible to get the translation before some media or the network is accessible (as a consequence, the initrd will not decrease).
- generate different initrds per language "zone" (europe, asia, america...). So that the user has to select a language (or 'zone') at boot and the appropiate initrd is loaded.
- Pros: reduces initial RAM disk size,
- Cons: initrd generation needs to be modified, boot loader needs to be modified so that language selection is an option, users just pressing 'enter' might not get what they expect (they don't get their language unless it's in the 'default' zone)
- provide only translations to the messages that the average users see in the udeb core components. Do not include translations for "expert" messages
- Pros: reduces intial RAM disk size,
- Cons: translations for expert messages are lost, users might not find it easy to debug tasks (if there is a failure d-i fallbacks to expert mode)
- reduce localechooser translations so that translations are only countries the user might select (i.e. do not provide Japanese, Chinese, Korean translations for European countries and viceversa).
- Pros: reduces inital RAM disk size (localechooser udeb is large)
- Cons: users might find that the country they are in (if foreigner living abroad) is not translated (the "Other" option in localechooser will always be shown in English), translations (iso-codes) go unused
- provide a single component with all the translations. Extract all messages for a given language and generate a two udebs, one for the core system (installed in the initrds) and other for the rest of components. When the user selects a language the udeb for his language is downloaded.
- Pros: translations can be installed / downloaded independently, users do not have to download translations they will not use (RAM and bandwith use decrease), only needs a few udebs (one per translation), udebs of unused translations in "core" can be removed
- Cons: large udebs (size?), requires changes to build process and component download mechanisms, requires changes to how cdebconf manages messages (udebs with translations will be installed before/after the actual package with the debconf messages), users download translations they will not use, is not possible to get the translation before some media or the network is accessible (as a consequence, the initrd will not decrease).
- use the 'lowmem' mechanisms to remove unused translations in the core after language selection.
- Pros: reduce RAM disk size (but not initrd size) once the user selects a language, can be extended also to component downloads
- Cons: the user cannot go back and select a different language, requires coding similar to lowmem