gettext in build system

gettext in build system

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]


I wrote initial support for gettext in build system.  It is available in:

  sftp://bzr.savannah.gnu.org/srv/bzr/grub/people/robertmh/gettext/

also attached.  It probably still needs some polish, please comment.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

[-- Attachment #2: gettext.diff --]
[-- Type: text/x-diff, Size: 4144 bytes --]

=== modified file 'Makefile.in'
--- Makefile.in	2009-11-15 12:41:25 +0000
+++ Makefile.in	2009-11-15 23:01:10 +0000
@@ -41,6 +41,8 @@ includedir = @includedir@
 pkgdatadir = $(datadir)/`echo @PACKAGE_TARNAME@ | sed '$(transform)'`
 pkglibdir =  $(libdir)/`echo @PACKAGE_TARNAME@/$(target_cpu)-$(platform) | sed '$(transform)'`
 
+LINGUAS = ca
+
 PACKAGE_NAME = @PACKAGE_NAME@
 PACKAGE_TARNAME = @PACKAGE_TARNAME@
 PACKAGE_VERSION = @PACKAGE_VERSION@
@@ -153,7 +155,7 @@ include $(srcdir)/conf/$(target_cpu)-$(p
 
 ### General targets.
 
-CLEANFILES += $(pkglib_DATA) $(pkgdata_DATA)
+CLEANFILES += $(pkglib_DATA) $(pkgdata_DATA) po/*.mo
 pkglib_DATA += moddep.lst command.lst fs.lst partmap.lst parttool.lst handler.lst
 moddep.lst: $(DEFSYMFILES) $(UNDSYMFILES) genmoddep.awk
 	cat $(DEFSYMFILES) /dev/null \
@@ -237,7 +239,7 @@ build_env.mk: Makefile
 	) > $@
 pkglib_BUILDDIR += config.h grub_script.tab.h
 
-all-local: $(PROGRAMS) $(PKGLIB) $(PKGDATA) $(SCRIPTS) $(INFOS) $(MKFILES)
+all-local: $(PROGRAMS) $(PKGLIB) $(PKGDATA) $(SCRIPTS) $(INFOS) $(MKFILES) $(foreach lang, $(LINGUAS), po/$(lang).mo)
 
 install: install-local
 
@@ -301,6 +303,13 @@ install-local: all
 	  dest="`echo $$file | sed 's,.*/,,'`"; \
 	  $(INSTALL_DATA) $$dir$$file $(DESTDIR)$(libdir)/grub/$$dest; \
 	done
+	$(foreach lang, $(LINGUAS), \
+	$(SHELL) $(mkinstalldirs) $(DESTDIR)/$(datadir)/locale/$(lang)/LC_MESSAGES
+	@list='po/$(lang).mo'; \
+	for file in $$list; do \
+	  if test -f "$$file"; then dir=; else dir="$(srcdir)/"; fi; \
+	  $(INSTALL_DATA) $$dir$$file $(DESTDIR)/$(datadir)/locale/$(lang)/LC_MESSAGES/grub.mo; \
+	done)
 	$(SHELL) $(mkinstalldirs) $(DESTDIR)$(infodir)
 	@list='$(info_INFOS)'; \
 	for file in $$list; do \
@@ -455,6 +464,16 @@ gensymlist.sh: gensymlist.sh.in config.s
 genkernsyms.sh: genkernsyms.sh.in config.status
 	$(SHELL) ./config.status
 
+po/messages.pot: po/POTFILES
+	xgettext --from-code=utf-8 --keyword=_ -f $< -o $@
+
+po/*.po: po/messages.pot
+	msgmerge -U $@ po/messages.pot
+
+po/%.mo: po/%.po
+	$(MKDIR_P) $$(dirname $@)
+	msgfmt -c --statistics -o $@ $^
+
 .PHONY: all install install-strip uninstall clean mostlyclean distclean
 .PHONY: maintainer-clean info dvi dist check
 

=== added directory 'po'
=== added file 'po/POTFILES'
--- po/POTFILES	1970-01-01 00:00:00 +0000
+++ po/POTFILES	2009-11-15 23:00:07 +0000
@@ -0,0 +1,2 @@
+# List of files which contain translatable strings.
+util/i386/pc/grub-mkimage.c

=== added file 'po/ca.po'
--- po/ca.po	1970-01-01 00:00:00 +0000
+++ po/ca.po	2009-11-15 23:05:55 +0000
@@ -0,0 +1,20 @@
+# Copyright (C) 2009  Free Software Foundation, Inc
+# This file is distributed under the same license as the GNU GRUB package.
+# Robert Millan <rmh.grub@aybabtu.com>, 2009.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: GNU GRUB\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2009-11-16 00:05+0100\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: Robert Millan <rmh.grub@aybabtu.com>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: util/i386/pc/grub-mkimage.c:322
+#, c-format
+msgid "Try ``%s --help'' for more information.\n"
+msgstr "Proveu «%s --help» per a obtenir més informació.\n"

=== modified file 'util/i386/pc/grub-mkimage.c'
--- util/i386/pc/grub-mkimage.c	2009-09-24 13:40:40 +0000
+++ util/i386/pc/grub-mkimage.c	2009-11-15 22:59:36 +0000
@@ -33,6 +33,10 @@
 #include <string.h>
 #include <stdlib.h>
 
+#include <locale.h>
+#include <libintl.h>
+#define _(str) gettext(str)
+
 #define _GNU_SOURCE	1
 #include <getopt.h>
 
@@ -315,7 +319,7 @@ static void
 usage (int status)
 {
   if (status)
-    fprintf (stderr, "Try ``grub-mkimage --help'' for more information.\n");
+    fprintf (stderr, _("Try ``%s --help'' for more information.\n"), progname);
   else
     printf ("\
 Usage: grub-mkimage [OPTION]... [MODULES]\n\
@@ -349,6 +353,8 @@ main (int argc, char *argv[])
 
   progname = "grub-mkimage";
 
+  textdomain ("grub");
+
   while (1)
     {
       int c = getopt_long (argc, argv, "d:p:m:c:o:hVv", options, 0);

Re: gettext in build system

[Robert Millan]

On Mon, Nov 16, 2009 at 12:13:55AM +0100, Robert Millan wrote:
> +po/messages.pot: po/POTFILES
> +	xgettext --from-code=utf-8 --keyword=_ -f $< -o $@
> +
> +po/*.po: po/messages.pot
> +	msgmerge -U $@ po/messages.pot
> +
> +po/%.mo: po/%.po
> +	$(MKDIR_P) $$(dirname $@)
> +	msgfmt -c --statistics -o $@ $^

Obvious missing thing is that these should be autoconffed.

> +#define _(str) gettext(str)

And I'm not sure if this is the right place to define _.  Isn't there
a system-wide definition?

> +  textdomain ("grub");

What's the usual way to handle this?  TEXTDOMAIN macro?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: gettext in build system

[Colin Watson]

On Mon, Nov 16, 2009 at 12:59:09AM +0100, Robert Millan wrote:
> On Mon, Nov 16, 2009 at 12:13:55AM +0100, Robert Millan wrote:
> > +#define _(str) gettext(str)
> 
> And I'm not sure if this is the right place to define _.  Isn't there
> a system-wide definition?

It's traditional to define _ in each project, since it's rather
namespace-invasive.

> > +  textdomain ("grub");
> 
> What's the usual way to handle this?  TEXTDOMAIN macro?

I usually use textdomain (PACKAGE).

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: gettext in build system

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On Mon, Nov 16, 2009 at 12:23:04AM +0000, Colin Watson wrote:
> > > +  textdomain ("grub");
> > 
> > What's the usual way to handle this?  TEXTDOMAIN macro?
> 
> I usually use textdomain (PACKAGE).

It's a bit unusual that we don't have PACKAGE.  This is usually provided
by aclocal via AM_INIT_AUTOMAKE(), so I guess it's time to start
auto-generating aclocal.m4, as with attached patch.

Comments?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

[-- Attachment #2: aclocal.diff --]
[-- Type: text/x-diff, Size: 768 bytes --]

2009-11-16  Robert Millan  <rmh.grub@aybabtu.com>

	* aclocal.m4: Move from here ...
	* acinclude.m4: ... to here.
	* autogen.sh: Add call to `aclocal'.
	* configure.ac: Add AM_INIT_AUTOMAKE() after AC_INIT() call.

=== renamed file 'aclocal.m4' => 'acinclude.m4'
=== modified file 'autogen.sh'
--- autogen.sh	2009-11-08 16:43:36 +0000
+++ autogen.sh	2009-11-16 19:01:50 +0000
@@ -2,6 +2,7 @@
 
 set -e
 
+aclocal
 autoconf
 autoheader
 echo timestamp > stamp-h.in

=== modified file 'configure.ac'
--- configure.ac	2009-11-09 19:58:24 +0000
+++ configure.ac	2009-11-16 19:00:41 +0000
@@ -32,6 +32,7 @@ dnl type.
 
 
 AC_INIT([GRUB],[1.97],[bug-grub@gnu.org])
+AM_INIT_AUTOMAKE()
 AC_PREREQ(2.59d)
 AC_CONFIG_SRCDIR([include/grub/dl.h])
 AC_CONFIG_HEADER([config.h])

Re: gettext in build system

[Jordi Mallach]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

Hi Robert,

Please excuse the total lack of input on this issue, I've been really
busy the last few weekends.

On Mon, Nov 16, 2009 at 12:59:09AM +0100, Robert Millan wrote:
> On Mon, Nov 16, 2009 at 12:13:55AM +0100, Robert Millan wrote:
> > +po/messages.pot: po/POTFILES
> > +	xgettext --from-code=utf-8 --keyword=_ -f $< -o $@
> > +
> > +po/*.po: po/messages.pot
> > +	msgmerge -U $@ po/messages.pot
> > +
> > +po/%.mo: po/%.po
> > +	$(MKDIR_P) $$(dirname $@)
> > +	msgfmt -c --statistics -o $@ $^
> 
> Obvious missing thing is that these should be autoconffed.

Also, as something merely cosmetic, messages.pot could be $(PACKAGE).pot,
which is more common.

> > +#define _(str) gettext(str)
> And I'm not sure if this is the right place to define _.  Isn't there
> a system-wide definition?

This, and others, sometimes go in a common .h to avoid duplication. Many
grub utilities are going to add this kind of stuff.

> > +  textdomain ("grub");
> What's the usual way to handle this?  TEXTDOMAIN macro?

As Colin said, $PACKAGE is common.
I haven't tested this patch yet, but I'm not sure if a bindtextdomain()
call is needed here too.

The rest looks good, given there's no automake.

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi@sindominio.net     jordi@debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: gettext in build system

[Robert Millan]

On Mon, Nov 16, 2009 at 08:09:56PM +0100, Jordi Mallach wrote:
> 
> Also, as something merely cosmetic, messages.pot could be $(PACKAGE).pot,
> which is more common.

Changed in my gettext branch.

> > > +#define _(str) gettext(str)
> > And I'm not sure if this is the right place to define _.  Isn't there
> > a system-wide definition?
> 
> This, and others, sometimes go in a common .h to avoid duplication. Many
> grub utilities are going to add this kind of stuff.

I wonder where would we put this.  Is there any convention?

> > > +  textdomain ("grub");
> > What's the usual way to handle this?  TEXTDOMAIN macro?
> 
> As Colin said, $PACKAGE is common.
> I haven't tested this patch yet, but I'm not sure if a bindtextdomain()
> call is needed here too.

This requires LOCALEDIR.  Should we add po.m4 in order to get this, or
just define it ourselves?

> The rest looks good, given there's no automake.

We have aclocal now (in my branch).  Is gettext.m4 usable to us?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: gettext in build system

[Robert Millan]

Btw, I gettextified util/grub.d/10_linux.in in my gettext branch, but adding
it to POTFILES is a bit problematic.

xgettext recognizes languages either by checking the file suffix or via
explicit command-line option.  However 10_linux.in doesn't end in .sh and
--language=Shell in the generic xgettext call would break detection of C
files.

Is there a solution that doesn't involve renaming 10_linux.in nor maintaining
a separate list of files for Shell language?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: gettext in build system

[Jordi Mallach]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

On Mon, Nov 16, 2009 at 09:24:08PM +0100, Robert Millan wrote:
> xgettext recognizes languages either by checking the file suffix or via
> explicit command-line option.  However 10_linux.in doesn't end in .sh and
> --language=Shell in the generic xgettext call would break detection of C
> files.
> 
> Is there a solution that doesn't involve renaming 10_linux.in nor maintaining
> a separate list of files for Shell language?

We need to look at what tricks intltool uses for this, as GNOME translates
desktop files and other "unusual" files using .in files. Can't do that
right now though, I need to go to bed RSN.

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi@sindominio.net     jordi@debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: gettext in build system

[Jordi Mallach]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

On Mon, Nov 16, 2009 at 08:56:06PM +0100, Robert Millan wrote:
> > > > +#define _(str) gettext(str)
> > > And I'm not sure if this is the right place to define _.  Isn't there
> > > a system-wide definition?
> > This, and others, sometimes go in a common .h to avoid duplication. Many
> > grub utilities are going to add this kind of stuff.
> I wonder where would we put this.  Is there any convention?

I'm not aware of any convention, not even for GNU packages. nls.h, i18n.h,
grub-i18n.h. You name it. :)

> > I haven't tested this patch yet, but I'm not sure if a bindtextdomain()
> > call is needed here too.
> This requires LOCALEDIR.  Should we add po.m4 in order to get this, or
> just define it ourselves?

*shrug*, I think just assuming the usual $(datadir)/locale is ok. po.m4
does provide checks for the gettext tools iirc, though, so that might
be useful in its own right.

> > The rest looks good, given there's no automake.
> We have aclocal now (in my branch).  Is gettext.m4 usable to us?

I think so, if platforms which don't use GNU gettext, or have an incompatible
gettext implementation are supported. It provides checks for gettext(),
ngettext(), setlocale() and friends, so yep, probably.

-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi@sindominio.net     jordi@debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: gettext in build system

[Robert Millan]

On Mon, Nov 16, 2009 at 11:32:52PM +0100, Jordi Mallach wrote:
> On Mon, Nov 16, 2009 at 08:56:06PM +0100, Robert Millan wrote:
> > > > > +#define _(str) gettext(str)
> > > > And I'm not sure if this is the right place to define _.  Isn't there
> > > > a system-wide definition?
> > > This, and others, sometimes go in a common .h to avoid duplication. Many
> > > grub utilities are going to add this kind of stuff.
> > I wonder where would we put this.  Is there any convention?
> 
> I'm not aware of any convention, not even for GNU packages. nls.h, i18n.h,
> grub-i18n.h. You name it. :)

Ok.  <grub/i18n.h> then.

> > > I haven't tested this patch yet, but I'm not sure if a bindtextdomain()
> > > call is needed here too.
> > This requires LOCALEDIR.  Should we add po.m4 in order to get this, or
> > just define it ourselves?
> 
> *shrug*, I think just assuming the usual $(datadir)/locale is ok. po.m4
> does provide checks for the gettext tools iirc, though, so that might
> be useful in its own right.

I enabled AM_GNU_GETTEXT() which drags that in, as well as a few of the
other declarations we needed.

Thanks!

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: gettext in build system

[Robert Millan]

I think my gettext branch is reasonably complete now.  If you can, anyone
please review before I merge it in trunk:

  sftp://bzr.savannah.gnu.org/srv/bzr/grub/people/robertmh/gettext/

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."