intltool 0.10 release

[Darin Adler <darin bentspoon com>]

on 9/24/01 11:45 PM, Darin Adler at darin bentspoon com wrote:

>   1) xml-i18n-tools.spec.in is renamed intltool-spec.in and updated as
> necessary with the rest of these changes.

Done.

>   2) xml-i18n-tools.m4 is renamed intltool.m4 and contains two sets of
> macros -- one set with the old names for compatibility (and without the
> UTF-8 support you'd need for gnome 2) and one set with the new names,
> shedding compatibility (assuming UTF-8 for everything, I guess). We could
> remove some of the options added recently since we'll have this dichotomy.

I decided to retain both intltool.m4 (with the new macros) and
xml-i18n-tools.m4 (with the compatibility macros to support
AM_PROG_XML_I18N_TOOLS users).

>   3) xml-i18n-toolize.in is broken into two scripts. The compatibility one
> is named xml-i18n-toolize.in, and the new one is named intltoolize.in.

Done.

>   4) All other source files named xml-i18n-* are renamed intltool-*. And
> the generated files are renamed similarly (without the .in bit).

Done.

>   5) xml-i18n-toolize installs intltool-*.in as xml-i18n-*.in for
> compatibility, but intltoolize installs them under their new name.

Done.

>   6) Makefile.am is set up to install only intltool-* files. No need for
> compatibility for the installed tools.

Done.

>   7) Update README to explain how to convert a gnome 1 package to use the
> gnome 2 version, and explain the compatibility strategy, without being so
> long-winded that it's hard to understand.

Not yet done.

>   8) (optional) Change Makefile to install an empty xml-i18n-tools.m4 or
> remove the old xml-i18n-tools.m4 to reduce the chance of failures for people
> who aren't using a package manager.

I chose to retain the xml-i18n-tools.m4 file and keep the compatibility
macros in there.

> The only thing I don't know about is how to change the name of the cvs
> repository from xml-i18n-tools to intltool.

Done. The repository is now called intltool, but there is a symbolic link to
it at xml-i18n-tools to avoid short-term confusion. We can remove that link
any time we want.

> * Is there any good way to keep xml-i18n-toolize.in and intltoolize.in
> in sync in the future, if we make them separate?

I didn't do anything about this. I don't think it's a real problem.

> * Is retaining the xml-i18n-*.in files an important form of
> compatibility? The new xml-i18n-toolize will presumably alter
> po/Makefile.in.in to use them under their new names, and the new M4
> macro should cause the tools to get called under their new names.

We could change xml-i18n-toolize to do it a different way, but I like the
way the current way is even .cvsignore compatible.

> * We should add an AM_PROG_INTLTOOL macro, but retain
> AM_PROG_XML_I18N_TOOLS for compatibility.

Done, but I called it AC_PROG_INTLTOOL, not AM_PROG_INTLTOOL.

> * AM_PROG_XML_I18N_TOOLS can default to legacy mode (without the 5
> second pause) while AM_PROG_INTLTOOL can default to UTF-8 mode, or
> make specifying the mode explicitly mandatory.

The new macros only support UTF-8 mode. People who need the non-UTF-8
support can use the compatibility macros indefinitely.

> * We should add INTLTOOL-named versions of the various merge rule
> substitution strings but retain the old ones for compatibility
> (perhaps only when using AM_PROG_XML_I18N_TOOLS

Done.

I also updated the autogen.sh files in gnome-common to support INTLTOOL as
well as XML_I18N_TOOLS macros.

I think I'm about ready to do an intltool 0.10 release. Any thoughts on
that?

    -- Darin