- Reasons why date/time formatting strings need to be also externalized
and localized as like translated messages:
Each culture has its own format, structure and ordering in date and time
format components. For instance, in Asian locales, AM/PM string will usually
appear before hour and minute digits and century number will appear as the first component of a date/time string. On the other hand, in
Western
European countries, AM/PM string usually appears after hour and minute
digits and century number also appear as the last component of a date/time
string usually.
Due to such differences, if multiple date/time formatting conversion
specifications are used to comprise a single date/time string such as
"%a %b %e %T %Z %Y" and not allowed to be localized, in many cases,
the formatted date/time string from
such format string would not be really
acceptable or correct for certain cultures.
For instance, the above format string will give the following output for American English, Japanese, Simplified Chinese and French locales, respectively:
Tue Oct 19 20:16:05 EDT 2004
火 10月 19 20:23:31 EDT 2004
二 10月 19 20:23:14 EDT 2004
mar oct 19 20:17:53 EDT 2004
while the first one would be acceptable for American English locale
users, for other locales, more culturally correct and acceptable ones
would be:
2004年10月19日 (火) 20時19分20秒 EDT
2004年10月19日 星期二 20时22分55秒 EDT
mardi, 19 octobre 2004, 20:18:34 EDT
where differences
are rather obvious.
For this reason, it is also needed to externalize
such date/time format strings
as localizable items so that each locale can choose to translate and
supply translated files that will be dynamically loaded for the locale of
the program in execution.
- How to then internationalize such date/time formatting string:
We have a function called dcgettext(3C) that we can specify not only message file domain name and message id but also locale category.
And thus by specifying such as LC_TIME as the locale category input argument for the function, one can specify to the function which mo file should be picked up from:
(void) cftime(time_buf,
dcgettext(mydomain, "%a %b %e %T %Z %Y",
LC_TIME),
&st.st_mtime)
printf(gettext("File last modified at:
%s\n"), time_buf);
Once the date/time internationalization is done as like the above, people can extract the message Portable Object (PO) files, translate, convert it to a Message Object (MO) file and then place the MO file under
path/share/lib/locale/<locale>/LC_TIME/ or
path/lib/locale/<locale>/LC_TIME/ depending on your platform where the "path" is the top directory for your software, e.g., /usr/.
Note: Sometimes, it is also acceptable to include such
date/time
formatting string to a LC_MESSAGES category's Portable Object
(PO)
file but that is not always recommended. Sometimes,
externalizing such date/format strings in a resource file would be also
acceptable.
- What else need to be externalized?
Usually any kind of date/time related strings need to be externalized so
that each localizer will decide if any of the externalized strings
are needed to be translated and/or changed for their locales.
Accompanying comments with each msgid would be also a very good
idea.
|
|
Print-friendly Version
