Re: Accelerator I18N [was: I don't wont the f* underlinings ...]

IMHO more useful than a :tag keyword would be some way to identify menu items that will prompt for an argument and automatically generate the trailing "...". (I'd like to get rid of all those "XlwMenu.mode.labelString" - "XlwMenu.mode___.labelString" pairs.) Don't see how to do it sensibly offhand though. Ben> I did mention about the :tag keyword to menu items that I'm Ben> planning on adding, right? Indexing first by :tag and then Ben> by the menu item name would help things out alot, IMHO. Ben> e.g. ":tag mule" but I can rename the item anything I want. Ben> If we tried to enforce a policy of requiring :tags and Ben> created a standard for them, it would give a lot more freedom Ben> to changes in the English names. I don't see that this addresses the problem. If it solves a problem you have, fine, do it, but this is just a clumsy way of implementing catgets from my point of view. Yes, it handles the introduction and fixing of typos (but note that changes of whitespace, punctuation except periods, and in particular embedded accelerators, are already ignored), but it doesn't do anything for the structure problem, which is the real issue. Eg, you blew away the apps menu, and hid most of the apps two levels down (typically in Tools | Internet). Tags are not going to be help for that. And note that we don't want to "give freedom" to change English names by disconnecting them from the translations. Remember that translators are generally going to be working in "batch mode" from long lists of labels, _not_ looking at the code. If we're lucky, they may actually look at the real menus while translating. If a label changes, the translator _must_ have a look at it to see if the semantics have changed and demand a change in translation. As for standards, the gettext people have thought a _lot_ about this. Seems to me that the sensible standard is (defun auto-generate-:tag-to-keep-ben&steve-happy () (interactive) (let ((label (scarf-string-around-point))) (open-line) (forward-line 1) (indent-according-to-mode) (insert ":tag " label))) Letting people generate tags themselves will create a big problem of collisions. And if you're thinking about a sort of double-hashing scheme, uh-uh. "Who knows what evil...." The current string should get priority, as that is most likely to generate semantically correct links. Then try the :tag as a backup. But using "category" tags (like "mule") then trying to look up a string isn't going to be feasible in the current architecture as far as I can see, nor in GNU gettext (unless you're willing to accept an absurd proliferation of gettext domains). And you want to bind strings like "Mode Hook..." (which appears something like 30 times in the menus) just once. A full RDBMS is a bit heavyweight for this purpose don't you think? (I plan to use PostgreSQL to organize the translations, BTW. After hand-pruning, sample.XlwmenuResourceConversions has 1691 individual resources, too many for a flat file. And this will make eventual conversion to gettext or whatever---X resources are fine for X IMO but one can't be an X bigot anymore...---much easier. Proposal forthcoming after M17N/2000.) I don't really like the idea of :tag (for i18n purposes) at all; but if you want to implement it, they should be optional (for i18n purposes) and people who edit a menu label for typos should apply `auto-generate-:tag-to-keep-ben&steve-happy' _before_ making the change so as to keep the translation link. (There's still the problem of what to do in case of an existing :tag, pretty intractable I think.) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."