Prepare a GLib Source Tree for gettext with glib-gettextize

You will add the gettext support file that a GLib or GLib-based Autotools project needs, while keeping the source tree's existing files under review. The command normally creates po/Makefile.in.in as a symlink to the installed template. You can request a real copy instead, and you can refuse an overwrite unless you explicitly choose the force option.

Allow about fifteen minutes. You need a source tree that uses a po/ directory and an ordinary shell. This guide uses the packaged Ubuntu command from libglib2.0-dev-bin, version 2.80.0-6ubuntu3.9, whose executable reports GLib version 2.80.0. The examples prepare files; they do not run Autoconf, edit your translation catalogue or commit changes.

1. Check which binary will run

Start with read-only checks. This matters on machines that have more than one GLib installation:

$ type -a glib-gettextize
glib-gettextize is /home/linuxbrew/.linuxbrew/bin/glib-gettextize
glib-gettextize is /usr/bin/glib-gettextize
$ /usr/bin/glib-gettextize --version
/usr/bin/glib-gettextize (GNU glib) 2.80.0

On this machine, an earlier Homebrew entry in PATH resolves to GLib 2.86.4, while /usr/bin/glib-gettextize is the command supplied by the installed Debian package. Use the path for the version you have reviewed. If your package manager installs the command elsewhere, replace /usr/bin/glib-gettextize after checking that path with command -v and --version.

Checkpoint: do not continue until the executable and version are the ones you intend to use.

2. Inspect the project before changing it

Change into the top level of the source package and inspect the relevant paths:

$ cd /path/to/project
$ test -d po && echo 'po directory exists'
po directory exists
$ find po -maxdepth 1 -type f -o -type l | sort
$ test -f configure.ac && echo 'configure.ac exists'

Replace /path/to/project with the real project directory. The optional directory argument to glib-gettextize is the package directory, so running it from the project root and passing . makes the target explicit. Keep the result of find: it gives you a simple before-and-after record.

This command writes inside the project. Make a normal version-control checkpoint, or at least save a patch, before proceeding. Do not run it in a source tree containing unreviewed changes if you cannot distinguish its generated file from your own work.

3. Add the template without forcing an overwrite

Run the default operation first:

$ /usr/bin/glib-gettextize .
Symlinking file po/Makefile.in.in

Please add the files
  codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4
  progtest.m4
from the /usr/share/aclocal directory to your autoconf macro directory
or directly to your aclocal.m4 file
...

The final reminder also mentions config.guess and config.sub. It is guidance for the surrounding Autotools setup, not a claim that this invocation copied those files. The operation itself creates or replaces the gettext template link and does not create an intl/ directory or modify po/ChangeLog.

If po/Makefile.in.in already exists, the command stops with a non-zero status and tells you to use -f if you really want to delete it. That refusal is the safe default. Do not add --force merely to make a script continue.

Checkpoint: confirm the command's status before inspecting the file:

$ printf 'exit status: %s\n' "$?"
exit status: 0
$ ls -l po/Makefile.in.in
lrwxrwxrwx ... po/Makefile.in.in -> /usr/share/glib-2.0/gettext/po/Makefile.in.in
$ readlink -f po/Makefile.in.in
/usr/share/glib-2.0/gettext/po/Makefile.in.in

Exact permission text varies. The useful checks are a zero status, a link at the expected project path, and a target that exists.

4. Choose a copy when the source tree must be self-contained

A symlink depends on the installed GLib package remaining available at the target path. For a source archive, build workspace or environment where that dependency should be explicit, use --copy:

$ /usr/bin/glib-gettextize --copy .
Copying file po/Makefile.in.in
$ test -f po/Makefile.in.in && echo 'template is a regular file'
template is a regular file
$ test ! -L po/Makefile.in.in && echo 'not a symlink'
not a symlink

Choose this before the first successful run, or remove an existing generated link only after checking it and recording the change. Removing a generated file is destructive to that file's current contents, so keep your checkpoint. If the file is project-owned or differs from the installed template, stop and compare it rather than overwriting it.

5. Use force only after comparing the old file

-f and --force allow the command to write a new file when an old one exists:

$ diff -u po/Makefile.in.in /path/to/known-template
$ /usr/bin/glib-gettextize --force --copy .
Copying file po/Makefile.in.in

The comparison path above is only an example. Use a real template path or compare the file through your version-control tool. Do not use force until you know whether the existing file contains local changes. There is no undo option in glib-gettextize; recover by restoring the file from version control or from the backup you made before the command.

6. Check the surrounding Autotools work

glib-gettextize prepares one part of an internationalisation setup. Its successful exit does not prove that configure.ac, Makefile.am, POTFILES.in or the Autoconf macros are complete. Review the command's reminder, then inspect the project changes:

$ git status --short
 M po/Makefile.in.in
$ git diff --stat
$ find po -maxdepth 1 -type f -o -type l | sort

The exact status line depends on whether the generated file is tracked and whether it is a link. If the command reports a missing input or cannot write the template, check the project path, po/ permissions and the installed template without changing anything:

$ test -r /usr/share/glib-2.0/gettext/po/Makefile.in.in && echo readable
$ test -w po && echo writable
$ /usr/bin/glib-gettextize --help

Elevated privileges are not normally required. Do not use sudo to hide an ownership problem in a source tree; fix the directory ownership or work in a directory you can write. Running as root can leave generated files that your normal account cannot update.