Re: gettext feature request

[Jean-Jacques Brucker]

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).
> >   * 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 
"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.


:-)

Jean-Jacques

OpenPGP_signature
Description: OpenPGP digital signature