For quite a while now, some folks in the DotNetNuke community have been experiencing a peculiar issue with localization on the Core DotNetNuke Blog module. While we worked on version 03.05.00 of the module, I ran into a ticket that I thought I had already fixed in a previous version release and marked it as fixed. Somehow, just like the villain in bad horror movie, this ticket was back! I and the entire Blog team tried to replicate the issue to no avail, so what to do? – We closed the ticket, and this time marked it as “Cannot Reproduce”. A couple of days ago, the villain was back again! Argh!
At this point I was committed to get to the bottom of this issue and fix it once and for all.

First, let me try to give you some background on the bug. As you can probably deduce from the title of this blog post, this issue had to do with a persisting localized string. As you may (or may not) know, DotNetNuke support multi-lingual localization. In order to support the community across many countries, all core DotNetNuke module must implement this standard which means that any text that is surfaced in the UI must support localization. As a result, all text strings are localized in Resource files (resx).
As it turned out, a non-human-readable character (a JavaScript break directive, \n) was placed in one of the module’s localization file: A.K.A THE BUG.

So after extensive diagnosis, I finally figured out what was going on, and the answer is so interesting that it deserves this long-winded blog post to describe it.
As it turns out, the module’s resource file was indeed fixed in a prior version, and so was the case for the current version as well. The issue lied within how DotNetNuke, because it is so flexible, allows its users to customize their portals, languages, and text. I’ll explain.

One thing that I have always advocated is building localizable modules, not for the sole benefit of supporting multiple languages, but also to enable easy, and quick text customization without having to wrote code, rebuild, repackage and redeploy. For example, a module developer may elect to define a label for an input field and label it with the text string “Email”, while I, the end-user or webmaster, would like to instead see “Email Address”. In DotNetNuke, I can login as an Administrator, or Host, and go to the Languages section and modify that module’s resource strings via a management interface. Here is where the subtlety comes into play, because if you login as the host, there are two places where you can change the language.

Logging in as the Host gives you administrative privileges to the site you are currently on (Admin), and well as to the overall portal installation(Host), while logging in as the the administrator limits your privileges to manage only your own site.

Clicking on either of the “Languages” menu item will take you to the same (UI wise, at least) localization management page. To modify your localized strings click on the “Language Editor”, you will arrive at this page:

This is where the fun begins. If I arrived at this page from the Host menu, and modified any of the localization strings then then entire portal and all sub portals would inherit this change, no exceptions. Also note that, when and if a module is upgraded, the new resource files will overwrite whatever changes you made here. If you are adamant about your previous changes, you will have to re-do them again after you upgrade the module (or DNN for that matter), and this is where the “Admin” or “Site” Languages becomes very useful.

If you login as Admin, and edit the localization strings, then you are editing the localized string specific to your portal (the portal in context). The way DotNetNuke enables this compartmentalization of languages is by creating a separate local resource file specific to the portal, unbeknownst to the user and as soon and the update button is clicked. The end result is a duplicate resource file, with “Portal-ID” (i.e. Blog.ascx.Portal-0.ascx, where 0 is the PortalId) appended to the name, and in which ONLY the changed localization strings are stored. DotNetNuke/ASP.net take care of the pulling the correct strings based on the portal being accessed.

Here is a screen shot of the “DesktopModules/Blog/App_LocalResources” after I made a text change:

In conclusion, this may very well be the reason why users are still seeing buggy localized strings even after an upgrade. Next time you run into a similar issue, make sure you check the following folders and make sure that the strings in question are not read from outdated portal-specific localization files:

ROOT
-- App_LocalResources
-- App_Global Resources
-- DesktopModules
---- ModuleName
------App_LocalResources
---- ModuleName 2
------ETC…

I do not believe that there is currently an easy way to reconcile un-synced localization strings, and therefore, the effort required to sync them up manually may depend on the amount customization you made to your language resource files.