Previous Up Next

Chapter 11  Localisation

11.1  Introduction

Currently, Config4* does not support localisation. In particular, error messages embedded in exceptions are hard-coded in English. Config4* would be more user-friendly for non-English speakers if such error messages could be provided in the language specified by the locale in effect.

11.2  One Possible Approach for Localisation

I do not have any experience of localising software applications. From the little I have read on the subject, I have formed the following (possibly incorrect) assumptions about how localisation might be introduced to Config4Cpp.

First, we need to (somehow) add Unicode support to Config4*. In particular, we need: (1) the ability to store a collection of strings in a Unicode encoding, that is, one of UTF-8, UTF-16 or UTF-32; and (2) the ability to transcode those strings into the character encoding of the current locale.

Second, we need a data store that contains parameterised error messages (written as Unicode strings) in multiple languages. If we provide Unicode support in Config4*, then it might be possible to use an embedded configuration file as the data store.1 As an example, an error messages configuration file might be in the format shown in Figure 11.1.

Figure 11.1: Hypothetical error messages localisation file
# Parameterised error messages in English
en {
  1 = "%%s1, line %%i1: expecting ’;’ near ’%%s2’";
  2 = "%%s1, line %%i1: expecting ’=’, ’?=’ or ’{’ near ’%%s2’";

# Parameterised error messages in French
fr {
  1 = "%%s1, ligne %%i1: j’attendais ’;’ près de ’%%s2’";
  2 = "%%s1, ligne %%i1: j’attendais ’=’, ’?=’ ou ’{’ près de ’%%s2’";
... # Scopes for other languages

The parameterised text for, say, error 2 in the current locale would be obtained as follows:

language = ...; # extract the language code from the locale
errMsg = cfg.lookupString(language, "2");

Then all the string place holders (such as "%s1" and "%s2") and all the integer place holders (such as "%i1") in the parameterised error message would be replaced with values from an array of strings and an array of integers. The resulting string could then be used as a localised error message when throwing an exception.

An interesting aspect of the above proposal is that Config4* would store localised messages in Config4* format. Unless care was taken, this might introduce a bootstrapping problem in building Config4*. Obviously, that is a drawback of the proposal. A benefit of the proposal is that Config4* would not rely on a third-party localisation library. Avoiding reliance on third-party libraries can keep down the memory requirements of Config4*.

Utilities such as config2cpp-nocheck or Config2JNoCheck (Section 3.6) could be used to embed the configuration file in the Config4* library.

Previous Up Next