On Thu, Mar 16, 2000 at 02:16:42PM +0900, Taketoshi Sano wrote: > > We can't just say "add 10 points if the window manager is > > internationalized" without telling the possible thick-headed American > > package maintainer how to determine whether it is or not. :) > > I have thought that users can judge if the specific software > is correctly internationalized or not, and they will file their > report on BTS if they find the wrong priorities. But your concern > may be reasonable. Well, what I want to do is have very clear guidelines so that we don't have any "bug terrorism". Violating policy is often interpreting as being a release-critical bug -- so if we put this into policy, I want to try to be very clear about what kinds of i18n problems are going to hold up a release, or cause a package to be removed from consideration for a release, and what kinds won't. > > One item would obviously be: > > + The window manager should use XmbDrawString() instead of XDrawString() > > for non-error/non-diagnostic text output. > > > > Please come up with more, if there are any, and I'd be happy to make a new > > policy proposal incorporating your suggestions. > > In fact, the true internationalization may require more than just replacing > XDrawString() with XmbDrawString(), but this is a good indicator as a start > point, I think. Yes, that's what I'm trying to get at. Obviously there's more to i18n than just replacing function calls, or everything would have been i18n'ed already. :) But since I have only a shallow understanding of i18n issues generally, and in implementing them in X window managers specifically, I wanted to request input on this issue. > # Anyway, users will file their report on that package if it can not be used. > > Just one thing: Error text output could be localized one (libc does have > localized error messages for such as "No such file or directory" or > "File exists". So excluding error output is not good in this case, I think. Yeah, but here's where we run into the specter of l10n again -- which I very strongly feel shouldn't be mandated by policy. Here's what I'm getting at -- if an X client has been internationalized, and it provides locale specific information to the window manager, the window manager needs to be able to deal with that. The XDrawString() vs. XmbDrawString() issue is a perfect example; I've *seen* the title of my Netscape window become total gibberish (in any language), because the window manager didn't use a multi-byte character aware function to render it -- if it did, I'd see proper Japanese glyphs (which I don't understand, either -- but I recognize them as human language rather than a machine-readable encoding method like Shift_JIS or EUC-JP). Error messages are another story. If the error messages come from outside the window manager, and are already localized, then the window manager shouldn't mangle them. I don't, however, think that the window manager should be compelled by Debian policy to have an internal message catalog for various languages. To sum up, what I'm saying is this: I think a Debian window manager policy should say that window managers should be given higher priority if they DON'T mangle localized information that they are intended to pass along to the user. And that is what I understand internationalization of computer software to mean -- it makes localization transparent and possible. -- G. Branden Robinson | Men use thought only to justify their Debian GNU/Linux | wrong doings, and speech only to conceal branden@ecn.purdue.edu | their thoughts. roger.ecn.purdue.edu/~branden/ | -- Voltaire
Attachment:
pgpsD06uy7DUe.pgp
Description: PGP signature