Martin Schulze writes ("Re: dpkg i18n and gettext"):
> Ian Jackson wrote:
> > I'm rather unimpressed with the current state of dpkg's build system,
> > including the i18n stuff. I'm also unimpressed by GNU gettext (I
> > agree with gettext's detractors in favour of catgets).
>
> *sigh*
? You don't like reorganisation ?
> > Over the next weeks and months I expect to be un-reorganising dpkg's
> > build system to look more like the way it used to. As part of this
> > I'm considering dropping gettext in favour of catgets.
>
> Before you continue could you draw a small picture how this works.
>
> a) Are there still regular strings in the source code?
> b) How are translated strings handled in the source archive?
> c) How are translated strings handled in the installed binary?
Um, I was expecting people on this list to have views about gettext
vs. catgets, not to ask me about it ! Changing the i18n mechanism is
about the last of the things I want to change (after stripping out
automake and probably libtool too). I was hoping for feedback, not
questions :-).
However, as I understand it (and I haven't investigated it deeply
yet):
(a) Yes.
(b) There would be a macro which would invoke catgets. The macro
would take two arguments, instead of gettext's macro's one: a message
number, and a default string.
(c) The macro expands to a call to catgets. catgets et al do some
kind of usual thing with message catalogues.
Ian.
