On debian-users@debian.or.jp, some problem was reported (in Japanese).

The circumstances are:

• locale is set as LANG=ja_JP.EUC-JP
• some X applications, such as tgif, put resource files under /etc/X11/ja_JP.eucJP/app-defaults/
• traditionally, we've used ja_JP.eucJP instead of ja_JP.EUC-JP for long time (since X11R4 or X11R5?)
• however, glibc normalizes locale name so that canonical form of ja_JP.eucJP would be ja_JP.EUC-JP. So, both ja_JP.eucJP and ja_JP.EUC-JP are considered as equivalent locale, that is, language is japanese (ja), territory is Japan (JP) and encoding is EUC-JP.
• Xt will load resource files based on XFILESEARCHPATH, in which, some templates, such as %L, are used (see X(7x)). Xt just uses locale name for %L without nomalization that is done by glibc.

Thus, when user set locale as LANG=ja_JP.EUC-JP, resource files under /etc/X11/ja_JP.eucJP/app-defaults/ are not used. Some application (for example tgif) depends on resources to localize so it won't works properly.

To workaround this problem:

• the most easiest way is that use ja_JP.eucJP instead of ja_JP.EUC-JP.
• symlink /etc/X11/ja_JP.EUC-JP to /etc/X11/ja_JP.eucJP
• it is not good idea to put japanese resource file under /etc/X11/ja or /etc/X11/ja_JP, because resource files would depend on its encoding. (it would be differ between ja_JP.EUC-JP and ja_JP.UTF-8).
• the best solution is to fix Xt to normalize locale name as done in glibc and/or encoding conversion as done in gettext(3). However, it's not so easy to modify do this before sarge...
• or, fix application not to use resources for localization. I think it's legacy way and modern way is gettext(3).