I can't believe this...if the name of the virtual directory you installed DNN into is called "portal", that's what causes this problem. My theory: Somewhere in the localization process, it sees /portal and you're trying to get localized strings for a DesktopModule from the Portals folder, and it's doing some string substitution. I traced through the code for quite a while and didn't find the exact line of code - but it explains the behavior perfectly.
See another post of this happening: www.dotnetnuke.com/Community/Forums/tabid/795/forumid/108/threadid/330562/scope/posts/Default.aspx
If you install to a different folder (not named "portal", it works.) This is a temporary workaround: (from that post):
DNN is looking at the wrong path for the resource file.
The location of the Resource File is:
[site root]\DesktopModules\Admin\Portals\App_LocalResources\SiteSettings.ascx.resx
The location where DNN is looking for the file:
[site root]\desktopmodules\admins\app_localresources\sitesettings.ascx.resx
Create these folders and put a copy of sitesettings.ascx.resx to this path. Then it works.
It seems to be replacing Admin\Portal with admin.
I'm not familiar enough with the code to know exactly where it's coming from. This behavior is specific to the modules located in the Portals folder. I noticed this on SiteSettings and PortalAliases. Well, I played hunch and renamed my virtual folder dnn. No more issues. I am avoiding the name "portal" for now, no wonder I had such consistent problems.
So, these are my findings.
Best Regards,
Ryan