NivaarExam PrepOfficial exam papers ↗

19-Soft-B2 User Interface · May 2015

Question 8 of 14: Internationalization and Localization of an Existing GUI

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

National Exams, May 2015 — 04-Soft-B2, User Interface (closed book, 3 hours). Part A: answer any FIVE of the NINE questions (10 marks each); Part B: answer ALL FIVE questions (10 marks each), all based on the same case study — Happy Medical Clinic, a Toronto medical clinic switching from paper-based practice to an electronic health record (EHR) system purchased from VisualEHR Inc., an off-the-shelf vendor willing to customize the product to the clinic's needs. Most questions call for essay-format answers; clarity and organisation count. This solution answers all fourteen questions as a full study resource.

Reference texts. Rogers, Sharp & Preece, Interaction Design: Beyond Human-Computer Interaction, 5th ed., Ch. 1–3 (interaction design, cognitive aspects, mental models), Ch. 9–10 (prototyping, personas), Ch. 11–12 (data gathering, requirements), Ch. 15–16 (evaluation, lab vs. field studies); Nielsen, Usability Engineering, Ch. 4–6 (usability heuristics, iterative design, usability testing); Shneiderman, Designing the User Interface, 6th ed., Ch. 2 (guidelines, principles), Ch. 12 (internationalization); Norman, The Design of Everyday Things, Ch. 1–4 (visibility, affordances, feedback, conceptual models).

Question 8: Internationalization and Localization of an Existing GUI (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Five steps/actions to add internationalization (i18n) and localization (l10n) support:

  1. Externalize all user-visible strings. Move every label, message, menu item and error string out of the source code into external resource files (one per target locale), replacing hard-coded text with resource-key lookups — this is the foundational step, since strings baked directly into code cannot be translated without recompiling and re-testing the entire application.
  2. Design layouts to accommodate variable text length and direction. Translated strings can be 30–200% longer or shorter than the English original (German labels are often much longer; some Asian-language labels much shorter), and some target languages (Arabic, Hebrew) are read right-to-left; the UI's controls, dialog boxes and layout containers need to resize/reflow rather than truncate or overlap, and the layout engine must support mirroring for RTL locales.
  3. Use locale-aware formatting for dates, numbers, currency and units. Replace hard-coded date/number/currency formats (e.g. MM/DD/YYYY, "$" and "," as the decimal/thousands separators) with the operating system's locale-aware formatting APIs, so a French-Canadian user sees dates and decimals in their expected convention automatically.
  4. Support locale-appropriate character sets, sorting and input. Ensure the application and its data storage use Unicode throughout (not a single-byte code page that cannot represent accented or non-Latin characters), that text sorting/collation follows the target locale's rules, and that any text-entry fields correctly accept the input methods (e.g. accented characters, IMEs) needed by target-locale keyboards.
  5. Establish a translation and localization QA process. Engage professional translators (not machine translation alone) for each target locale, and add a dedicated localization testing pass — pseudo-localization testing early (to catch hard-coded strings and layout truncation before real translations exist) and full linguistic/functional testing with each real translated build — so that i18n/l10n defects are caught before release rather than discovered by customers.