[GRASS5] I18N for GRASS: continued discussion

[Glynn Clements]

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?

From the bug reports which arose immediately after the release, we
know that none of the recent versions had been tested on the Mac (I'm
fairly sure that the "libedit" change pre-dated the libgis I18N, and
the problems with that weren't found until after the release).

> 3. Tcltkgrass and intro messages: locale is set up during install and for good,
> which is not correct because it should be determined and chosen on startup
> of GRASS.
> ---------------------------
> 
> This is right but misleading. Neither tcltkgrass messages nor
> grass_into and license messages are defined on install. Actually, as
> it follows from the [locale/Gmakefile], all possible locales are
> installed into $(INST_DIR)/locale, including tcltkgrass messages and
> text files, 'only if' GRASS was configured with NLS support.

Yes; I changed it; It originally used the value of $LANG at compile
time.

However, tcltkgrass is still only consulting LANG; for consistency
with C programs which use dgettext(), it should be checking:

	LC_ALL
	LC_MESSAGES
	LANG

in that order. Init.sh consults all three, but has the ordering wrong.

> 4. More testing is needed to find out other dangers from I18N looming,
> before such code can be included into any stable release.
> 
> ---------------------------
> 
> No other testing except the developer's would be possible if you do
> not include the subjects to be tested into the release.

Well, some people did actually test the various -beta and -pre
releases, and even the bleeding-edge CVS versions. It just didn't
happen enough.

Now that 5.0.0 has finally been released, I'm less concerned about the
remote possibility of any I18N-related problems. However, I would
still prefer to see 5.0.1 being a bugfix-only release, with the
critical I18N changes (libgis, startup, tcltkgrass) saved for 5.0.2.

That needn't mean a long wait. Personally, I would have liked to have
seen 5.0.1 released as soon as the initial batch of MacOSX/gcc-3.x bug
reports had been dealt with, but Bernhard didn't seem too keen on
that.

-- 
Glynn Clements <glynn.clements@virgin.net>