[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gettext feature request
Re: gettext feature request
Sat, 31 Jul 2021 22:17:20 +0200
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
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
Now, changing that default behavior, no matter what the reason or how
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).
* And maybe TEXTCDOMAINDIR (or TEXTQUOTEDOMAINDIR): (like
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
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.
Description: OpenPGP digital signature
Re: gettext feature request, Léa Gris, 2021/07/24
Re: gettext feature request, Eli Schwartz, 2021/07/29