Re: IRC client for Emacs

[Noah Friedman <friedman@splode.com>]

>    Maybe for applications within Emacs.  In erc.el there is code like
>    this:
>
>    (defun erc-make-message-variable-name (catalog entry)
>      (intern (concat "erc-message-"
>		      (symbol-name catalog) "-" (symbol-name entry))))
>
>This seems like a space-inefficient way to store the data, creating a
>symbol for each translatable string.  Aside from that, how would you
>load a new message catalog?  I suppose you would set each of these
>variables.  That means Emacs can only hold one message catalog
>for the category at any time.

zenirc already uses separate hashtables for each language, so multiple
languages at once are supported and the current language can be
buffer-local.

It looks to me like the erc API is pretty similar to the zenirc API in
regard to using symbols for the catalog entry lookup.  The reason zenirc
chose this method was because the actual message strings change in cosmetic
ways from time to time and people aren't necessarily good at keeping the
rest of the catalogs up to date.  So if someone changed the (english)
format string in the source code, suddenly none of the other catalogs would
work anymore for that message.  (It goes without saying that these are
still maintained manually; we don't have a message entry scanner.)  Symbols
don't ever need to change, so this was a maintenance choice.  I'm not set
on preserving this style, but at the time the obfuscation factor seemed
minor in constrast to reliability.

(Also, zenirc still uses obarrays, not proper hashtables, so we are already
paying a high symbol use price.  And preserving emacs 18 compatibility is
still a goal, so the authors would probably want to implement obarray-based
catalogs as a fallback method anyway.)

Argument order is also still a potential problem in zenirc and right now
some of the catalogs probably have awkward sentence construction just to
keep the parameter order the same in every language.  I have been
contemplating some kludges to address this, such allowing an optional
argument order list for each message entry in a given language's catalog.
But I seem to recall that the C library's printf library has some feature
for dealing with this already in the format specifier, e.g.

      printf ("%2$s is %1$s", "foo", "bar");
      =| bar is foo

and wondered if this would be worth adding this functionality to emacs's
message function as part of the basic functionality for i18n in elisp
packages.

>The drawback would be that lookup is slower.  But I think this won't
>matter much, because these operations are mostly for user output.
>
>A program that needs to use various message translations, and wants to
>run fast, could look them up once at the outset and then save the
>translations in local variables.  This would combine the advantages
>of both methods.

Given the relative infrequency of messages in irc (on the order of less
than 1/s most of the time, often there are minutes of idle time), this is a
non-problem for the program we're talking about at the moment.  I am more
concerned about preloading the entire contents of the message catalogs into
memory at once, rather than lazy-loading entries as they are used.

Even for an application that might produce a lot of output very quickly,
I'm not sure that the cost of looking up the catalog entry is
significantly higher than parsing the format string and converting
arguments.  Has anyone ever profiled this?