This application is situated in the example10 folder. To run it on your own server you need the same data as for example3. To try it out on the phpPeanuts website click here.

It localizes a copy from example 9 for Dutch users: labels and announcements are in Dutch, Dutch number format and date format are used. The data are still in English because it is to far-fetched for this example to build a multi language database. Read how to build multi language applications entirely before you decide to use phpPeanuts for building a multi language application!

To localize example 10 we stated with the introduction of a code management scheme. We chose a scheme that supports the customization of the applications for a specific deployment: all code we like to reuse between deployments was put into classes in the classFolder my/example10, all their names prefixes with 'My'. ('My' stands for the company that is developing and maintaining the reused code). Then we created empty subclasses of these classes in the application classFolder (example10), with the same names but without the prefixes. Also see how to keep your application code separated from customization code.

Once the code management scheme was in place, we went through all the 'My' classes and made overrides in the corresponding subclasses wherever we needed to translate something into Dutch. If appropriate we did a little refactoring so that we could override specifically some string constant instead of an entire method.

To localize the stringconversions we copied StringConverter from the root classFolder and there we made overrides for the number format, the date format and all error messages. We did the same with ValueValidator.

To localize the framework pages, parts and actions, we copied their classes from the root classFolder too, and made overriding methods that translate page- and button labels etc.. These classes can be recognized from not inheriting from a 'My' prefixed superclass in the 'my/example10' folder. We advise you to read through the code of all the classes in the application classFolder (example10), eventually looking at the superclasses in the my/example10 classFolder to see how refactoring was done. Also look for applicable howto's in the localization section.

Finally we found that there where a few texts in skins that had to be translated too. For skins we could not use the override trick we used with classes, because skins have no inheritance. The choice is either to get the texts from the corresponding object using a php call to a print method, and then override that method, or simply modify the skin. We chose to do the last. We also had to copy a few skins from the includes folder so that we could change texts in them.

P.S. We could have used a different code management scheme. For example if the application is deployed several times in one language and several times in an other, it might be nice to be able to customize each of the deployments according to specific requirements. Adding another immediate layer between the classes in the application classFolder and the generic application classes in the my/example10 classFolder can solve this. The same holds for overriding of the generic framework classes: we chose to only localize the example10 application, and to do that we copied the classes from the root classFolder to the application classFolder. But if we wanted to localize all examples at once, we would probably have changed the classes right away in the root classFolder.