[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg i18n and gettext



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.


Reply to: