Hi Parker, There are a number of areas where we have thought about internationalisation. All the button tags, messages etc are defined in a single messages.properties file located in the web application. This the typical java approach allowing locale specific files to be added which will be automatically used based on the current locale. Locale is also used throughout the application for dates, times and currency. You can define additional currency settings by adding a lookup.currency and associating with the practice. This is for things such as rounding. The most important area area we need to add internationalisation support is in the archetype definitions. These define the objects and relationships that we store and are used also by the screen rendering system to display labels and object names (i.e Patient -> Sex ). Currently we would need to provide modified versions of these to support the different language, replicating the structural stuff that is actually common to all languages. This is not ideal so we have been thinking about an alternative approach. Any thoughts/contribution in this area would be great ! Tax regimes is an area we have also thought about a bit and implemented a pretty flexible approach but it still needs to be tested in a production environment with more difficult tax settings than Australia (generally a simple GST on everything with minimal exclusions and no additional state tax issues). Any ideas or comments on what else we can do would be much appreciated .. Cheers Tony