This article is cross-posted from my blog on DotNetNuke.com.

Ever since the localization framework was first introduced in DotNetNuke 3.0, it has always been our intention to go back and complete the localization story for DotNetNuke.  When localization was first introduced in DotNetNuke, we only tackled the localization of static strings.  This support for the localization of static strings was sufficient to address the needs of many international users, however it was not adequate for addressing multi-lingual sites.

We realized from the beginning that content localization was a tough issue to address, and one which could be solved in numerous ways.  Every time we looked at tackling content localization, the effort always seemed to be a bigger than we had the resources to be able to tackle.  We wanted to make sure that whatever solution we put in place would meet the needs for a large portion of our community.

After many meetings with members of our Internationalization team, international community members and customers, and after many months of development, we are finally ready to release a DotNetNuke version which supports content localization.  I will leave it to others on our development team to go into the details of the implementation as we approach the final release of 5.5.  You can see an earlier version of code in the two videos that Scott previously posted.

Today, I am pleased to announce that an Alpha version of DotNetNuke 5.5 is available for download.  We are still in the middle of addressing some outstanding bugs from previous releases along with any bugs we are finding in the new 5.5 specific code.  We anticipate being able to release a beta version next week, but need your help in identifying any major outstanding issues with the current alpha release.

Because this is an Alpha release, we will not be supporting a seamless upgrade to the final 5.5 release.  This code should not be deployed in a production environment since we haven’t completed performance testing and tuning and we know that significant bugs still exist in this version of the code.

You can download the code from the Beta Release page on DotNetNuke.com.  Please post any questions or comments on the release to the Open Core Testing forum.

I am pleased to announce the release of DotNetNuke 5.4.4.  This maintenance release resolve’s two significant breaking changes that slipped through in 5.4.3 and resulted in us pulling the 5.4.3 release. Below are the highlights from this months release. As usual, you can see a full list of changes in the changelog.

Major Highlights

• Fixed issue with ExecuteSql method overloads to be able to handle ExecuteSQL(string, nothing) again.
• Fixed issue with Indirect Reference to DotNetNuke Library errors.

Security Fixes

• None

Updated Modules/Providers

The following modules and providers have been updated in the 5.4.4 packages.  Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

• Media Module 03.03.00

Providers

• None

NOTE:  As with any release, we recommend you perform a complete file and database backup before performing any upgrade on a production website and that you first conduct a trial upgrade on a staging version of the site.  Following these guidelines will ensure that you are able to recover should any unforeseen problems arise during the upgrade process.

I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Understanding the Basics

In the first part of this series we’ll be covering the basics of DotNetNuke Skinning.  My intent is to demystify some of the terms that we use and to relate them to our simple design.  Once you understand the basic elements that make up a DotNetNuke skin, then the rest of the skinning process becomes very easy.

A Little Background

One of the original goals we had when the DotNetNuke skinning engine was first created in 2003 was to make skinning accessible to both developers and designers.  This fundamental requirement has driven many of the changes over the years and continues to shape how we think about skinning in DotNetNuke.  From the very outset we thought that it was important that skin developers should be able to use whatever tool they were comfortable with and that they should not require any knowledge of programming in order to create cutting edge designs.  We also thought it was important that we put as few restrictions as possible into the skinning engine which would provide skinners with complete freedom in their designs.

The DotNetNuke skinning engine supports 2 different types of skins:  HTML Skins and ASCX Skins.  HTML Skins are the most basic form of skin and allow designers to use whatever HTML editor they desire.  When HTML skins are installed in DotNetNuke they are automatically converted to ASCX skins in the background.  During the conversion, the only part of the HTML skin that is retained is the innerHtml of the body tag.  Anything in the HTML Header will be discarded.

The DotNetNuke skinning engine recognizes a “Skin” as having two distinct entities: skins and containers.  These elements can be packaged and installed as a single package or as two distinct packages.  We’ll discuss containers later in this series and for now will focus on just the main skin package.  All of the concepts translate directly from skins to containers with a few minor differences.  If you understand how to create a skin, then creating the associated containers is easy.

More...