On Thu, Aug 5, 2010 at 11:52 PM, David Korn <[email protected]> wrote:
> cc:  [email protected]  [email protected]          
> [email protected]  [email protected]          
> [email protected]
> Subject: Re: Re: Re: Re: Re: Re: [ast-developers] Re: [ast-users] Write up on 
> how   to localize shell scripts - Second Try
> --------
>
>> Why are the strings frozen at this point? Why can't the shell look the
>> message up in the current catalog each time it is used? We could live
>> with slow and unfrozen localised string literals but not with the
>> inability to switch the message locale of already established
>> functions. We require this to use the localised string literals in an
>> installer which must be able to instantly switch between languages
>> without having to restart the installer (this is a typical installer
>> feature users expect these days).
>>
>> Irek
>>
>
> I am not sure that most people would be willing to give up performance
> for all scripts that use $"...".

$"string" competes with /bin/gettext. Whatever you do, it will be hard
to be slower than /bin/gettext :)

I really would opt for *flexibility* and implement the spirit of the
POSIX shell standard first. We can look at performance later, if there
is the need to do so. But I doubt it will be a problem for the time
being.

> An installer can ask for the locale, then set the locale, and
> the remainder of the script will use that locale.
>
> Another possibility is to add an option that would defer locale
> expansions until execution.  However, this would either have
> to be given as a command option or appear at the start of
> the file before any other commands.

3rd possibility is to add a compile time switch that distributions can
pick either flexibility or speed for $"string" literals. But I doubt
speed is a problem, compared to the other issues I explained earlier.

Chris
-- 
    ^---^
   (@)v(@)  Chris Pickett
   |    /   IT consultant
 ===m==m=== [email protected]
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers

Reply via email to