Mats Lidell writes:
>>>>> Stephen wrote:
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.
Of course. You asked why, which is relevant to what we may be able to
get to happen in the future. If you've already done some work, no
reason not to use it, and let the users tell us if they want more.
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
The build process can't do it. It has to be install time or later.
I'm not sure I want to make a revision to the install process for
this, but it's certainly a possibility.
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
This would be more consistent. However it's not clear to me how this
might work, since there's only provision for the global menubar to
have resources read. It's not obvious how packages would hook into
this. Should we read resources for all packages at startup? Or
should we read them when the package is loaded? Or what?
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?
locale is not experimental, it's been standard in the Mule package
distribution for years. As long as your change doesn't cause crashes
or data loss, which seems unlikely, and you watch the smoke test for
build glitches, if you can't think of a reason to wait, then you
should check it in.
XEmacs-Beta mailing list