Re: [Translation-i18n] The reason for make dist updating po files

[Kenneth Rohde Christiansen <kenneth gnu org>]

> Actually I already looked at it a long time ago. For example, the existence
> of xml-i18n-unicodify convinced me that there was some need for "msgconv"
> and the other new programs. And the "xml-i18n-extract" program gave me
> confirmation that xgettext support for Glade files may be useful. But
> also I shudder when I see 10 different po/Makefile.in.in patches, and
> wonder why you haven't asked for version numbers in po/Makefile.in.in.

Yeah, I should probably have done that. Can you add that?

> Now some comments based on intltools-0.26:
> 
> * intltool-unicodify can IMO use msgconv instead of iconv.

OK, I will let it use that.

> * doc/I18N-HOWTO
>   - Step 2:
>     Nowadays one uses the filename 'configure.ac' instead of
>     'configure.in'.
>   - Step 5:
>     Comment for "gettextize --force --copy" says that it
>     creates po/ and intl/. Actually, since version 0.11,
>     this commands creates no intl/ directory any more.
>   - Step 10:
>     AM_WITH_NLS has never been documented, and was removed
>     since gettext 0.11. Use AM_GNU_GETTEXT([external])
>     instead.
>   - Step 10:
>     Setting ALL_LINGUAS="da nl" in configure.{in,ac} is
>     deprecated since 0.11; instead a file po/LINGUAS is
>     recommended. This avoids lengthy runs of autoconf and automake
>     each time a catalog is added.
>   - Step 10:
>     You recommend AM_GLIB_GNU_GETTEXT - but you said intltools
>     had a broader spectrum than GNOME ? Btw, what does
>     AM_GLIB_GNU_GETTEXT provide that AM_GNU_GETTEXT doesn't?
>   - Step 15:
>     Instead of src/i18n-support.h I recommend to install the
>     gettext.h file (since gettext 0.11). Like this:
>       #include "gettext.h"
>       #define _(String) gettext (String)
>       or
>       #define _(String) dgettext ("helloworld", String)
>     This EXPLICIT_TRANSLATION_DOMAIN variable is bloat IMO.
>   - Step 17:
>     You forgot to #include <locale.h>.
>   - Step 18:
>     You can remove the -I$(top_srcdir)/intl since gettextize
>     didn't create an intl/ directory.
>   - Step 19:
>     You can remove the intl from SUBDIRS since gettextize
>     didn't create an intl/ directory.
>   - Step 21:
>     "cp helloworld.pot da.po" is better replaced with
>     "msginit --locale=da"
>   - Step 23:
>     There is no nl_DK locale on most systems. Probably this should
>     read da_DK.

I fixed all these.

> * intltool-extract:
>   This is xgettext's job. Are the types "ini", "keys", "xml", "scheme",
>   "schemas", "rfc822deb" used today? I'm asking because for Scheme, AFAIK,
>   guile doesn't have a gettext binding; as of version 1.4, its character
>   data type even supports only ASCII characters.

Well we are using these in GNOME and the freedesktop.org standards. the
Windows "ini" like format is used for .desktop files for instance. keys
are used for our mime system and are really just ini files with a
different extention AFAIR.

We are also using different kind of XML formats.

With intltool it is possible to define the format in POTFILES.in, like:

[type: gettext/xml] data/start-here.xml
src/main.c
src/test.c
[type: gettext/ini] data/mimefile.keys

etc.

We use scheme for the Aisleriot games. I don't really recall how this is
done.

> * intltool-merge:
>   These are all GNOME specific file formats, so I feel this code rightfully
>   is in intltools, not in GNU gettext.

Probably.

> * intltool-update:
>   Do you think some of this is general enough that it belongs into GNU gettext?
>   If so, which parts? Btw, is intltool-update a tool for translators or for
>   developers?

Some of it yes. I would really like an option like --maintain for
gettext.

intltool-update is mostly for translators. It is some kind of msgfmt
that just works for more formats. Maintainers like the -maintain option
though.

-- 
Kenneth Rohde Christiansen <kenneth gnu org>