Browse Prior Art Database

National Language Enablement Considerations

IP.com Disclosure Number: IPCOM000102699D
Original Publication Date: 1990-Dec-01
Included in the Prior Art Database: 2005-Mar-17
Document File: 5 page(s) / 208K

Publishing Venue

IBM

Related People

Chapman, RA: AUTHOR

Abstract

Developing a National Language Support* (NLS)-enabled product involves a very detailed design phase. During this time consideration needs to be given to screen definitions and presentations, expansion of static text, entry field text, and translatable text substitution, as well as code level string manipulations. Single and double byte consideration have been included. To be fully NLS compliant requires function that is beyond the scope of this article.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 29% of the total text.

National Language Enablement Considerations

       Developing a National Language Support* (NLS)-enabled
product involves a very detailed design phase.  During this time
consideration needs to be given to screen definitions and
presentations, expansion of static text, entry field text, and
translatable text substitution, as well as code level string
manipulations.  Single and double byte consideration have been
included.  To be fully NLS compliant requires function that is beyond
the scope of this article.

      This article contains a summarization of information gathered
during the development of such a product.  The recommendations
outlined have been derived from both technical and business related
perspectives.  They take certain OS/2* Presentation Manager*
environmental issues into consideration.  Other operating
environments may vary.
       .   Dynamic Text Field Lengths
           Text fields on user panels need to allow for
           expansion/contraction of user static text.
           Translation from English to German appears to
           require the greatest expansion.
           -    0 to 10 English characters should allow 200%
                expansion
           -    11 to 20 English characters should allow 100%
                expansion
           -    21 to 30 English characters should allow 80%
                expansion
           -    31 to 50 English characters should allow 60%
                expansion
           -    51 to 70 English characters should allow 40%
                expansion
           -    over 70 English characters should allow 30%
                expansion

      The major concern is that creating screens that look attractive
while allowing for expansion space is very difficult.  Dynamically
placing and stretching text fields on Presentation Manager screens is
expensive.  An alternative is to place the fields in columns that are
fixed in position and allow for expansion.  The drawback here is
excessive white space in the English version.

      Edit Fields All Edit fields should be defined as scrollable. It
is probably safe to set a fixed displayed length but the user must be
able to type beyond the displayed edit window, thus scrolling.

      Dynamic Pushbuttons and Other Window Classes These windows must
be dynamic in size (both width and height).  Most windows and/or
dialog boxes have numerous pushbuttons defined.  When expansion of
these buttons is taken into consideration often they will not fit on
the window.  We have compensated for this problem by allowing the
user to scroll pushbuttons left and right to see the buttons actually
displayed outside the windows border.  Another alternative is to
place all buttons in a scrollable list.  These are sug...