Show your support for Zikula! Sign up at Github account and watch the Core project!
Zikula and i18n
i18n means 'internationalisation' and Zikula is in dire need of it! Starting with Zikula 1.2.0 we have tried to make some effort to cope with the issues presented by internationalised websites. We are presented with all manner of problems, from different date formats to different ways to write numbers.
One of the worse problems is with processing numbers. 1.008 in the UK is a decimal point, but in Germany it's one thousand and eight! In Zikula 1.2.0 we have introduced native locale processing for reason I'll explain:
All language packs now have a locale.ini file which defines locale settings. This is because PHP's setlocale() command relies on the server being configured with that locale data - which it mostly isn't. For this reason we have our own native locale processing.
Module developers take note: now when you expect a number you can use DataUtil::transformNumberInternal() to transform the number input by the user, e.g. 1,008 in Germany will become 1008. Similarly there is DataUtil::transformCurrencyInternal().
This means you can always be sure a number is correct internally. When it comes to the presentation layer, we have render modifiers formatcurrency and formatnumber. You can also use their counterparts in the code, DataUtil::formatNumber() and DataUtil::formatCurrency().
Next we have solved date formatting in a similar way. Each language pack has a list of date formats which the translator can translate into their locale area. We now have DateUtil::getDatetime() and DateUtil::strftime()
Dates should always be treated internally as unixtime and stored in the database in format of the constant DATEFORMAT_FIXED.
Share This | Print