[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: priority of x-window-manager

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

Reply to: