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.
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.
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.
--
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
