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 .






footer




 

 

 

 

 Home | About Us | Network | Services | Support | FAQ | Control Panel | Order Online | Sitemap | Contact

indiana web hosting

 

Our partners: PHP: Hypertext Preprocessor Best Web Hosting Java Web Hosting Inexpensive Web Hosting  Jsp Web Hosting

Cheapest Web Hosting Jsp Hosting Cheap Hosting

Visionwebhosting.net Business web hosting division of Web Design Plus. All rights reserved