Japanese page

Internationalization of Window Managers

I am improving a few window managers so that text in Japanese (and other various languages) can be used for window titles, icon names, and so on.

Principles

I determined two principles. At first, the fruits must be contributed to the official version. I will not make Japanese version separate from the official version. The second principle is that all that users need should be configuration of locale. Don't design so that users have to configure each software (such as MultiByte option in ~/.foobar-rc file).

Principle 1: Contribute to the Official Version

There are many works which releases "Japanese (or other local) support patches" or "Japanesed (or other local) versions". Followings are the merits of this way of works:

test in Japanese (or other specific local) environment is enough,
a document in Japanese (or other language) is enough, and
detailed and delicate Japanese (or other local) support is possible.

On the other hand, there are following demerits:

it needs to catch up to the new version of the upstream,
since the upstream developers don't know the Japanesed (or localized) version, they may change the software in the way which conflicts with the Japanized (or other localized) version,
losing a chance to make upstream developers think about i18n,
various localized versions will be developed independently, which is "re-invention of a wheel", and
generally, "fork" is not a good mannar.

I don't think I can maintain the Japanized fork version forever. Also, I think that free software developers in the world should know about i18n problem. These are why I decided to send my patches to the upstream developers.

To make my patch be adoped by the upstream developer, the patch need a certain level of quality.

At first, other languages must not be sacrifised to achieve Japanese support. Most of my work are related to substituting XFontStruct-related functions [for example, XLoadQueryFont(), XDrawString()] by XFontSet-related functions [for example, XCreateFontSet(), XmbDrawString()]. However, XFontSet-related functions depend on assumptions that OS (or X Window System) support "locale" and users set LC_CTYPE locale properly. When locale is not set (i.e., the default behavior), ASCII is used. Most of 8-bit-character-code users in the world don't know about locale and of course they don't set LC_CTYPE locale. Even many developers of window managers think XFontSet-related functions are only for multibyte languages and are not 8-bit-clean. Of course the idea is wrong.




Thus, my patches were written so that they can be compilied even
when OS and X Window System don't support locale. Furthermore,
even on OS / X Window System which support locale, when users
don't set locale properly, my patches will use XFontStruct-related
functions. Some strict i18n people may think "Not setting locale
is a bad manner and softwares don't need to support such users".
However, I think such a "correct opinion" is be accepted by
real users in the world, and I compromised. 



Another difficulty is English. We need to prepare documents in English,
discuss with other developers in English, write comments in source
code in English, and so on. Nomenclature for variables and subroutines 
needs to use English (not Japanese or other languages).
Many Japanese developers strongly hesitate to use English.


Principle 2: Not Need Configuration for Each Software


Visit a bookstore in Japan and find Linux/BSD corner.
You can find several books related to configuration of
Japanese environment. In my opinion, it is a wrong situation.



Why such books are sold? It is because a user has to do many
configurations to use Japanese in Linux/BSD. If only one
configuration were enough, a book would not be needed.
Why many configurations are needed? One of the reason is that
each software requires its own configurations to use Japanese.



Ideally, a user needs to specify "Japanese" just once somewhere,
then all softwares should work in Japanese.



In case of window managers, specification of XFontSet mode and
fonts. In my patches, I made XFontSet mode is automatically chosen
when locale is properly set, as written above. I can imagine
another algorithm like: XFontSet mode is chosen when locale
starts with "ja", "ko", or "zh", 
like Sawfish before I sent
a patch. However, in future, UTF-8 will be widely used and it
is also multibyte (thus XFontSet mode is needed).



It is not very easy to specify fonts.
One of main purposes of window managers is to decolate windows
using some designs, i.e., idea of beauty. Thus, default font
is chosen to realize the developers' idea of design. However,
it is not realistic to list up many fonts for many langauges
as a default setting. Many developers of window managers don't
know about languages and fonts in the world. Even in future,
we cannot expect developers and designers will know that.



Many window manager develoers live in Latin-1 font languages
and they are not interested in other langauges. Thus, software
should have a mechanism to supplement fonts for other languages.



However, it sometimes occurs that Japanese (or other language) font
is not available which corresponds to specified latin-1 font.
Not sometimes. It very often occurs! (Imagine difficulty to
develop a font with thousands of characters [each of them consists
of many strokes] for Japanese while
a latin-1 font contains only about 200 characters.)
However, it is a bad choise not to display Japanese (or other language)
at all because of lack of a font of similar design. 



I took two kind of solutions. A simpler solutions is to add
",*" to a fontset parameter for XCreateFontSet()
function. This method ignores decoration or design completely,
but all languages can be displayed if any fonts are available.
Another solution is to search for a font which is as similar as
the specified font. This algorithm is complex and depends on 
developers' taste.


IceWM


When I checked IceWM, it had already been internationalized
using XFontSet. However, it needed to be activated by MultiByte
option in a configuration file. (For a while in past, the option was
activated as a default).



I modified so that users don't need to specify MultiByte option.
Also, I modified so that ",*" will be automatically added 
at the end of the font specification.



After that, I wrote a code to search for similar fonts, but it is
not adopted by IceWM.


Sawfish


Sawfish had already had an internationalization feature using XFontSet.
It was made so that XFontSet mode was activated when the locale begins
with "ja", "ko", or "zh".



The developers of Sawfish consider deeply on internationalization.
When I sent a patch to automatically activate XFontSet mode in case
the locale is appropriately configured, they tested my patch extensively
to gave me many suggestions. Thus the algorithm to automatically activate
XFontSet mode was improved as following:

 when setlocale(LC_CTYPE, "") returns NULL,
    XFontStruct mode will be used,
 
when setlocale() returns "C" or 
    "POSIX, XFontStruct mode will be used,
 
if XSupportsLocale() fails, XFontStruct mode will be used, and
 
otherwise XFontSet will be used.




Sawfish adopted an algorithm to search for a similar font for a specified font.



TWM


TWM is a part of XFree86 distribution and is expected to be a reference or a
standard, I thought it is very bad situation that TWM is not internationalized.



Since TWM is a part of XFree86 distribution, I don't need to consider a
possibility that XFontSet-related functions are not available. However,
TWM will need to support XFontSet mode and XFontStruct mode. Since I thought
TWM should be as simple as possible and I didn't introduced an algorithm
to search for a similar font. Also, I found a function to read a configuration 
file was not 8-bit-clean and I fixed that.



My patch will be adoped since XFree86 4.0.2.



CTWM


CTWM had already been internationalized by using XFontSet-related functions.
However, it was determined in compilation-time (Not run-time) which mode
(XFontStruct mode or XFontSet mode) will be used. In such case, developers
of Linux (or other OS) distributions will have to ignore half of the world.



First I sent a patch to add ",*" at the end of a parameter
to XCreateFontSet() function and it will be adopted in the
next version. Next, I sent a patch to automatically select XFontSet mode
or XFontStruct mode in run-time, but I have not got a reply.



Blackbox


When I checked Blackbox, it had not been internationalized using 
XFontSet-related functions. Thus, I sent a patch (XFontSet wrappere)
based on 
My
Linux Japanization to the Blackbox developers and found that 
they were developing internationalization features.
However, my algorithm to automatically activate XFontSet mode was adopted.



Since I thought a look and design is important in Blackbox,
I sent a patch to find a similar font and the patch will be adopted.


Window Maker


I found it is more difficult to internationalize Window Maker than
other window managers.
Main part of window manager and widget are separated. 
Also, several string-handling algorithms in Window Maker depend on
1 character equals to 1 byte.





  Tomohiro KUBOTA
  <debian at tmail dot plala dot or dot jp>