Quoting Clytie Siddall (clytie@riverland.net.au):
>> So, really, what I would like to end up is:
>>
>> - Debian Installer: the real "core" D-I
>> - tasksel
>> - iso-codes
>> - dpkg
>> etc.
....which I did yesterday.
>>
>> ...and dropping debconf-only translations (exim4, console-data, etc.)
>> at least for the moment....until a more general solution is
>> found/built to allow translators to work on them directly from Pootle
>> and have the result committed somewhere for maintainers to use it.
>
> When I first came to Debian, I found it very helpful that there was a
> set of files labelled "Debian Installer" to which I could give priority,
> and which somehow stood out against the huge, complex mass of the Debian
> project.
It's much understandable. On the other hand, things have changed quite
a lot since we established the Debian Installer "levels". At that
time, strings from the listed packages were indeed used in one step or
another in Debian installs (some were only used in specific types of
installs).
Sicne then, the installer changed and some packages we still list
(particularly in "level 5") have no more strings used during Debian
installs (dpkg, for instance...or aptitude).
For some other packages (xorg for instance), the priority of questions
has been lowered and the questions you translate only appear on expert
installs and no more in default ones....which gives a quite smaller
importance to translation (not saying this is useless,, though)
More and more, the strings that are really used during Debian installs
are "concentrated" levels 1 and 2. Therefore, translatings packages
from those levels guarantees a very complete localization of the
installation process.
We could even shrink the concept of levels to the first two
levels. Still, as you mentioned, having the other ones helps
translators to concentrate on the most "important" stuff.....though
one could argue that mysql or squid debconf templates are as
"important" as samba or xorg ones....
If we look closer:
- level 5: most of it is made by the dpkg/apt/aptitude trio which are
indeed the most "important" Debian native packages. So, these could
be replaced by targeted localization of Debian native packages.
- debconf: no string used in D-I installs
- debconf program: ditto
- shadow: kept only for historical reasons
- newt: IIRC, it still provides the Yes/No translations for the
test installer widgets. Could be moved to level 2
- aptitude/dpkg/apt: not used in installs. A few strings may
appear in progress bars (to be investigated)
- console-common: not used anymore in default installs
- dictionaries-common: may trigger questions in localized
installs when the l10n task installs a dictionary
- level 4: only samba (because *one* question is asked during the
installation of the "File Server" task
- level 3:
- xorg: no longer asks any question during default installs.
- menu: not really involved in installs.
- win32-loader: now advertized as a D-I functionality. Could go
in level 2. However, it depends on another item, not under
Debian control, to be translated
- exim4: if I'm correct, it no longer asks any question during
default installs, but only in the Mail Server task
- level 2:
- tasksel: should be kept as part of the installer
- iso-codes: country names. Should be kept
- console-data: should be kept...unless we finally switch
to console-setup and find a way to have i18n'ed keymap names
for it. In such case, the translation would need to focus
on xkb-data (good luck: the file to translate has 606 strings!)
- popularity-contest: has a question in default installs
- eject: has one string used in the D-I menu
- grub2: not sure we'll need to keep this one
I would indeed propose to simplify this and only keep two levels:
-level 1: core D-I
-level 2: extra packages which is worth translating to have a good
l10n'ed installation:
tasksel, iso-codes (iso-3166), console-data, popcon, eject, newt
dictionaries-common
There is not a big point in hierarchizing the level 2 translations as
the "less important" ones are also those which few strings...
We of course still have that special case of win32-loader, which I'd
like to see in level 2 but depends on that external stuff which we
have no control about.
Attachment:
signature.asc
Description: Digital signature