Hi all. Time for an update on the Localization Editor. In case you’re not familiar with this project, it is a tool to help you create language packs of your favorite DNN bit. Whether the core or a module. This new version of the editor aims to support something called CORE and FULL packs for the DNN core. Allow me to explain what’s going on.
A brief history of the full pack
Back when static localization was introduced (DNN 3) the distribution zip of DotNetNuke included a whole bunch of modules that were automatically installed. So when the opportunity was created to make a translation of DNN and upload it (as a so-called language pack), the translator was faced with the daunting task of not only translating all the core tidbits of DNN, but also each and every module that came with it. Pretty soon you saw the emergence of two types of packs: the CORE and the FULL pack. You probably guessed it. The FULL pack included all modules and the CORE didn’t. So far so good. People were comfortable with this division and who could blame a translator for not wanting to translate the forum module which, on it’s own, was about the same amount of work as the complete core at the time.
Later on, we discovered that the amount of stuff you have in the bin folder (i.e. all the module dlls and the core) has an impact on performance. So in an effort to improve performance and to “clean up” DNN introduced the “optionally installed” packaging in DNN 4. This meant that modules that were packaged as zip would get installed and those that were renamed to .resources were kept “at hand” and you could install them by checking a checkbox. This had one quirky impact on the language pack domain: when you installed a FULL pack and you did not have some modules installed, the installer would happily create the necessary folders for the localization files and dump them there. As there was no impact on anything (performance or otherwise) this was never seen as an issue and we all happily continued.
Then DNN 5 came along. And with DNN 5 we got a new installer. And as is often the case: those that designed this bit were not used to making or installing language packs on a daily basis. The new installer made everything a “package”. A package contains 1 or more items to install. A feature of this new approach is that you are assumed to “package” all your bits into a single file and properly announce them in one manifest. This means that if you upload a language pack consisting of more than one pack (e.g. core plus several modules) you list them all in the manifest. The manifest also required a much more rigorous approach to anything being uploaded. This included having language packs bound to a “parent” package. It’s easy to see the advantage of this approach. But when you now make a FULL pack and follow the rules and make that a collection of packs in a single package, the installer will refuse to install it unless all items are installed. And it will fail the complete package! By its very design the installer assumes you install packs one by one for each bit. Now we add a second complexity at this point.
DNN 5 also broke off quite a few bits that were previously integrated. If you check out the Install folder of a distribution zip you’ll see what I mean. This now includes a whole bunch of providers. All of these are separate packages. It’s a really great feature as you can roll out a lean DNN with providers of your own choosing. But unfortunately it meant that if you were to follow the rules and upload language packs for each bit of the core, you’d end up uploading something like 20 packs for each language. So it’s hardly surprising that since the early days of DNN 5 we have heard some resentment from the DNN translators.
With DNN 6 we hope the issue of the installer failing on a compound package will be resolved. I.e. if one of the packs has a dependency on an object that is not there, the installation of the complete pack should not fail. This is an important step to support FULL packs in the future again. For DNN 5 it is too late. The only way to install full packs in DNN 5 is to package it all together in one pack which you label as being a core pack. It’s not pretty but there is no other way for now.
Implications for Localization Editor
The localization editor was not previously well equipped to deal with compound packs. This came down to the fact that each version of DNN can have a different set of items (modules, providers, skins, etc) that are installed by default. So the first thing to do was to implement some kind of bookkeeping. This is done in the new table LocalizationEditor_ObjectCoreVersions. There we keep track of every object that is distributed as zip (i.e. installed by default) with the core version. If you already have the Localization Editor running with stuff in it, you’ll need to somehow make the records yourself if you want to benefit from this aspect. If you start from scratch I’ve made a complete SQL script to add ALL core distributed texts for all DNN 5 versions! In the first lines you’ll see ModuleId being added so you need to change the value of that for the module ID of the localization Editor you’re targeting (find out the module id if any module by clicking “Module Settings” and examining the querystring where you’ll see a value for ModuleId). If you run this under Host > SQL … you’ll probably see an error if you haven’t allowed for uploads bigger than 8 Mb as this file is 9 Mb long! So set the maxRequestLength in your web.config to something a little bigger. Anyway, if you use this you can hit the road running and have a Localization Editor ready to start receiving your translations. Note you must add at least 1 permission (i.e. binding a user as translator to a specific locale code) before you see the list of objects in the editor:
In this version I’ve also spent some time on language pack uploads. It used to be hidden on the object details screen but now it is on the main screen:
Follow the instructions on screen to upload an existing pack. This will allow you to migrate your old packs into this new system. Lots of time has been spent looking at various packs to see how they were made to come up with a solution that is able to parse all these packs.
In the new version downloading a DNN core pack brings up the following on your screen:
As you can see you can now download the core or the full pack. The CORE pack will include all objects that were installed by default and the FULL pack will include every object that came with the release. This also takes into account the version numbers of those specific objects.
The downloads can be found on CodePlex:
The development is done by myself. The DotNetNuke Internationalization team is involved as peer group. If you have any comments talk to one of us. We realize this is not a “perfect” translation tool, but we all have limited time to devote to this project and our aim is to provide a mechanism with which you can manage language packs.