osCommerce Blog

The biggest task for the second alpha release is just about ready! This is what I have had my head stuck in the past weeks, from spending time looking for a nice XML library to serialize and unserialize data to and from an XML document, to tediously moving the language definitions over to XML files for easier management.

Boy did that take longer than expected! And I didn’t write my own XML class this time to speep up things, which will more than likely come later

The intentions of moving the language definitions over to XML files is to make it easier to manage “language packs” - and at the same time to make it easier for translators to translate each definition in a more friendly environment without the need anymore to check if the slashes have been escaped properly (yes, you have read the nasty long text on the index page of a fresh osCommerce installation haven’t you?)

The problem here was needing functionality to parse data to and from XML formats, was efficient, had no dependencies, didn’t add 100k worth of source code to the projects filesize, and worked in PHP 4.

I tried the libraries Pear provided and played around with many functions and classes I found in the user comments of the PHP documentation and what Google returned. I ultimately found a nice simple efficient library to use that serves its purpose perfectly for now. And to feed my satisfaction even more of finally finding what I was looking for, I whipped up a custom XML wrapper class together that transparently uses this library if PHP 4 is installed or uses the native PHP 5 SimpleXML features if PHP 5 is used. Groovy!

The base language definitions (excluding definitions used in modules) are now in one main file inside the languages directory, named after the code of the language (eg, en_US.xml, de_DE.xml, ..). The settings for the language also exist in this file (eg, date formats, locale, ..). A directory also exists with the same code name, that contains the images used for that language (buttons) and the definitions of the modules, each in their separate XML files in a structured directory (eg, en_US/modules/payment/paypal.xml).

These are in separate files so that when the module is uninstalled, so are its language definitions! There is no relationship here between the module and the language definitions, as how the module parameters are linked from the module itself, so the uninstallation routine reads the XML language file for the module and automatically deletes the definition keys from the database. Nice, clean, and transparent

The installation routine now scans the languages directory recursively and imports all found XML files into the database, automagically. Groovy!

Yes! The definitions are stored in the database - they are not read from large-sized-XML-files on each page request which would kill the performance of the store.

The bonus point here is that each definition is now assigned a group, which the page being loaded only queries from the database. This is ofcourse cached for optimal performance.

The reason why the definitions are not cached directly from the XML files is to keep a copy of the definitions for additional features in future releases. One great possible feature here is then being able to compare between edited definitions and base definitions, to make it easier to manage the numerous translations a store can have.

Importing new language packs from the Administration Tool follows the same principle as the installation routine, where it recursively scans the language directory and imports the definitions in the XML files into the database.

With providing so much ease now to the store owner, we obviously must match this with equally so much power, so it is also obviously possible to export language packs! This should help increase the quality of the language packs that are contributed to the project. Groovy!

Searching for language definitions would also improve the management of the installed languages, and will be worked in in a later alpha release.

The only negative aspect of the new language implementation is needing to declare the $osC_Languages object as a global within functions and class methods, as the values of the definitions are now returned as $osC_Languages->get(’definition_key’). I think this can be fixed with a nice method Drupal uses of a simple t() function (ie, t(’definition_key’)) but this would break our coding standards of functions needing to be abbreviated with osc_, so that would become osc_t(’definition_key’), which I personally hate more than what is being used now Dilemmas, dilemmas

Here’s a movie showing what will appear in the second alpha release, that I am aiming to provide to our sponsors for testing over the weekend. This release is obviously late for the reasons explained above, and will make sure to update the workboard with the new roadmap for these alpha testing releases once this second release is available.

oscommerce-languages.mov

Here’s to the fun work coming ahead, now that the dirty work has been done!