trim-mo requires the reference C.mo to build $LINGUA.mo correctly
Hi. I found this modifictation today.
RCS file: /cvs/debian-boot/boot-floppies/utilities/dbootstrap/po/Makefile,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- boot-floppies/utilities/dbootstrap/po/Makefile 2000/01/18 17:56:47
1.13
+++ boot-floppies/utilities/dbootstrap/po/Makefile 2000/01/20 06:18:33
1.14
@@ -38,7 +38,7 @@
@msgfmt --statistics -o $@ $<
.mo.trm:
- trim-mo $< C.mo > $@
+ trim-mo $< > $@
$(PACKAGE).pot: $(POTFILES)
xgettext --default-domain=$(PACKAGE) --directory=.. \
@@ -65,6 +65,9 @@
clean:
rm -f *.mo *.trm *~ C.po
+
+maintainer-clean: clean
+ rm -f $(PACKAGE).pot
update-po: Makefile
$(MAKE) $(PACKAGE).pot
The reason for this change is shown as
"fix the .mo.trm suffix rule (C.mo mentioned twice at times)"
But if $LINGUA is set to other than C, and $LINGUA.po is not
fully updated, removing this "reference" C.mo leads to the problem
which is solved before.
In <20000104135223.A19516@artica.id-agora.net>,
at Date: Tue, 4 Jan 2000 13:52:24 +0000,
on Subject: Re: Bug#53981: language-chooser,
Enrique Zanardi <ezanardi@id-agora.com> writes:
ezanardi> On Tue, Jan 04, 2000 at 11:24:01AM +0100, Martin Schulze wrote:
ezanardi> > Adam Di Carlo wrote:
ezanardi> > >
ezanardi> > > Package: pointerize
ezanardi> > > Version: 0.3
ezanardi> > >
ezanardi> > > Martin Schulze <joey@finlandia.Infodrom.North.DE> writes:
ezanardi> > >
ezanardi> > > > . dbootstrap/pointerize must not crash if no translation for a string
ezanardi> > > > is present (0.3 returned NULL which drove things crazy.
ezanardi> > >
ezanardi> > > Hmmm... This report is a bug report against pointerize...
ezanardi> >
ezanardi> > There was a prelimnary and inefficient fix for this from
ezanardi> > Fumitoshi Ukai. Enrique promised to get the real fix done.
ezanardi> > However, since only 0.3 is out, the bug seems to be still
ezanardi> > present.
ezanardi>
ezanardi> The problem is two folded.
ezanardi>
ezanardi> If we are trying to load an obsolete trm file (one generated from a
ezanardi> different version of dbootstrap, with more or less _("strings") )
ezanardi> dbootstrap must display an error message and stop (I posted a patch on
ezanardi> debian-boot a few weeks ago to do just that).
ezanardi>
ezanardi> The translated string is searched by its position on the trm file (not by
ezanardi> its non-translated counterpart as it is in gettext) so, if there's a
ezanardi> different number of strings on the trm file than expected, there's no way
ezanardi> to tell which one goes where (and usually some of them won't be there,
ezanardi> NULL pointer, so the segfaults).
ezanardi>
ezanardi> Using the original string to search for the translated string means
ezanardi> including the original strings on the executable and on all the trm
ezanardi> files, as gettext does, defeating the whole purpose of using pointerize.
ezanardi>
ezanardi> Now for the second fold:
ezanardi>
ezanardi> Sometimes a trm file is generated from an up-to-date ("msgmerged")
ezanardi> but not fully translated LANG.po file. "msgfmt" (another gettext tool)
ezanardi> doesn't write on the LANG.mo file messages that haven't been translated
ezanardi> (or that are marked as "fuzzy") and so the LANG.trm file generated from
ezanardi> that LANG.mo file will be treated by dbootstrap as if it were obsolete.
ezanardi>
ezanardi> That's what I was going to fix (and haven't done yet) by making trim-mo
ezanardi> put the non-translated string (instead of the translated one) on the
ezanardi> LANG.trm file when the translated string is not on the LANG.mo file
ezanardi> (probably because that message hasn't been translated yet, or is marked as
ezanardi> "fuzzy"). That means rewriting trim-mo, as currently it just extracts
ezanardi> the translated strings from the LANG.mo file, and doesn't use any other
ezanardi> file. The new trim-mo will have to use both C.mo and LANG.mo or go one
ezanardi> step higher and parse LANG.po like msgfmt does.
ezanardi>
ezanardi> > In that case, the is a no-go for the language chooser since
ezanardi> > it will crash the installation process if we cannot ensure that
ezanardi> > all strings for all languages exist.
ezanardi>
ezanardi> I'll fix pointerize as I said above, but that doesn't prevent someone
ezanardi> trying to use an obsolete trm file. The language chooser should use a
ezanardi> check-trm-file routine to detect invalid/obsolete trm files before
ezanardi> displaying its menu, so that only valid files are offered to the user.
ezanardi>
ezanardi> --
ezanardi> Enrique Zanardi ezanardi@id-agora.com
This problem can be avoided by using "C.mo" as a reference,
so the "obsolete" LANG.mo has been supplemented by the messages
from this "reference" C.mo (most updated & very correct one).
Enrique wrote:
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.
And pointerize 0.4 can do this, by
.mo.trm:
trim-mo $< C.mo > $@
OTOH, "trim-mo C.mo C.mo" does not give harm on the output C.trm.
The second "C.mo" is just used for "reference", and if the first
one has the complete messages, then the messages from the second
one are all overwritten.
If you do mind just to use C.mo twice to produce C.trm,
then please add separate rule to build C.trm, and just leave
the rule to build other LANG.trm to use the reference C.mo as
the second argument.
I will commit to revert this change now.
--
Taketoshi Sano: <sano@debian.org>,<sano@debian.or.jp>,<kgh12351@nifty.ne.jp>
Reply to: