kap121@ztivax.UUCP (Thomas Oeser) (02/15/90)
Hi there, looking at the documentation of X11R4 I found some surprising lines talking about application defaults depending on the current setting of $LANG. I want to start (again ?) a discussion about Language dependent application defaults. Here some reasons, why I believe we should avoid (or event don't offer) this functionality: 1) For the case that only button labels or other text strings differ, this should be done within the program using catgets() and explicitely setting the appropriate resource of the corresponding widget; 2) Other language dependent stuff (e.g., number of entries, other values, etc.) can also be set in message files using catgets() and e.g. sscanf(); 3) more ? The general issue should be to minimze the number of (language dependent) files that are necessary to run an application (simplifies maintenance of resulting products!). NOTE - In the case of catgets() it is already possible to run without any additional files, when the fallback strings in catgets() are properly set. We should try to create X applications (using Athena, Motif or other widget sets) that are able to startup even when no application defaults are provided. Thomas Oeser ------------------------------------------------------------------------------ ARPA: kap121@ztivax.siemens.com UUCP: kap121@ztivax.uucp (may work only in Europe...) Postal mail: Siemens AG, DI AP 313, Otto-Hahn-Ring 6, P.O. Box 830951, D-8000 Munich 83, West Germany Phone: + 49 (89) 636-47537 FAX: + 49 (89) 636-41477 Disclaimer: The opinions expressed are my own, and should not be attributed to anyone else living or dead. ------------------------------------------------------------------------------
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (02/15/90)
> I want to start (again ?) a discussion about Language dependent application > defaults. Here some reasons, why I believe we should avoid (or event don't > offer) this functionality: > 1) For the case that only button labels or other text strings differ, > this should be done within the program using catgets() and > explicitely setting the appropriate resource of the corresponding > widget; Wouldn't this require recompilation to add a new language? The app-defaults solution has the advantage of allowing the appliction to be internationalized w/o modifing the binary. This separates the programmer from the language specialist. Give how complex this stuff is becoming any separation of tasks such as this would seem to be well worth a bit of extra configuration headaches. Spend the extra time working on an install script that does all the right things. This is not to say that we have found the final answer, just that the current app-defaults technique may not be as bad as you think. Localization is a hard problem. You don't have to use the solutions proposed by the toolkit, but they are there if you want them. If you want to hard code everything into you application you can certainly do so. Of course, I would never buy your product if you did that, but that's my choice :-) > We should try to create X applications (using Athena, Motif or other widget > sets) that are able to startup even when no application defaults are provided. I disagree. I see no need to have the application "work correctly" with no application defaults. I consider the app-defaults file just as much a part of the application as the executable, the help file, or some other data file. That is not to say that a well written application should fail silently when no app-defaults file is present. I think that the behavior of the R4 xman is perfectly acceptable. If no app-defaults file is found then it puts up a message saying that it couldn't find the app-defaults, and asks the user if he would like to quit. Part of the application is missing. Since the application has notified the user of this it has fulfilled its responsibility. I see no reason to duplicate the entire app-defaults file in the text space of the applications binary. I should note that there are a certain set of applications that will need to run in the absence of app-defaults. These are things like a file system recovery tool. If the file system is corrupted you really can't count on finding that app-defaults file :-) Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213
erik@srava.sra.co.jp (Erik M. van der Poel) (02/16/90)
In article <898@ztivax.UUCP> kap121@ztivax.UUCP (Thomas Oeser) writes: > NOTE - In the case of catgets() it is already possible to run > without any additional files, when the fallback strings in catgets() > are properly set. NOTE - In the case of XtAppInitialize() it is already possible to run without any additional files, when the fallback strings in same are properly set. :-) In fact, this is what Chris uses in xman to be able to tell the user that no app-defaults file was found. But let's get down to the point here. The X/Open catgets catalogues are only for multilingual text, while app-defaults files are for all sorts of resources including e.g. border width. So I suppose what you are trying to say is that we should keep language-dependent files in one place, specified by the environment variable NLSPATH. We could achieve this by keeping only language-independent files under /usr/lib/X11/app-defaults. But I imagine that the Xt people decided to put language-dependent files under the app-defaults directory too because X/Open is not the only standard out there. In AT&T's MNLS, for example, the internationalized files are under /lib/locale. Somebody correct me if I'm wrong. What about POSIX? And others? Basically, what I'm trying to say is that not everyone has catgets().
erik@srava.sra.co.jp (Erik M. van der Poel) (02/16/90)
In article <9002151430.AA11687@expo.lcs.mit.edu> kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) writes: > The app-defaults solution has the advantage of allowing the appliction > to be internationalized w/o modifing the binary. This separates the > programmer from the language specialist. Give how complex this stuff > is becoming any separation of tasks such as this would seem to be well > worth a bit of extra configuration headaches. Spend the extra time > working on an install script that does all the right things. > > This is not to say that we have found the final answer, just that the > current app-defaults technique may not be as bad as you think. > Localization is a hard problem. Yes, it certainly is difficult. It would be nice if we could separate the task of the programmer from that of the language specialist, but unfortunately it is not easy to make a clean separation. Let's take the Japanese language as an example. It takes 16 bits to express each character because there are thousands of them. Fortunately, Xlib provides XDrawText16() for such character sets, and the R4 distribution even contains at least one Japanese font (mit/fonts/bdf/misc/k14.bdf). Clearly, the Xlib-level programmer needs to distinguish between XDrawText() and XDrawText16(). It should be possible for the program to find out which language the user has chosen by looking up a certain environment variable. Of course the application writer would not have to worry about these things if they were neatly packaged in widgets. What we need to do is to migrate towards conventions where text is read from app-defaults files into ANSI C wide character wchar_t strings, for example. Several organizations are working on standards in this area. Perhaps some of those individuals would like to comment? (What timing! :-) - -- Erik M. van der Poel erik@sra.co.jp (Japan) SRA, 1-1-1 Hirakawa-cho, Chiyoda-ku erik%sra.co.jp@uunet.uu.net (USA) Tokyo 102 Japan. TEL +81-3-234-2692 erik%sra.co.jp@mcvax.uucp (Europe)
nazgul@alphalpha.com (Kee Hinckley) (02/17/90)
In article <898@ztivax.UUCP> kap121@ztivax.UUCP (Thomas Oeser) writes: >looking at the documentation of X11R4 I found some surprising lines talking >about application defaults depending on the current setting of $LANG. ... > 1) For the case that only button labels or other text strings differ, > this should be done within the program using catgets() and > explicitely setting the appropriate resource of the corresponding > widget; How do you deal with size changes if you are trying to make the interface esthetically pleasing (sure, I could just let things resize automatically, but English->German is a pretty big growth). Also, I need to be able to support multiple languages simultaneously. I can do this using compound strings, but I don't believe that the catgets functionality will give me what I want. (BTW. Is there a PD implementation somewhere? A number of the machines I'm porting to don't support it.) > 2) Other language dependent stuff (e.g., number of entries, other > values, etc.) can also be set in message files using catgets() and > e.g. sscanf(); What about symbols and icons? What about reversing my interface when the language goes right to left? How do I use catgets() if I'm using a user interface language like Motif's UIL? I kind of feel that the catalog stuff came along and solved the text problem just about the time that simple text was no longer the only problem. >The general issue should be to minimze the number of (language dependent) files >that are necessary to run an application (simplifies maintenance of resulting >products!). Absolutely, but that requires a solution that provides all of the necessary functionality. I don't currently see that. >We should try to create X applications (using Athena, Motif or other widget >sets) that are able to startup even when no application defaults are provided. Definitely. -kee -- +-----------------------------------------------------------------------------+ | Alphalpha Software, Inc. | Voice/Fax: 617/646-7703 | Home: 617/641-3805 | | 148 Scituate St. | Smart fax, dial number. | BBS: 617/641-3722 | | Arlington, MA 02174 | Dumb fax, dial number, | | | nazgul@alphalpha.com | wait for ring, press 3. | BBS line is still dead | +-----------------------------------------------------------------------------+
asente@decwrl.dec.com (Paul Asente) (02/17/90)
In article <3890@srava.sra.co.jp> erik@sra.co.jp (Erik M. van der Poel) writes:
<But let's get down to the point here. The X/Open catgets catalogues
<are only for multilingual text, while app-defaults files are for all
<sorts of resources including e.g. border width. So I suppose what you
<are trying to say is that we should keep language-dependent files in
<one place, specified by the environment variable NLSPATH. We could
<achieve this by keeping only language-independent files under
</usr/lib/X11/app-defaults. But I imagine that the Xt people decided to
<put language-dependent files under the app-defaults directory too
<because X/Open is not the only standard out there. In AT&T's MNLS, for
<example, the internationalized files are under /lib/locale. Somebody
<correct me if I'm wrong. What about POSIX? And others?
Close, but there's more to it. You really need to customize more
resources than just strings (fonts, widget sizes, printing direction...)
The X/Open routines were adequate for simple applications, but more is
needed for window applications than just changing the text string.
-paul asente
asente@decwrl.dec.com decwrl!asenteerik@sravd.sra.JUNET (Erik M. van der Poel) (02/17/90)
In article <3890@srava.sra.co.jp> I write: <But let's get down to the point here. The X/Open catgets catalogues <are only for multilingual text, while app-defaults files are for all <sorts of resources including e.g. border width. So I suppose what you <are trying to say is that we should keep language-dependent files in <one place, specified by the environment variable NLSPATH. We could <achieve this by keeping only language-independent files under </usr/lib/X11/app-defaults. But I imagine that the Xt people decided to <put language-dependent files under the app-defaults directory too <because X/Open is not the only standard out there. In AT&T's MNLS, for <example, the internationalized files are under /lib/locale. Somebody <correct me if I'm wrong. What about POSIX? And others? In article <2803@bacchus.dec.com> asente@decwrl.dec.com (Paul Asente) writes: > Close, but there's more to it. Yes, you're right, there's a lot more to it. What we've discussed so far is just the tip of the iceberg. And what follows won't get us much further either, but I want to continue the discussion... > You really need to customize more resources than just strings (fonts, Here in Japan, the X applications that are used daily (terminal emulators, editors, etc) usually use 2 fonts: font (for English) and kanjiFont (for Japanese). I suppose the Chinese would also want to have 2 fonts, while the Europeans could probably get by with one font, using 8-bit characters (umlaut, etc). So the number of fonts depends on the type of text. This area needs standardization. > widget sizes, Widget sizes? As in width and height in pixels? I have seen several programs that specify sizes of widgets that contain text, and the result is that the text gets truncated on displays that have very small dots. Users on such displays tend to choose fonts with many dots for legibility. Application programmers should not specify the sizes of such widgets. Instead, they should let the user choose a font and let the widget choose it's own `best' size. After that the programmer can adjust the widgets so that, for example, all the buttons are the same size. Better yet, the programmer could throw a composite widget around the buttons so that they are automatically aligned. (This message is not directed at you, Paul. :-) > printing direction...) There is some support for this in X already: a negative character width causes the next character to be printed to the left of the current character. Vertical printing is not directly supported, though. Top-to-bottom printing could be achieved by drawing the text one character at a time, in a vertical fashion. So one would need resources to specify vertical printing. Erik M. van der Poel erik@sra.co.jp (Japan) SRA, 1-1-1 Hirakawa-cho, Chiyoda-ku erik%sra.co.jp@uunet.uu.net (USA) Tokyo 102 Japan. TEL +81-3-234-2692 erik%sra.co.jp@mcvax.uucp (Europe)
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (02/20/90)
From: Thomas Oeser
The general issue should be to minimze the number of (language dependent)
files that are necessary to run an application
The use of catgets does not reduce the number of files (compared with using
X resource files), it merely puts them in a different place.
From: Erik M. van der Poel
Basically, what I'm trying to say is that not everyone has catgets().
As far as I know, the X/Open messaging system has not yet been accepted by the
formal standards bodies (e.g. ANSI X3J11 (C) or IEEE 1003 (POSIX)).
From: Erik M. van der Poel
It would be nice if we could separate the task of the programmer from that
of the language specialist, but unfortunately it is not easy to make a
clean separation.
X Consortium folk believe it is generally quite possible.
Clearly, the Xlib-level programmer needs
to distinguish between XDrawText() and XDrawText16().
Wrong. We will be much better off if the Xlib programmer does not have to
distinguish. A basic goal of internationalization work is that the programmer
should not need specific knowledge of the language/culture in use. This
includes details about the encoding of strings, and the mapping to fonts.
It should be possible for the program to find out which language the user
has chosen by looking up a certain environment variable.
Well, setlocale() (see the ANSI C standard or X/Open's XPG) is a bit more
complicated than this. Yes, the program can find this information out, but
in general it shouldn't need to know.
Of course the application writer would not have to worry about these things
if they were neatly packaged in widgets.
The widget writer shouldn't have to worry very much either.
What we need to do is to migrate towards conventions where text is
read from app-defaults files into ANSI C wide character wchar_t
strings, for example.
It need not be wchar_t, it could remain multi-byte strings. The particular
choice of representation (multi-byte vs. wchar_t) is a space/time tradeoff.
Both forms of interface are probably required. What is essential is that
X provide sufficient abstractions so that the programmer need not be concerned
with language/culture details; that is, extending the "locale" concept to
X specifics.
Several organizations are working on standards in this area.
Perhaps some of those individuals would like to comment?
The X Consortium is very active in the area of internationalization. It is
probably the most active discussion group we have at present. For example, I
just returned from chairing a 2.5 day Consortium meeting in Tokyo on the
subject. We are working not just on resource files, but also on keyboard
input and text display, not just at the Xt level, but at the Xlib level. We
have reasonable representation from and interaction with people working on
internationalization in X/Open, OSF, UI, etc. "Harmony" with the existing ANSI
C standard and ongoing work in POSIX is an important aspect of our work. We
hope to have specifications out for public review in a few months.kap121@ztivax.UUCP (Thomas Oeser) (02/21/90)
in Article 13142 comp.windows.x Erik M. van der Poel writes > > printing direction...) > > There is some support for this in X already: a negative character > width causes the next character to be printed to the left of the > current character. Vertical printing is not directly supported, > though. Top-to-bottom printing could be achieved by drawing the text > one character at a time, in a vertical fashion. So one would need > resources to specify vertical printing. > The writing direction is proposed to be a property of the font (see ISO 9541-1, Information processing - Text and office systems - Font Information Interchange - Part 1: Architecture). Since the bdf format contains already a lot of this stuff, things like writing direction may be included, too (and recognized by the server...). But apart of this discussion, I agree that choosing the font that supports the language dependent set of glyphs, writing direction etc. is n o t supported by catgets() (or other functions from this area). BTW, this is still an open issue in the standardazations community to specify a complete chain from character encoding to character meaning, e.g. 0x31 is a "uppercase A" in the case of ISO 8859-1, and from the character meaning to a particular glyph identifier in a font representing that meaning. Thomas Oeser ------------------------------------------------------------------------------ ARPA: kap121@ztivax.siemens.com UUCP: kap121@ztivax.uucp (may work only in Europe...) Postal mail: Siemens AG, DI AP 313, Otto-Hahn-Ring 6, P.O. Box 830951, D-8000 Munich 83, West Germany Phone: + 49 (89) 636-47537 FAX: + 49 (89) 636-41477 Disclaimer: The opinions expressed are my own, and should not be attributed to anyone else living or dead. ------------------------------------------------------------------------------