原理：
DNN中的页面全部是由用户控件组成的。本地化应用程序只需对每一个用户控件进行本地化就行了。对控件进行本地化的资源都在相应的资源文件中。
几个相关名词（DNN程序本地化中常用的几个名词自己根据理解翻译的也不知对不对）：
ResourceFileRoot：本地资源文件基本名称。
如：GlobalResources.resx就是一个基本名称。
GlobalResources的其它本地化资源文件的名称就可以是GlobalResources.zh-CN.resx（中文）
GlobalResources的站点级本地化资源文件文件的名称就可以是GlobalResources.zh-CN.Portal-0.resx（中文）
resourcekey：在资源文件中查找特定的本地化内容的key
地区信息：无论是在用户注册时，还是在站点时都有相应的地区信息选择。它是决定呈现何种语言界面的依据。如下图：
在应用程序加载时，程序按照：注册用户的地区信息-->访问站点的地区信息-->系统默认的地区信息（en-US）就决定呈现界面的语言。正是因为这个顺序说明了为什么有人安装语言包后人没有得到汉化后的界面。主要是因为没有将站点、用户的语言设置为指定区域语言。
在读取本地化资源文件的顺序：先读取站点级本地化资源文件（如：*.zh-CN.Portal-0.resx）-->主机级本地化资源文件（如：*.zh-CN.resx）-->系统默认（如：*.resx）。另外每种语言还可设置一个后备语言（fallback），当第一语言本地化资源文件加载失败时可加载后备语言的本地化资源文件。这一功能程序中没有给出操作界面，只能在Locales.xml文件中修改。比如我将Chinese的第一语言设置为zh-CH（简体中文），后备语言设置为zh-TW（繁体中文）。当某一控件没有简体中文的资源文件时它就会去找繁体中文的资源文件
DNN中的本地化——打造全球通用的程序
3G双线全能空间1元 开网店-找友创互联 0元招收代理【CN域名0.5元】
http://tech.ddvip.com 2008年10月31日 社区交流
关键字： DotNetNuke DNN本地化 DNN XCOPY web.config
DNN中的本地化——打造全球通用的程序。
<?xmlversion="1.0"encoding="UTF-8"?>
<root>
<languagename="English"key="en-US"fallback=""/>
<languagename="Deutsch"key="de-DE"fallback="en-US"/>
<languagename="Chinese"key="zh-CN"fallback="zh-TW"/>
</root>
语言包的内容：（语言包的内容都分布在各个相应App_GlobalResources文件夹下）
全局语言包文件（只列举ResourceFileRoot，相应的.zh-CH等就是本地化的资源文件）
GlobalResources.resx：存放本地化菜单的信息
SharedResources.resx：存放本地化按钮、提示信息等一些页面通用的控件的信息
TimeZones.xml：存放时区信息。
模块语言包文件：（用户模块也就是第三方模块，DesktopModules中的各个App_GlobalResources文件夹下的）
控制语言包文件：（通用的用户控件，controls中的各个App_GlobalResources文件夹下的）
管理语言包文件：（管理模块也就是实施网站后台管理的各个功能模块，admin中的各个App_GlobalResources文件夹下的）
本地化相关的程序：
adminLocalization文件中的各中操作语言包的用户控件，它们实现了主机管理下的语言管理的全部功能。这些控件有：创建语言包（Languages.ascx），编辑语言包（LanguageEditor.ascx），生成语言包（LanguagePack.ascx），编辑时区信息（TimeZoneEditor.ascx），效验语言包检查本地化文件的完整性（ResourceVerifier.ascx）。
依然存在的问题：
DNN提供的程序是可以适应全球化的。我们开发的第三方控件也可做成可适用于全球化的。但是在DNN中建设的网站内容如何进行全球化呢。比如我新建一个标签Home，我需要中国用户访问时时“首页”，美国用户访问是“Home”。同样页面中的内容也是如此。如果有这种要求该如何解决呢？我想在开发用户模块控件的时候是不是应该考虑进去。在用户添加模块时做一个语言选择。按照不同的语言输入不同的内容。这也就是说，比如我添加一个Text/HTML模块输入一段内容就可以同时多种语言版本的在呈现时就可以选择需要的一个了