On 2/27/06, Netocrat <[EMAIL PROTECTED]> wrote: > Axel Liljencrantz wrote: > > On 2/27/06, Netocrat <[EMAIL PROTECTED]> wrote: > > > >>I've had this in the back of my mind for a while and have finally found > >>the time and clarity to respond. > > > > I'm grateful. I've been trying to come to a solution and start coding > > lately, so your timing is perfect. > > It was a useful break from coding for me so I'm glad it was timely for you. > > >>Axel Liljencrantz wrote: > [...] > >>>1). Making all descriptions, both for functions and completions > >>>automatically translated at runtime. The main drawbacks: > >>> > >>>* Moves things into the shell that where previously handled externally. > >>>* The standard 'xgettext' command can no longer be used to extract > >>>translation strings directly. But I'm not sure this is a big issue - > >>>one can simply write a script that does the extraction and outputs > >>>text in a format readily understood by xgettext. > >> > >>Unless I've missed something, you could retain the xgettext command by > >>simply redefining the '_' alias to always use printf. > > > > You are completely right, I hadn't though about that. Though I think > > one should keep '_' to be an alias to gettext and use 'N_' for the > > gettext-noop, since that is the usual meaning of the respective C > > macros. > > > > A very nice solution, I might add. > > Yes, it just popped out of the box but it does seem neat. > > [...] > > For once, I > > am inclined to lean towards integrating things into the shell binary. > > There comes a time when the external solution has enough drawbacks and > > warts that it's not worth the effort. > [...] > > What this boils down > > to is that we move one of two things into the shell: > > > > * Clever special purpose code to reload files in certain situations. > > One could probably implement most of this in shellscript, e.g. using > > an even handler to trigger the reloading whenever LANG and friends > > change values. > > * Simple code to perform just-in-time translation of some specific strings > > > > Though it can be argued that the former is more general purpose, I can > > honestly say that I don't see why it would have more uses than the > > latter. It seems to be a feature with extremely few real world > > applications. The latter means is a very small and simple addition in > > comparison. > > > > Though I know I'm losing serious fundamentalist-points on this one, I > > think I'm going go with the just-in-time translation of strings inside > > the fish binary solution. > > I don't think you're losing too many fundie-points the way things are > right now - the amount of code added to the shell for the supposedly > "out-of-shell" solution would as you say be greater and more complicated > than the solution you've picked - and that's not even considering > external scripting; also it avoids corner-cases. The main legitimate > criticism that I can see is that it probably has a slight average > performance disadvantage compared to a per-file on-demand load (although > the per-file demand-load has a larger latency on first load). But > performance isn't fish's primary goal, and I doubt that the difference > will even be noticeable for normal usage.
The jit solution should be plenty fast enough. The only reason any translations ever take a noticable amount of time is if they use the gettext command. By calling the gettext function inside fish, you avoid a call to fork and a reinitialization of the gettext database, which are the reasons why things can sometimes be slow when it comes to translations in fish. > > If fish already used an event-handling model for completions as we've > discussed as a possibility in the past, then I think the out-of-shell > approach would be a more plausible solution because it would already be > general-purpose. The way that could work is that completion files are > stored such that accessing the definition of a specific completion is > very quick, so that they could be pulled out on-demand (and translated > at the same time) by a completion-event handler. There'd be a > performance penalty, and greater than that of the in-shell solution, but > you'd definitely get to keep all fundie-points. Right. But a true fundamentalist might mean that it is more important to keep the shell theoretically and conceptually clean than actually make the implementation clean per se. I'm fundamentalist-light? > > The translation of fish function-description strings is still a > special-case to be handled in that situation; that could be solved by > adding a new specifier (e.g. --description-delayed) - using that rather > than --description could indicate that the translation is to be > performed on-demand, either by the shell or a handler (e.g. > "on-translate"). I can't see any other corner-cases but I'm not as > familiar with it all as you. If no completion is avaliable, then the original string will be printed. When would it be specifically harmfull to even attempt a translation? > > -- > http://members.dodo.com.au/~netocrat > -- Axel ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
