Re: Bug#53981: language-chooser
On Tue, Jan 04, 2000 at 11:24:01AM +0100, Martin Schulze wrote:
> Adam Di Carlo wrote:
> >
> > Package: pointerize
> > Version: 0.3
> >
> > Martin Schulze <joey@finlandia.Infodrom.North.DE> writes:
> >
> > > . dbootstrap/pointerize must not crash if no translation for a string
> > > is present (0.3 returned NULL which drove things crazy.
> >
> > Hmmm... This report is a bug report against pointerize...
>
> There was a prelimnary and inefficient fix for this from
> Fumitoshi Ukai. Enrique promised to get the real fix done.
> However, since only 0.3 is out, the bug seems to be still
> present.
The problem is two folded.
If we are trying to load an obsolete trm file (one generated from a
different version of dbootstrap, with more or less _("strings") )
dbootstrap must display an error message and stop (I posted a patch on
debian-boot a few weeks ago to do just that).
The translated string is searched by its position on the trm file (not by
its non-translated counterpart as it is in gettext) so, if there's a
different number of strings on the trm file than expected, there's no way
to tell which one goes where (and usually some of them won't be there,
NULL pointer, so the segfaults).
Using the original string to search for the translated string means
including the original strings on the executable and on all the trm
files, as gettext does, defeating the whole purpose of using pointerize.
Now for the second fold:
Sometimes a trm file is generated from an up-to-date ("msgmerged")
but not fully translated LANG.po file. "msgfmt" (another gettext tool)
doesn't write on the LANG.mo file messages that haven't been translated
(or that are marked as "fuzzy") and so the LANG.trm file generated from
that LANG.mo file will be treated by dbootstrap as if it were obsolete.
That's what I was going to fix (and haven't done yet) by making trim-mo
put the non-translated string (instead of the translated one) on the
LANG.trm file when the translated string is not on the LANG.mo file
(probably because that message hasn't been translated yet, or is marked as
"fuzzy"). That means rewriting trim-mo, as currently it just extracts
the translated strings from the LANG.mo file, and doesn't use any other
file. The new trim-mo will have to use both C.mo and LANG.mo or go one
step higher and parse LANG.po like msgfmt does.
> In that case, the is a no-go for the language chooser since
> it will crash the installation process if we cannot ensure that
> all strings for all languages exist.
I'll fix pointerize as I said above, but that doesn't prevent someone
trying to use an obsolete trm file. The language chooser should use a
check-trm-file routine to detect invalid/obsolete trm files before
displaying its menu, so that only valid files are offered to the user.
--
Enrique Zanardi ezanardi@id-agora.com
Reply to: