On 6 August 2010 11:59, Chris Pickett <[email protected]> wrote: > 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.
I fully agree with Irek and Chris. Maybe Finnbarr will agree as well. The Korn shell is a high level language which should provide easy and FLEXIBLE feature access. Everyone who wants to sacrifice the flexibility for performance should better use C or C++. Performance is good but I don't think it matters when the closest competitor is /usr/bin/gettext >:-) and I'd opt for $"" strings to be able to replace /usr/bin/gettext in any aspect of runtime changes to ( NLSPATH, LC_MESSAGES ) Ced -- Cedric Blancher <[email protected]> Institute Pasteur _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
