bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib localizations


From: Bruno Haible
Subject: Re: gnulib localizations
Date: Sun, 08 Dec 2024 09:34:00 +0100

Hi Gavin,

> If possible, gnulib translations should be made without much adaptation
> by the developers of the package using gnulib.

Yup. That's what was the main mistake in the approach (b) from 2008.

> The main requirement
> for developers is to add the bindtextdomain call with the directory
> name of LOCALEDIR, which is usually $(datadir)/locale.

Yes, in approach (a) this is all that you will need.

> The Gnulib build system installs the translation files, so it should
> be able to provide the location of the translation files to Gnulib
> code automatically.  Could gnulib infrastructure provide the value of
> LOCALEDIR using the "datadir" configure value

Yes, absolutely.

> , calling "bindtextdomain" automatically as required?

No, adding the actual bindtextdomain() call is something the programmer
needs to do. (I don't want to play with gcc's __attribute__ ((__constructor__))
since it violates the principle of least surprise.)

> I think the problem with requiring extra packages to be installed is
> that it seems to against the gnulib philosophy that it is not a separate
> library and does not have to be installed separately from packages that
> use it.

Yes, that was probably part of my thinking in 2008, and what led to the
failure.

> Another issue is that the translated strings may depend on the point of
> time the package took its code from gnulib.  Some packages may reference
> strings that do not exist in newer versions of gnulib.  So it makes
> sense for the gnulib code import and the gnulib translations import to be
> close in time together, assuming the gnulib translations are up-to-date.

This too was certainly part of my thinking in 2008. I thought "100% translated"
is better than "98% translated". Not realizing that the added complexity for
the "100% translated" would lead to only 10% of the packages adopting the
approach.

Oh I hate the "worse is better" approach, because I am a perfectionist.
But here at least, Linus' "keep it simple, stupid" principle is better.

> If it was required for operating systems to install a separate package
> containing translations for all of the gnulib translations, it is likely
> that it would often not be installed.

I disagree. Once GNU coreutils and GNU gettext have a dependency to this
package (in a distro), it will likely be installed for most users.

Thanks for your feedback.

Bruno






reply via email to

[Prev in Thread] Current Thread [Next in Thread]