[Top][All Lists]

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

Re: gettext feature request

From: Jean-Jacques Brucker
Subject: Re: gettext feature request
Date: Sat, 31 Jul 2021 22:17:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0

Le 29/07/2021 à 21:08, Chet Ramey a écrit :

How about `noexpand_translation'?

It sounds good ! (imho).

IMHO bash already suffers of having too many options. And using, or not, one of those often breaks compatibility.

It's not really a matter of having too many options, as long as the
defaults are good and preserve backwards compatibility. That way, people
who want the new behavior can opt in, and people who want no changes don't
have to change anything. If, at some point, it makes sense to change the
default behavior, it's a matter of changing the default value of that
option, which still allows users who want the old behavior a way to get it.

Now, changing that default behavior, no matter what the reason or how long
the option has been there, is always going to present problems. But
sometimes you do it.

Finally there is an other and maybe better solution, by implementing one or two more variables:

  * TEXTCDOMAIN (or TEXTQUOTEDOMAIN): if set, enable `quote_translation'
    feature (like TEXTDOMAIN does for actual translation features).
    TEXTDOMAINDIR does for actual translation features).

Did you just invent these variable names? Or are they actually used for
something right now? I prefer not to have optional behavior depend on
whether a variable exists. Sometimes you can't avoid it, such as when you
need a way to indicate more than two possible values, but this isn't one
of those cases.

Yes I just invented these names, they have no known usage.

The advantage of adding such variable is that we could use more easily different mo files in a same bash execution :

(at least) one "legacy" (for /$"..."/) and (at least) one 'C-strings' (for /$'...'/), which could then be shared with a C program (For example lazy people could then reuse coreutils mo files, as they contain lot of frequently-used-everywhere strings, while using their own mo file for "legacy" strings).

But I agree, the "benefit over complexity" ratio of such implementation might be not interesting.

Moreover it could encourage the use of "legacy" translations, whereas we know that this poses security problems.

If you prefer to enable translation for all /$'C-string'/ using the same existing variable TEXTDOMAIN (and TEXTDOMAINDIR), with an option 'noexpand_translation' to disable it. I am also fine with this idea.

It is an important choice. I would like to be sure we have not forgotten any argument in the balance.

Thanks a lot, Chet.



Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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