[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