Background
A number of Months ago I launched an initiative with the DNN Core Team to improve the translation process of DNN. This is but one cluster of issues when it comes to 'localization' of the framework. There's also content-, or dynamic localization which is a tough and complex issue. But let's focus on translations. I'll use the example of my good friend Benoît Sarton from dotnetnuke.fr (i.e. France) as an example. I happened to have had the opportunity to tune in to this at the French meeting last March in Paris. I like to examine two phases of translation: production and distribution. Both are experiencing some difficulty as we'll find out.
When translating a framework, DNN relies on dedicated individuals around the world that take it upon themselves to do this. Benoît runs a business making extensive use of DNN and has volunteered to lead the French effort. He does so in close cooperation with his pal David. So far so good. But the pace of DNN releases is high and both Benoît and David have a business to run. Translating the core framework is one thing, translating all the core modules (including Forums) is quite another. So some work is delegated. The distribution of the translation effort is not that easy and unsupported by any tool. This holds up translation efforts. On top of that, they don't have access to the framework any sooner than regular users. You'll see that after release there is a lot of pressure on Benoît and David to get the language packs done. Emails start flooding in as French users download and install the latest framework.
Currently there is no structure in which translators are embedded. IMO we need to (1) improve the relationship we have with translators by embedding them in a formal structure in DNN, and (2) give them adequate tools to help a distributed translation effort. All too often we see someone making a translation and then not updating it for subsequent versions. My guess is because that person had a vested interest at first (i.e. for a particular job), and not afterwards. The embedding should help here.
Then there is an emerging issue surrounding distribution. Basically with the separation of the core modules from the central release, DNN introduced a timebomb in localization. The Core Team decided that it was best if all core modules could have their own separate development process, complete with teams, release processes, forums, etc. This frees the core framework to concentrate on their own release process and not be hampered by faltering modules. This is a good idea. It makes a lot of sense. Secondly the Core Team decided to allow users to chose which modules they wanted to install upon first installation. This meant a performance increase as unused DLLs would no longer be hanging around in the bin folder. Again a very good idea.
So where did this create a problem? Well, let's take a closer look at translation and language packs. You translate the resource files (*.resx) by creating a copy for your own language (lets say French) to get a localized version (*.fr-FR.resx). The various texts inside this file are then translated. The result is wrapped into a big zip, with a manifest, and can be uploaded into another framework. Cool. Now you have your DNN installation and you need French, you go and download the lang pack for French and you're done. Well, almost. Which files actually got translated? The core framework ones? Then you only have a 'Core' pack. It means your News core module, for instance, would still be in en-US only. So you want the pack to include all regular core modules? OK, no problem. But now you've decided not to install the News module, you've uploaded your French language pack, and you've decided you wanted the News module anyway. So you select install for that module and ... you guessed it: still only in en-US. The fr-FR language files were obliterated during install and they were irrelevant upon first upload as the module was not there.
A second stumbling block is the versioning of modules. You'll find that now that the modules have their hands free, they release outside the release cycle of the core. So how can anyone relaibly predict what comination of core framework with modules you have in terms of version nrs. Note that different versions might have different language packs (keys added, deleted, renamed etc).
So this begs the question: Why have Full lang packs? Why not do this per module and core? This is obviously the way to go, but now lets change perspective to the user. The user wants to locliaze his/her installation. This means wading through a myriad of language packs to get everything right (with version nrs etc). So this solution runs into serious practical issues. It is next to impossible for anyone to deliver a localized site when we distribute all packs separate.
The solution must come through technology (after all, this is what we do for a living eh). IMO we need to work toward a distribution network for the (fragmented) language packs. It will be more extensive and complex than the current alert on your 'Module Definitions' list for a new version. It is more of a matrix: language and versions of modules. This should also wire to the translator's site so he/she still gets the page hits they want.
The Meeting
The above was my plan and I was able to discuss it with the 'top brass' at OpenForce 07 EU. We reserved the Sunday evening to discuss this with the core team members there and the 'language leaders' that were present as well. Shaun Walker, Joe Brinkman, Charles Nurse, Vicenç Masanas, Erik van Ballegoij, Sebastian Leupold, Benoît Sarton, plus a bunch of others, were there to discuss this. Personally it was a high point in my 'DNN career' as I felt I was able to move an issue forward that needed this attention and all the relevant players were there. The audience was supportive and critical, just as I wanted them to.
We'll see where this is going to go. I have particular fond memories as the 'European leaders' huddled together to nail down a wish list in the bar over a few beers. Unfortunately it all ended too soon as I had to leave at midnight (drive back as I had appointments to see clients the next day).
Keep an eye out on dotnetnuke.com to see any developments on this! If nothing moves nag me or your nearest DNN representative ;-)