Browse Prior Art Database

A mechanism to detect string truncation problems in Graphical User Interfaces in products supporting multiple languages

IP.com Disclosure Number: IPCOM000125990D
Original Publication Date: 2005-Jun-27
Included in the Prior Art Database: 2005-Jun-27
Document File: 4 page(s) / 80K

Publishing Venue

IBM

Abstract

A mechanism to detect string truncation problems in Graphical User Interfaces (GUI) in products supporting multiple languages

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 36% of the total text.

Page 1 of 4

A mechanism to detect string truncation problems in Graphical User Interfaces in products supporting multiple languages

With the global nature of the economy, it is inevitable that software products are internationalized. Most of the products developed by the majority of the software vendors support multiple languages. In GUI based products, all the configuration panels and the display elements are translated into many international languages. One of the main problems is to make sure the strings used in static labels are truncated in the dialogs in different languages. The reason is due to the difference in the length of such strings when translated from one language to another. Also, the different in the way fonts are used across languages.

Software process for translatable strings and the problem of truncation : Textual elements, such as status messages and the GUI labels, are usually not hard coded into the source code. Instead they are stored outside the source code and retrieved dynamically during run-time by the code. The text strings are stored externally in various forms (a resource DLL (Dynamically Linked Library), message catalogs, resource bundle, class files , property files, databases, etc). For the discussion, it is assumed strings are stored in message files. Each string in a message file is identified by a unique Identifier (usually it is just an index of the strings in a message file) and let's call it a StringID.

During GUI development, the developer assigns a StringID to each textual element in the GUI panels. He/she creates the message file with the actual English strings. He/she typically writes code where the message string is loaded from the message file based on the current locale setting. For example, LoadString(MessageFile, StringID, String);

The developer completes the Functional Verification Testing by testing the GUI panels with English locale and English message files. The English message source files are then shipped to various translation centers and are translated into the respective languages. Then, the message source files are compiled to create the appropriate binary files (catalogs, resource DLLs) and very late in the development cycle, (typically one of the last phases) the Translation Verification Testing (TVT) occurs where all the language testers test the product.

One of the most common problems reported during TVT is that the strings used in the static labels are truncated in the dialogs and display panels. A string in English becomes lengthier when it gets translated into other languages. The original English developer does not realize this and sizes the static label control to the size of the English text. He/she bases the display aesthetics of the dialog based on the English text. When the translation tester reports of the problem, it is too late in the cycle to make major changes to the GUI panels. Typical resolution to these problems is a band-aid fix to stretch the dialog and the con...