Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings
On Mon, Jan 19, 2009 at 10:02:31PM +0000, Neil Williams wrote:
> On Mon, 19 Jan 2009 12:20:40 -0800
> Russ Allbery <rra@debian.org> wrote:
> > If I check the generated templates in the binary deb, how do I check that
> > the string was marked for translation? We don't want to trigger this tag
> > on strings that aren't intended to be translated.
You can't. This only works properly at the source package level.
> TBH I was expecting that all questions would be translated - at least
> the help text (Description), even if not the possible answers.
> Otherwise, doesn't it tend to indicate that debconf is being used as a
> registry?
To be honest, I think you seem to have got the wrong end of the
debconf-is-not-a-registry stick somewhat.
The point of saying that debconf is not a registry is to discourage
maintainers from storing information long-term in the debconf database
that instead belongs in the filesystem. There is no prohibition on
people doing fancy stuff on a short-term basis, e.g. to communicate
between the config and postinst scripts, and nor should there be.
(I'm speaking with my debconf co-maintainer hat on here.)
> A quick check finds these files on my system that contain unexpected
> content like:
> Template: debconf-apt-progress/info
> Type: text
> Description: ${DESCRIPTION}
>
> Template: debconf-apt-progress/media-change
> Type: text
> Description: Media change
> ${MESSAGE}
>
> How are those variables utilised? Where and how could these be
> translated?
With the possible exception of the "Media change" string there, which I
think is probably a bug, debconf-apt-progress is passing through
already-translated strings supplied by apt.
Checking this at the binary package level loses all the paragraph-level
annotations applied to po-debconf input templates files (e.g.
"flag:translate!:2"), though. It's just the wrong place for the check.
> Template: console-setup/modelcode
> Type: string
> Description: for internal use
>
> Template: console-setup/layoutcode
> Type: string
> Description: for internal use
>
> Template: console-setup/variantcode
> Type: string
> Description: for internal use
>
> Template: console-setup/optionscode
> Type: string
> Description: for internal use
>
> Template: console-setup/fontsize
> Type: string
> Description: for internal use
>
> Template: console-setup/codesetcode
> Type: string
> Description: for internal use
>
> Those all look wrong to me - debconf for internal use only?
See above - this is perfectly legitimate. In the case of console-setup,
this is a way for the config script to communicate information to the
postinst, specifically the results of mapping translated choices back to
the identifiers that need to be written to the configuration file. It's
perhaps a little awkward and there are some other ways to achieve a
similar effect, but the most elegant way to do this can vary depending
on the circumstances; it's certainly not intrinsically wrong.
I haven't analysed all the cases you provided, but in general Lintian is
not smart enough to second-guess a maintainer's choice of labelling a
template as internal-use with any remote degree of correctness, and it
should therefore not attempt to do so.
> Template: tasksel/desktop
> Type: multiselect
> Choices: gnome, kde, xfce
> Default: gnome
> Description: The desktop environment to install when the desktop task
> is selected This can be preseeded to change the default.
>
> (That tasksel one looks like a true positive - I can't see why that is
> not translated.)
Because it's never asked; it's preseeding-only. The installer
intentionally doesn't offer this as a choice by default (and let us not
reopen that most endless of discussions here), but it's available for
preseeding for people customising the installer.
Again, Lintian is not smart enough to second-guess this and shouldn't
try.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: