[GRASS5] I18N for GRASS: continued discussion

Glynn Clements glynn.clements at virgin.net
Tue Nov 12 18:46:31 EST 2002

Alex Shevlakov wrote:

> 1. Hypothetically, I18N shall break GRASS on some systems where
> dgettext is in libintl.
> ---------------------------
> There is no evidence known to me when it broke anything. As this was
> considered the major problem, I think we can learn and list what
> systems will break, and why.
> If we can list such systems, then we must place warnings to those
> systems users who want NLS support, to be aware of '--with-nls' option
> expected break on such systems.

We should fix the build process so that I18N works even on systems
where dgettext is in a separate library. This is the "normal"
situation; GNU libc is the exception.

The problem wasn't the I18N generally, but in the consequences of
internationalising libraries.

When individual modules were internationalised, the Gmakefile for that
module had $(INTLLIB) added to the link command, so that dgettext()
would be available.

Internationalising libgis would require that every module which linked
against libgis (i.e. every module) depended upon dgettext(). Rather
than adding $(INTLLIB) to every Gmakefile, the obvious solution is to
simply change src/CMD/generic/make.mid to use:

	GISLIB         = -lgis $(INTLLIB)

This is simple enough, and I'm 99.9% sure that it's safe. However,
it's that last 0.1% that concerned me. If there turned out to be a
problem, it would have broken *everything*. Most users can get by
without the *.pg programs; they can't get by without libgis. Ditto for
the GRASS startup and, to a lesser extent, tcltkgrass.

The situation regarding libgis, startup, and tcltkgrass was "probably"
safe, so GRASS would "probably" have worked OK. I'm just allergic to
changes which "probably" won't completely break GRASS being made weeks
before the long-awaited release.

The real problem was that the change was only made at a point when the
5.0.0 release was looking imminent. If it had been done six months
earlier, I wouldn't have been so concerned.

Unfortunately, we don't have a systematic test program. The only
platform which gets regular testing is Linux/x86. AFAICT, occasional
testing occurs for Cygwin, MacOS X, Solaris and Irix. A whole batch of
Mac OS X problems were only discovered once 5.0.0 was released.

For comparison, the Linux kernel is about to go into feature freeze
(prompting a massive increase in the rate of patch submissions). 
However, the actual 2.6 release isn't expected for another six months
yet. The Linux kernel has a hell of a lot more developers and testers
than does GRASS, and some of those are large corporations with rooms
full of systems for running test suites.

> 2. The I18N code modifications done to libraries make them system-wide
> dangerous.
> ---------------------------
> There is no difference in doing actual string replacement by gettext
> _(macro) inside the code of both modules and libraries; the I18N is
> done in the same way.
> Therefore there is no difference in: a) being relatively safe with
> modules internationalization and in b) being put in risk with
> libraries internationalization, whatever risk one could foresee.

But what about the risks which one doesn't foresee? The most dangerous
assumptions are the ones which you don't know that you're making.

> All
> modules use libraries, but this should not mean that all modules will
> break, nothing would break if I18N was done in duly way.

Correct. But what if it *wasn't* done quite right? What if there was
some unforeseen consequence of the libgis I18N?

More information about the grass-dev mailing list