Hrvoje> One's desire to have things translated to his tongue Hrvoje> should not reduce the developer's freedom to change the Hrvoje> program. Gratuitous spelling changes in menu items will "unhook" the translation (see lwlib/xlwmenu.c:massage_resource_name() for exactly which ones). Shouldn't we restrict freedom at least that much? Oh, by the way. I just generated the XlwmenuResourceConversions file: bash-2.03$ wc sample.XlwmenuResourceConversions 10930 29547 588026 sample.XlwmenuResourceConversions Approximately 5,465 translations. Coming soon[1], to an xemacs-patches archive near you! I'm looking forward to seeing the Croatian version for the hr locale. :-) Hrvoje> That's your opinion. I say otherwise. Hrvoje> By your standards, nothing UI-wise in XEmacs would ever Hrvoje> change, because there's always a possibility that Hrvoje> _someone_ in _some_ language would misunderstand/misparse Hrvoje> _something_. I can't hope to disprove that claim. You needn't bother, because I didn't make it. All I ask is that _discussion_ take place. This serves to (1) warn the translators that they are about to get a ton of hate mail (2) give them a chance to kick up a fuss and (3) maybe cause developers of good will to rethink some planned changes where appropriate. I don't expect that Ben's current changes would have been blocked or even much delayed, drastic as they are. They're needed, including some parts that I will disable in my personal setup as soon as possible. But it is part of my job to kick up a fuss when I18N considerations are completely ignored. Hrvoje> What I do claim is that _English_ menus are written for Hrvoje> people who understand _English_. Croatians, Japanese, Well, your claim is incorrect. Under the current architecture, and in GNU gettext as well, the menu translations are indexed by the English menu. The English menus determine the menu organization for _everybody_, whether they use English menus or not. And typos in the menu items (eg, when adding accelerators) are significant for this purpose, too. Hrvoje> Thai, etc. without proper knowledge of English will fail Hrvoje> to understand them. Well, that's what translations are Hrvoje> for. If that means "fuck I18N" in your book, then you Hrvoje> have a pretty weird notion of I18N. So, yes, changing the English menu without understanding how that impacts the menus in other languages means "fuck I18N" in my book. If you want to change to using catgets, then the English menu no longer has a central role in I18N. But nobody wants that; that would nearly guarantee that the menus would never ever change. :^) Hrvoje> Uh, and the Japanese better get used to Internet not being Hrvoje> IE and Netscape. It's for their own good. :-) The concept of the Internet and the word インターネット are two different things. Unfortunately, the mass media here have preempted the latter to mean "using a Web browser." Footnotes: [1] I'm gonna clean out the duplicates first. - 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."

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