International Ui Example

Continuation of a discussion in OoLacksMathArgument.

Objective: A non-trivial application must be customized for multiple languages.

Associated Issues and Challenges:

Assume an international character-set and a common string encoding (such as UTF-8), and associated fonts. No need to increase the challenge even further by introducing Big-5, explicit font management, and so on.

Also, International UI is a subset of all 'accessibility' issues. We aren't concerning ourselves with support for the blind or deaf or motor-function limited, etc.


Approach 1: DB-centric

Approach 1:

  Application
  ---------------
  ResourceID
  .
  Resource File (one for each language) Typo? This is not a DB
  ------------------
  ResourceID 
  Text

Approach 2:

  Table: translations
  -------------
  widgetRef
  languageRef
  transText

Approach 3:

  Table: translations
  -------------
  phraseID
  English
  Spanish
  Japanese
  Arabic
  Etc.....
  transNote

Another variation:

 Table: messages
 ---------------
 msgID   // could be number or mnemonic
 desc    // what the programmer wants the message to 'mean'
 .
 Table: Languages
 ----------------
 langID
 langDescript   // example: Spanish, French, English, etc.
 .
 Table: languageMessages
 -----------------------
 msgRef
 langRef
 msg

The reason "English" is in the Messages table instead of the languageMessages table is to serve as a description also. If you find this odd, then don't use it.

I think it useful: it can serve as a description by the programmer of what a message is intended to mean, and translators can still usefully translate it to English. In practice, translators need more than just a short-text English description to perform an intelligent translation. They need context, and this description might provide it. I hope you don't mind, but I modified the above to express this different view.


Approach 2: flat files

The text of every UI component is loaded from resource files. The original monolingual resource file is sent to translators. They provided equivalent text in different languages, each in its own resource file. Users pick which language they want and the app uses the appropriate resource file.


A very long discussion ensued. It boiled down to this:


A compromise variation got deleted somehow here. I also proposed using a DB to store the language strings, but generating code so that the app performs faster. In other words, the DB is a developer-side "language manager", but not necessarily the run-time source of the language strings. --top


Language Width Differences

In some languages the word/phrase equivalent to "Save" may be say 25 characters. Designing a UI to make room for the largest possible string in all common languages could be really messy. Even if the UI engine had auto-stretch features, it may be difficult to control screen width and/or auto-wrapping behavior. Computers have no esthetic sense. It's a sticky problem.

However, there's two things that could reduce the pain. First, have horizontally scalable text such that the aspect ratio changes for longer phrases. In other words, "squish fonts" to make the aspect narrower to force a fit.

And second, if there is still not enough space or the aspect adjustment above makes the text hard to read, then make sure mouse roll-overs are working to pop-up the full-sized description when needed. -t

Fixed-size, non-fluid, non-stretchy, brochure-style UIs haven't been considered good design for over a decade, but mobile devices of varying resolutions are forcing developers to adopt fluid, dynamic, automatic UI layout. Stop poking about in forms designers -- let the code do it dynamically. It's got a better understanding of layout aesthetics than you do, anyway.

Mobile devices often don't do anything sophisticated enough to test the limits. They are very MS-Wizard-like in their one-step-at-a-time UI's to change settings etc. While good enough for casual use, it's not sophisticated enough when user productivity matters, usually in the work-place. Related: CoordinateVersusNestedGui.

You're quibbling over the example, but missing the point. Coordinate-based GUIs are obsolete.

That topic explains and visually demonstrates why it's nice to have the option of both and different situations require different approaches. Computers lack esthetic sense and don't get things "right" in tight quarters. Maybe "tight quarters" is a design smell, but if the boss wants to cram as much as possible onto one screen, that's his/her prerogative. The picky and illogical people who pay us want things a certain way and don't want lectures on architecture purity or claims of flexibility 5 years down the road. They want fine control now. DilbertIsNoJoke. -t


See also: DoubleDispatchExample


CategoryInternationalization, CategoryExample


EditText of this page (last edited January 21, 2014) or FindPage with title or text search