Re: Bug#752045: [RFR] templates://dictionaries-common/{dictionaries-common.templates}
Agustin Martin wrote:
> Justin B Rye wrote:
>>> The configuration question for "${question}" is empty but some
>>> elements are installed for the "${class}" class:
>>
>> What does it mean for a question to be empty? And what on earth is
>> all this about elements and classes? Is this perhaps saying:
>>
>> There is no answer on file for the configuration question
>> "${question}", but some elements are installed for the "${class}"
>> package class:
>
> This can mean that question value is "" or that question is lost, usually
> because of debconf database corruption.
My point was that the problem isn't a missing *question* - it's a
missing *answer*. And it isn't clear yet what the question is likely
to be about. Are the "elements" the codenames of the dictionaries
provided by the packages? Are the "classes" the two families of wfoo
and ifoo packages? The answers may seem obvious to you, but they
won't to ordinary users.
[...]
>> This needs a complete rewrite, using human-readable (and translatable)
>> labels; my guess is
>>
(Which reminds me: I made them translatable in my patch but left the
#flag line.)
>> .
>> Installed elements: "${installed_elements}"
>> Debconf setting: "${choices_value}"
>> Involved packages: "${shared_owners}"
>
> They are intended for possible bug reports, but I am also not happy with
> their current status. Some (long) explanation follows.
>
> dictionaries-common uses a rather complex system to deal with the main
> shared question. To make translation easier, it uses a normal question under
> dictionaries-common control. All ispell dictionaries and wordlists provide a
> shared shared/packages-{ispell,wordlist} template, and am additional
> ${package}/languages template whose default value provides the language(s)
> keys provided by the package (things like "castellano8 (Spanish 8 bit)").
So are we expecting "Choices_dictcom" to always be a list of language
codenames like "castellano8 (Spanish 8 bit)"?
(Wait... what package provides that, anyway? wspanish is just
"castellano (Spanish)", and I don't see a wspanish-legacy...)
> This way, template translation for the selection menu is handled in a
> single location at the cost of much higher complexity.
>
> debconf database corruption can be caused by the main template being lost,
> with or without the shared question being also lost.
>
> "Choices_debconf" or "Debconf setting" stands for the possible choices
> debconf shows. If this problem happen it will most likely be only "Manual
> symlink setting".
>
> "Choices_dictcom" or "Installed elements" stands for the possible values that
> should have been made available to debconf (except "Manual symlink setting").
>
> "Owners/error" should show the list of owners for the
> shared/packages-ispell or shared/packages-wordlist question, or the error
> message returned by debconf in case of error.
>
> May be something like
>
> Available values: "${installed_elements}"
> Involved packages/Error: "${shared_owners}"
>
> is enough.
Try to look at it from the point of view of somebody who doesn't
already know what the "available values" are values *of* and who or
what they are available *to*. If users are likely to end up looking
at something like this:
The configuration question for "default-wordlist" is empty but some
elements are installed for the "wordlist" class:
Available values: "american-huge (American English -- huge) british-huge (British English -- huge)"
Involved packages/Error: "wamerican-huge wbritish-huge"
... then this shouldn't need to be any more complicated than:
The setting for "default-wordlist" is missing, but packages
providing a wordlist are installed: wamerican-huge wbritish-huge
>>> dictionaries-common. "${value}" does not correspond to any installed package
>
>> I wish somebody would translate "$value" for me. What *kind* of value
>> is this variable going to expand to? Is it something like "wfrench"
>
> Is something like "castellano8 (Spanish 8 bit)". It is both the language
> unique identifer and the language name, preferrably 7 bit and should not
> change. We initially used a poor's man internationalization like that
> (this system is more than 10 years old). Since debconf later allowed
> C-Choices, an additional new translatable ${package}/elanguages was added.
If all that's needed is an ASCII key to identify a language, it's far
from clear to me why the dictionaries don't have names like "fr" (with
package names like "words-fr")...
[...]
>> I think we should use the value of "${value}" instead of the rotten
>> variable-name that users don't know about. Alternatively you could
>> say "the invalid default dictionary setting", but then the user still
>> needs to puzzle out what it means for a package to provide that; it's
>> much easier to guess what package provides wfrench!
>>
>> Also, there's no need in this case to explicitly mention debconf.
>>
>> To fix this error, reinstall (or install) the package that provides
>> "${value}". Then, if you don't want that package on this system,
>> remove it, which will also delete this configuration setting. A menu
>> of choices will be shown after this message in order to leave the
>> system in a working state until you fix the problem.
>
> I did not put "${value}" here because is not a single word and could be a
> bit repetitive, but I do not have problems adding it, just remember that is
> not the package name.
When I asked "Is it something like 'wfrench'", it was because you
hadn't actually said what it was.
It's not a disaster if the user is presented with:
To fix this error, reinstall (or install) the package that provides
"francais (French)".
It would be better if it just told them the name of that package, but
if that's impossible, maybe:
To fix this error, reinstall (or install) the package that provides
the dictionary "${value}".
>>> Template: dictionaries-common/default-ispell
>>> Type: select
>>> Choices-C: ${choices}, Manual symlink setting
>>> __Choices: ${echoices}, Manual symlink setting
>>
>> I gather this isn't a typo, and that e-choices are connected to
>> e-languages, whatever those are...
>
> Not a typo, "${echoices}" is the possibly translated string, after
> elanguages..
I'd worked out that connection and stalled looking for documentation
for what elanguages are or what the "e" means. Though come to think
of it I didn't look very hard - I quickly got distracted onto trying
to come up with plausible uses for the word "echo-ices"...
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: