Gabor Hojtsy wrote:
Earnie Boyd wrote:
Earnie, how would that SQL table work for translations? Different languages need very different suffixes. I don't see what table structure you envision here.
Chris was looking for "simple" and and realized his needs are "English-centric" but was wanting some way to possibly support simple translation.
int|locale|string 1|en|st 2|en|nd
So now he creates a function to look for the passed int value and locale and appends the suffix or some administrated set default. No it doesn't fit all scenarios.
Frankly, I would suggest using t('first'), t('second'), etc instead of the lazy symbols.
Yes, the problem with the above table that it is hardly (if at all) fits into the gettext based translation toolset translators are using. Yeah, gettext is the wrong tool for this this job. A "locale" library, or a numerical/calendaric library is what needs to get used here. The whole concept of doing ordinal numbers by tacking on "st", "nd" is too specific to English to practically handle any other way.
For a really good explanation of some of the reasons why this is so, it's worth reading this tutorial from Sun: http://java.sun.com/docs/books/tutorial/i18n/format/index.html While the APIs are Java specific, the issues apply to any kind of coding you want to work for more than one human language or script.
Gabor