I've had this in the back of my mind for a while and have finally found
the time and clarity to respond.
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.
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.
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/*.
--
http://members.dodo.com.au/~netocrat
-------------------------------------------------------
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&kid=110944&bid=241720&dat=121642
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
