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. > > Axel Liljencrantz wrote: > > I've spent some time pondering about when and how to perform language > > translation in fish. Right now, all completion descriptions are > > translated whenever the completions for a command are first loaded by > > running the description through a subshell like this: > > > > complete -c somcmd -d (_ "Some string to translate") > > > > Where '_' is an alias for the gettext function of gettext is > > available, otherwise it is an alias for 'printf "%s"'. This has the > > advantage of not making translation in any way connected to fish, > > which is nice, but it also has two drawbacks: > > > > * It's a bit slow since every completion causes an invocation of the > > gettext command which has to do some reinitializing of the translation > > database. > > * Things go wrong if the user changes language at runtime. > > > > The former is not really a huge issue, things load pretty quickly most > > of the time. The latter problem is a bit bigger, however. Currently, > > whenever the language is changed, the completion database is purged. > > This works, but it's stupid. And it doesn't completely solve the > > problem, since there are other things than completions that need > > translation, and aren't dynamically loaded. > > > > I see two possible solutions: > > > > 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. > > > 2). Making it possible to use a command substitution that is evaluated > > at completion time as a description, i.e. somthing like: > > > > complete -c somecmd -d '(_ "Some string to translate")' > > > > would call gettext when the description is to be used. The main drawbacks: > > > > * Whereas having a slight delay the first time completing a given > > command is tolerable, this means that completion will be slow _every_ > > time, which is much worse, in my opinion. > > * Syntactically, I feel it is rather ugly to have lots and lots of > > commands that allow you to specify code in strings that will be > > evaluated at some later point in time. The fish design of event > > handling was specifically made to avoid passing code in strings, as it > > makes it impossible to validate code without running it. > > > > I'm leaning towards either doing nothing and accepting that we live in > > an imperfect world or going with the first solution, but I'm not > > really happy with either one. Opinions? > > Solution 2 seems least clean; the only drawback that I can see to > solution 1 is that it's moving code in the opposite direction to what > you like - into the shell rather than out. That's the same condensed conclusion I've been moving towards. Solution one is cleaner, easier to implement and has no known edge cases, but requirers moving functionality into the shell. 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. > > There may be a half-way approach between solution 1 and the current > purge-all-completions: on-demand reloading and retranslation > per-completion file. > > When first loading all completions, fish could determine which > completion file each base command is defined in. Then it could > internally associate a last-loaded timestamp with each file, as well as > a last-changed timestamp for the language variable. Then when > completing a command, it could check which completion file it belongs > to, and reload/retranslate that file only, if and only if its > last-loaded timestamp is earlier than the language-change timestamp. > > A similar approach could be used for functions defined in share/functions/*. Indeed, that would work as well. Nicely spotted. 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. > -- > 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
