Localising content - a quick update on progress

We've been working on introducing content localization enhancements for a while now. Back in 5.2.0 we started to add some of the API pieces and other supporting framework that we would build on and the original aim was for 5.3.0 to contain support for localisation portal settings. However, this has proved more tricky than it would originally appear, so rather than rush out an imperfect solution with 5.3.0, we've pushed it back a month to the 5.3.1 release. Whilst the solution in place worked there were some concerns:

• Performance - this took two parts. We felt some further testing needed to be done to ensure that sites running with multiple portals and multiple languages would perform sufficently. Secondly, the solution that was in place introduced some additional database overhead. Whilst this will be necessary for sites that want to run localised portals, sites that would run in a mono-lingual basis could have been "punished" with lesser performance. To address this we'll likely add the ability to enable content localisation at the portal level (as well as the existing host level switch), and look to refactor some of our database queries so that both options performance is maximised.
• Changes in behaviour - whilst we initially localised all portal data (e.g. everything you see on the site settings page), there were some issues raised that questioned this. Whilst it's obvious that certain portal specific fields such as logos, footertext,description etc.(i.e. primarily the PortalInfo fields) are key candidates for localisation, we also store lots of values in the PortalSettings table and their need for localisation is less clear e.g. why would someone want to localise "EnableSkinWidgets"? However, we can see use cases for some of these such as DefaultPortalSkin, DefaultPortalContainer or even something such as SSLUrl (e.g. perhaps a site has translated versions of shared SSL pages). Rather than add an all or nothing solution, we want to consider the implications of this and whether we offer a concept of "global" and "localised" PortalSettings.

Whilst I'm sad that we're not going to see these bits in the forthcoming 5.3.0, I believe that waiting one month more until 5.3.1 to iron out any potential problems is the pragmatic and sensible thing to do, particularly as this will then form the basis of the other localisation enhancements that will be coming along shortly.