But why the use of gettext then?
Because it handles currency, date, numeric, text orientation, encoding, symbols, and true localization.
There is a HUGE difference between translation and localization. Translation by itself is pretty useless.
Localization, on the otherhand, means the program has all needed information so that it can adapt itself to handle its input and output in a fashion which is correct for some native language and cultural habits.
From the gettext docs: Very roughly said, when it comes to multi-lingual messages, internationalization is usually taken care of by programmers, and localization is usually taken care of by translators.
What I am talking about is using gettext for the internationalization so we can do precisely that.
By using gettext (or some similiar method) you handle all of this:
CODESETS
The codeset most commonly used through out the USA and most English speaking parts of the world is the ASCII codeset. However, there are many characters needed by various locales that are not found within this codeset. The 8-bit ISO 8859-1 code set has most of the special characters needed to handle the major European languages. However, in many cases, the ISO 8859-1 font is not adequate: it doesn't even handle the major European currency. Hence each locale will need to specify which codeset they need to use and will need to have the appropriate character handling routines to cope with the codeset.
CURRENCY
The symbols used vary from country to country as does the position used by the symbol. Software needs to be able to transparently display currency figures in the native mode for each locale.
DATES
The format of date varies between locales. For example, Christmas day in 1994 is written as 12/25/94 in the USA and as 25/12/94 in Australia. Other countries might use ISO 8061 dates, etc.
Time of the day may be noted as hh:mm, hh.mm, or otherwise. Some locales require time to be specified in 24-hour mode rather than as AM or PM. Further, the nature and yearly extent of the Daylight Saving correction vary widely between countries.
NUMBERS
Numbers can be represented differently in different locales. For example, the following numbers are all written correctly for their respective locales:
12,345.67 English
12.345,67 German
12345,67 French
1,2345.67 Asia
Some programs could go further and use different unit systems, like English units or Metric units, or even take into account variants about how numbers are spelled in full.
MESSAGES
The most obvious area is the language support within a locale. This is where gettext provides the means for developers and users to easily change the language that the software uses to communicate to the user.
Using SQL and a lookup table only solves the "Messages" aspect of translation and nothing else. Sure you could build routines to account for differences in numbers, text encoding, dates, etc., but at that point why wouldn't you just use gettext?
The only reason that this matters to me is that I work for a multinational company that needs to support about eight languages for their website. We already know that doing straight text translation does not work for us, as it doesn't meet the needs for the other aspects.
On the otherhand, as I've said before, I know nothing about translation, I only speak English ... so if someone has an easy way to solve these other issues, especially if it is simpler, I'm all about it. I just don't want to see us do down the road of "we just need a Spanish version of strings X and Y" and think we have true internationalization because that's only 25% of the actual solution.
MODX Staff
ops: 
☆ A M B ☆
MODX Staff
