Chapter 6. LOCALE technology

59

6.4 Unicode and LOCALE technology

UTF 8 is considered as the future encoding and many softwares are coming to support UTF 8.

Though some of these softwares implement UTF 8 directly, I recommend you to use LOCALE

technology to support UTF 8.

How this can be achieved? It is easy! If you are a developer of a software and your software has

already written using LOCALE technology, you don't have to do anything!

Using LOCALE technology benefits not only developers but also users. All a user has to do is set

locale environment properly. Otherwise, a user has to remember the method to use UTF 8 mode

for each software. Some softwares need

 u8

switch, other need X resource setting, other need

.foobarrc

file, other need a special environmental variable, other use UTF 8 for default. It is

nonsense!

Solaris has been already developed using this model. Please consult Unicode support in the So 

laris Operating Environment (

http://docs.sun.com/ab2/coll.651.1/SOLUNICOSUPPT

)

whitepapaer.

However, it is likely that some of upstream developers of softwares of which you are maintain 

ing a Debian package refuses to use

wchar_t

for some reasons, for example, that they are not

familiar with LOCALE programming, that they think it is troublesome, that they are not keen

on I18N, that it is much easier to modify the software to support UTF 8 than to modify it to use

wchar_t

, that the software must work even under non internationalized OS such as MS DOS,

and so on. Some developers may think that support of UTF 8 is sufficient for I18N.

4

Even in such

cases, you can rewrite such a software so that it checks

LC_*

and

LANG

environmental variables

to emulate the behavior of

setlocale(LC_ALL,   );

. You can also rewrite the software to

call

setlocale()

,

nl_langinfo()

, and

iconv()

so that the software supports all encodings

which the OS supports, as discussed later. Consult the discussion in the Groff mailing list on the

support of UTF 8 and locale specific encodings (

http://ffii.org/archive/mails/groff/

2000/Oct/0056.html

), mainly held by Werner LEMBERG, an experienced developer of GNU

roff, and Tomohiro KUBOTA, the author of this document.

6.5

nl_langinfo()

and

iconv()

Though ISO C defines extensive LOCALE related functions, you may want more extensive sup 

port. You may also want conversion between different encodings. There are C functions which

can be used for such purposes.

4

In such a case, do they think of abolishing support of 7bit or 8bit non multibyte encodings? If no, it may be

unfair that 8bit language speakers can use both UTF 8 and conventional (local) encodings while speakers of multibyte

languages, combining characters, and so on cannot use their popular locale encodings. I think such a software cannot

be called  internationalized .