Stephen> I think that this is not the reason. Rather, since only the Stephen> menus and startup screen are translated, we simply never put Stephen> a lot of effort into getting translations. OK. But menus seems to be what can be translated without major work. Emacs seems like the file in app-defaults that is consulted. Maybe each package could provide its own translations for its Menes so that the translation could be provided in a more modular way. Either the build process could glue all files together and make a super Emacs file with all translations. Or each file in app-defaults could be consulted so that it would be resolved at run time? Stephen> Your effort won't be wasted as long as you know people will Stephen> use it. And it will provide a basis for further work even if Stephen> we change the implementation of localized messages. Process question: I now have an experimental version with Swedish menus. Should I post it to XEmacs-patches or shall I commit it to locale? I mean locale is in itself a bit experimental(?) so simply committing might make it easier for getting it reviewed? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> The build process can't do it. It has to be install time or Stephen> later. I'm not sure I want to make a revision to the install Stephen> process for this, but it's certainly a possibility. I was thinking of the build process of the packages. Something like make in the locale package would also traverse the other packages to find their app-defaults and copy their contents into the app-defaults file Emacs. Or some variation on that theme. Stephen> This would be more consistent. However it's not clear to me Stephen> how this might work, since there's only provision for the Stephen> global menubar to have resources read. It's not obvious how Stephen> packages would hook into this. Should we read resources for Stephen> all packages at startup? Or should we read them when the Stephen> package is loaded? Or what? First version could naively include all resources, for the current locale. When the number of packages with translations increase and we find that it really is a memory problem to have them all we could read them in when loading the package or maybe even only when the menu is defined. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Well, yes, but remember, the build process for many users Stephen> takes place on Norbert's machine, while the app-defaults file Stephen> is on the user's. It's not obvious to me that it's safe to Stephen> mess with the user's app-defaults file since under the Stephen> current situation that's the only one that will be read, so Stephen> local changes would have to be made there. I might have missed something here. I thought the app-defaults that is consulted is the one installed by the locale package? Stephen> If you're going to do a monolithic file, it has to include Stephen> all resources for the current file, and it's not going to be Stephen> a memory problem unless people have extremely restricted Stephen> systems. But how do you add the resources for a newly Stephen> installed package? You don't. It is the naive approach remember. ;-) You will either have to build it yourself, wait for Norberts next official release or install a pre-release version of locale to get the translation for a new or updated package. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Yes. The problem is coordinating that with any changes made Stephen> in other packages. Well, for the naive, simple, dumb, solution the coordination would be sort of done by the locale package. When it is built it will fetch all translations from all packages. Anything that happens after that will not be seen. But for the users of the official- or the pre-releases this will work!? Anyway the idea is only interesting if the better alternatives are hard to implement. I guess it ought to be an easy thing for instance to read in all files in the app-defaults folder, and not only the Emacs file. This would allow for each package to install its language files in app-defaults much in the same way as locale does for the core lisp. And the coordination will not be needed since it is resolved in runtime. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Since we don't have any such packages at this point I don't Stephen> think we should spend much more time on discussing it. Well I don't understand but never mind. Let's instead look at the practical side of it. Where should translations for non core XEmacs menus, like modes such as dired, gnus, vm go? Should we insert them in the app-defaults Emacs file until we find a better solution? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Are you planning to do such translations? Yes. Now when half of the my menus are in Swedish the remaining nontranslated really calls for action! Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta