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. 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? -- Axel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
