[Gtk-sharp-list] i18n of gtk# applications

Jonathan Pryor jonpryor@vt.edu
Sat, 19 Feb 2005 11:19:57 -0500


On Sat, 2005-02-19 at 00:14 +0100, Fabian Sturm wrote:
> I am trying to find out what is the best way to internationalize my mono
> programs. The goal is to have a portable way which works on Linux and
> Windows and can translate strings and widgets loaded from glade files.

Mono != Gtk#. :-)  More below.

> The ideal solution would be to have a way which works "out of the box"
> on windows and linux (macosx too of course).

There are three basic ways to do i18n within Mono: using gettext (or
some variant thereof), using GNU.Gettext, and using System.Resources.

Your web page presents two variations of gettext.  Which one you use
doesn't really matter, as they all depend (ultimately) on the gettext C
libraries.

GNU.Gettext, your third solution, tries to bridge standard gettext and
System.Resources.

System.Resources, the 4th solution you list on your page, is fully
supported by Mono.  Mono has its own resgen program, and
System.Resources works on all platforms, including .NET, without
requiring any additional libraries (no gettext dependency).

This would imply that System.Resources should be used, right?

Well, maybe.

Glade, IIRC, is tied to gettext; I know of no way to get it to use
System.Resources.

Gettext has the added advantage that most Free Software projects use it,
so the facilitating tools are well known.  This simplifies life for
translators, who can stick with their existing tools.  It has the
disadvantage that it's not included with Windows, so anything using it
under .NET will require additional libraries.  This isn't a Mono-
specific issue; if you want your program to run under .NET and use
gettext, you have to include gettext with your app.

This is why GNU.Gettext looks interesting, because it allows you to use
the standard gettext translation functions and use the .NET standard
resources framework.  Even better, GNU.Gettext can be used under .NET
*without* requiring GNU.Gettext.dll; simply use `msgformat --csharp-
resources` to create a .resources file, add the .resources to your
assembly, and use System.Resources to load your strings.

If you use Gtk#+Glade, you should gettext, through one of its
variations.  (You can, of course, use System.Resources instead, but this
would require that you manually assign strings to all your widgets,
removing any benefit of using the GTK+ stock controls.)  I don't know if
GNU.Gettext integrates with Glade; I would assume that it doesn't, since
Glade uses libglade, which uses gettext directly, IIRC.

If you use System.Windows.Forms, System.Resources may be more sensible.
Similar for ASP.NET.

Finally, some corrections to your web page:

Mono.Posix.Catalog will be deprecated as of Mono 1.2; Mono.Unix.Catalog
is the replacement.  It should be usable under Win32, as long as the
required gettext libraries are installed.  (Gettext should be usable
under Win32; if it wasn't, then The Gimp couldn't run there. :-)

If Mono.Unix.Catalog can't run under Windows due to library name
differences, please let me know and I'll try to correct this.

Your second solution, Catalog, is virtually identical to
Mono.Unix.Catalog (says the guy reading the source).  The only
difference is that Catalog DllImports libc.so instead of libintl.  The
only benefit of Catalog is that you don't need to link to
Mono.Posix.dll, which seems a rather strange thing to avoid doing (says
the current maintainer, biased he may be).

Finally, for System.Resources, the Pros are that it is (should be) fully
supported by default installations of Portable.NET, Mono, .NET, and
Rotor -- no additional assemblies are required.  This invalidates all of
your Cons. :-)

The true Con is that System.Resources doesn't integrate with gettext,
unless you look at GNU.Gettext, and that it doesn't integrate AT ALL
with Glade.

Moral of the story: If you plan on doing international software with
Gtk#+Glade, stick with gettext.  If you're using some other widget set
(console output, System.Windows.Forms, wx.NET, etc.), you have more
flexibility, so choose whichever is most convenient (probably
System.Resources of GNU.Gettext.dll).

 - Jon