[GRASS5] I18N for GRASS: continued discussion

[Alex Shevlakov]

> 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 should work fine. Without NLS option, I don't see how this could 
affect anything. If variable $(INTLLIB) was empty and someone requested 
NLS support, it would be impossible to compile if dgettext was not in glibc, 
but that's it. Vice versa, $(INTLLIB) non-empty and no NLS support enabled, 
it would not affect anything as there wouldn't be calls to the library.

> 
> 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.

I have only to point out again that the question is not whether some modules
or libraries must be considered as something one can just get by without.
Instead, the whole of i18n changes can be 'got by without' not giving 
'-with-nls' option.
If this option was proved to be dangerous, we warn you to be prepared,
nevertheless we leave it for ones who need it, including gettext in 
libraries, start up and tcltkgrass.

> > 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?

These bad consequences should be tried, at least. What if there are none?
The simplicity of the string replacement makes me think so.
Being not able to test it on some systems, I would notify the people
who use GRASS on these systems of the option of string replacement,
and that they are welcome to make it on their own risk and report 
about the consequences.

> 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.
> -- 
> Glynn Clements <glynn.clements at virgin.net>
> 

Alex Shevlakov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20021115/1e5d14c8/attachment.bin