国际化（internaotionalization）和本地化（localization）这两个术语被用来表示人们对非英语语言的WordPress相关内容翻译所做的贡献，翻译WordPress的人可能使用不同语种，或者同一语种下不同方言和不同的本地优先级。

本地化一个软件需要经过两个步骤。首先是该软件的开发人员为最终翻译和程序接口提供一种符合本地优先级和世界各国语言的机制，WordPress开发人员已经完成了这一任务，因此从理论上来说，WordPress可以被用于任何语言。

其次便是实际的本地化过程，即人们利用软件开发人员所开发的机制，使软件页面内容以及其它设置被翻译成另一种语言、适应另一种文化的过程。WordPress已经被翻译成多种语言版本（更多信息请见WordPress in Your Language）。

本文介绍了WordPress翻译者（WordPress双语用户或多语言用户）可以为WordPress本地化所做的贡献。

翻译WordPress

翻译WordPress前，请先查看 WordPress in Your Language（及文中所列网站中）中是否已经有了你要翻译的WordPress语言版本。当然也有可能某个人（或者某个团队）已经在将WordPress翻译成你准备翻译的语言版本，但是还没有完成。我们可以订阅 wp-polyglots mailing list邮件列表，介绍自己然后询问是否有人在你和做同样的工作。这里还列出了一些为WordPress本地化服务的团队，可以从中查看是否有人和我们进行同样的本地化工作。

本地化要求

如果没有发现自己需要翻译的WordPress语言版本，或者其他人对该版本的翻译还没有完成，这时如果希望将WordPress翻译成自己所用的语言，需要符合以下要求：

• 精通两门语言——书面英语以及此次翻译的目标语言。如果不够精通，不仅翻译过程会很艰难，翻译后的内容也不容易被使用目标语言的人接受。
• 熟悉PHP，因为有时需要通读WordPress代码，找出最恰当的语言来翻译其内容。
• 熟悉人类语言的构成：名词、动词、冠词等，以及不同此类的各种形式，能够识别英语中不同词类的变体。

语种

一个语种，是相应语言与其区域性方言的综合。通常语种与国家相对应，如葡萄牙语（葡萄牙）和葡萄牙语（巴西）。

我们可以将WordPress翻译成任何语种，甚至包括加拿大英语、澳大利亚英语等其它地区的英语，可以修改WordPress中的内容使之符合加拿大、澳大利亚的拼写习惯和俗语。

WordPress的默认语言是美国英语。

本地化技术

WordPress开发人员将GNU gettext作为WordPress的本地化架构。Gettext是一个被广泛用于软件模块化翻译的成熟架构，实际上也是开源项目/免费软件王国中的本地化标准。

Gettext使用信息级翻译技术——即显示给用户的每条“信息”都会被独立翻译，无论是一个段落还是单词。在WordPress中，WordPress PHP文件通过两个PHP函数（__()与_e()）生成、翻译并运用这类显示给用户的“信息”。当信息作为参数被传递给其它函数时，会用到函数__()；而将信息直接写向页面时，会用到_e()函数。具体请看：

__($message)

查找对$message的翻译的本地化模块，并将翻译结果传递给PHP的return语句。如果没有找到对$message的翻译，该函数返回$message。

_e($message)

查找对$message的翻译的本地化模块，并将翻译结果传递给PHP的echo语句。如果没有找到对$message的翻译，该函数回显$message。

注意：本地化一个主题或插件时，应使用“Text Domain”工具。具体信息请分别查看主题开发和插件开发。

Gettext架构在WordPress大部分范围内畅通无阻。但在WordPress中有些地方无法使用gettext——阅读 Files For Direct Translation了解如何翻译这些地方的内容。

gettext文件

gettext翻译架构中的文件可分为三种类型。这些文件都是翻译工具在翻译过程中会用到/生成的文件：

POT（可移植对象模板）文件

本地化进程的第一步，就是用一个程序搜索WordPress源代码，找出被传递给__()或_e()的所有信息。被找出的信息列表被存放在已编排格式的模板文件（POT文件）中，该文件构成所有翻译内容的雏形。独立的POT文件也可用于主题/插件，前提条件是主题/插件开发人员将所有内容圈在__()函数或_e()函数中。

PO（可移植对象）文件

本地化进程的第二步，翻译者将POT文件中所有信息翻译成目标语言，并将英语原文和翻译后的信息保存在同一个PO文件中。

MO（机器对象）文件

本地化进程最后一个步骤，为PO文件执行一个程序，使其成为一个经过优化的、供机器识别的二元文件（MO文件）。将翻译结果编译成机器可读代码后，用本地化的程序检索翻译内容就更方便迅速了。

翻译工具

翻译时可以根据自己的喜好借助各种翻译工具。

Launchpad

Ubuntu Linux系统中有一个网站，用户可以在网站中直接翻译信息而不必查看任何PO文件或POT文件，然后将翻译结果直接导出到MO文件。

注意：很多翻译者发现Rosetta是一个不错的起点，而一到校对翻译结果阶段，很多人还是会选择手动编辑PO文件，或者使用poEdit、KBabel等程序。这是因为Rosetta UI不具备校正和编辑时必要的查找等功能。

Pootle

一个基于网络的开源翻译系统。Pootle的服务器寄存在Locamotion.org上，服务器上有激活的WordPress翻译版本。

poEdit

用于Windows、Mac OS X与UNIX/Linux系统的开源程序，提供一个便于使用的GUI以编辑PO并生成MO文件。

KBabel

适用于Linux系统中KED窗口管理器的开源PO编辑程序。

GNU Gettext

官方Gettext工具包中包括各种用于创建POT文件、处理PO文件以及生成MO文件的命令行工具。还包括一个命令shell。

用Launchpad翻译WordPress

独立页面 instructions for translating WordPress with Launchpad中有详细说明。

用Pootle翻译WordPress

1. 在Pootle服务器上注册一个账号，发送一份邮件给管理员，要求增加我们的目标语言版本的WordPress

2. 开始翻译前，请登录Pootle。未登录用户有时能够浏览内容、提交意见，但翻译是登录用户的独有权利，不登录无法翻译。

3. 访问目标语言的WordPress页面。例如Afrikaan语的页面是 pootle.locamotion.org/af/wordpress/（不要忘了结尾斜线）。

4. 点击“Show Editing Functions（显示编辑功能）”

5. 点击“Quick Translate（快速翻译）”以编辑未翻译的与语义含糊的内容，或点击“Translate All（翻译全部）”以编辑所有内容。

为了能在locamotion.org上翻译WordPress，wordpress.pot文件被分散成多个小逻辑单元，其中包括readme.html文件，还包括一个包含所有内容的文件，用户可将该文件按正常步骤手动添加到PHP文件中。

这里和这里有对WordPress翻译的相关介绍。

将翻译结果整合到wordpress.pot

正常情况下，翻译人员可用Pootle服务器随时下载自己翻译的软件的PO文件，并将下载的文件提交到自己的翻译项目中。但由于在pootle.locamotion.org上，原始源代码被分散成多个小单元，翻译人员不得不手动整合翻译结果和wordpress.pot文件，之后再将结果提交到WordPress。

1. 下载官方WordPress POT file

2. 下载WordPress Continent POT file （可选操作）

3. 在本地机器上下载并安装 Translate Toolkit

4. 从Pootle服务器上下载经过翻译的或部分翻译的PO文件。可以逐个下载，也可以以ZIP文件形式一次性下载（参见网站上的选项）。一般情况下下载经过翻译的PO文件无需登录Pootle。

5. 首先将PO文件整合到0翻译记忆中（整合后，之后的操作中只需要处理一个文件），在命令行中执行以下命令：po2tmx -l xx -i pofiles -o xx.tmx，其中xx即你的目标语言代码。以上操作生成一个名为xx.tmx的TMX翻译记忆文件。

6. 接下来根据翻译记忆文件预翻译WordPress POT文件。可执行以下命令进行预翻译：pot2po –tm=xx.tmx -i wordpress.pot -o wordpress_xx.po。该命令为目标语言生成一个PO文件，文件名为wordpress_xx.po。

7. 最后，在命令行中使用pocount wordpress_xx.po来计算PO文件的字数/字符数，查看有多少内容已经被翻译，多少内容还没有翻译或意义不明。

如果所有PO文件都被100%翻译了，最终的wordpress_xx.po文件也会被100%翻译。如果PO文件中有字符串没有被翻译，pot2po命令可能会造成wordpress_xx.po文件中的翻译语句含意模糊（这未必是坏事）。

用poEdit翻译WordPress

1. 下载并安装poEdit

2. 下载官方WordPress POT file

poEdit界面

3. 在poEdit中打开官方WordPress POT文件

4. （见上图）标注有①的文本框是POT文件中的原始信息（英文）。在标注有②的文本框中添加对①的翻译，在标注有③和④的文本框中添加对该信息的注释。与翻译团队合作时，可以通过这种方式分享自己对PO文件内容的看法。

5. 在文件——另存为….中将翻译结果保存为PO文件。

6. 翻译完毕后，再次在文件——另存为….中将翻译结果保存为PO文件。

7. 也可以点击文件——优先级，然后在编辑框中点击保存时自动编译.mo文件。

用KBabel翻译WordPress

本部分内容不完整。

1. 下载官方WordPress POT file

2. 在KBabel中打开文件

用Gettext工具翻译WordPress

1. 下载官方WordPress POT file

2. 在常用的文本编辑器中打开文件

3. 升级页头信息

4. 翻译信息

5. 以.po为扩展名保存文件

6. msgfmt -o filename.mo filename.po

PO文件页头信息

PO文件的开始部分即页头信息。页头给出了待翻译的软件信息和软件版本号、翻译者名称以及文件创建日期。页头信息中有一部分内容是所有WordPress翻译通用的，无需更改：

# LANGUAGE (LOCALE) translation for WordPress.
# Copyright (C) YEAR WordPress contributors.
# This file is distributed under the same license as the WordPress package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: WordPress VERSION
"
"Report-Msgid-Bugs-To: 
"
"POT-Creation-Date: 2005-02-27 17:11-0600
"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE
"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>
"
"Language-Team: LANGUAGE <LL@li.org>
"
"MIME-Version: 1.0
"
"Content-Type: text/plain; charset=CHARSET
"
"Content-Transfer-Encoding: 8bit
"

用相应内容代替其中的大写字母代码。

信息格式

文件剩余部分的格式为：

#: wp-comments-post.php:13
msgid "Sorry, comments are closed for this item."
msgstr ""

#: wp-comments-post.php:29
msgid "Sorry, you must be logged in to post a comment."
msgstr ""

#: wp-comments-post.php:35
msgid "Error: please fill the required fields (name, email)."
msgstr ""

每段信息的第一行都描述了该信息在WordPress代码中的起始行数。在上面这个例子中，这三段信息的起始行分别是wp-comment-post.php文件的第13、29、35行。有时我们要自己在WordPress代码中查找一些信息，找到所需信息后，记下它们在核心代码中的位置和相应行数。有时在不同位置上会出现相同内容的信息；这种情况下，我们需要分别列出这些信息的所在位置和行数。

信息的第二行，msgid，即源语言信息。这就是WordPress传递给__()函数和_e()函数的字符串，同时也是需要翻译的信息。

信息的最后一行，msgstr，是空白字符，我们将要在这里填入自己的翻译。

下面是以上信息被翻译后的样式，以汉语为例：

#: wp-comments-post.php:13
msgid "Sorry, comments are closed for this item."
msgstr "对不起，该文章的评论功能已被关闭。"

#: wp-comments-post.php:29
msgid "Sorry, you must be logged in to post a comment."
msgstr "对不起，请登录后再发表评论。"

#: wp-comments-post.php:35
msgid "Error: please fill the required fields (name, email)."
msgstr "错误：请填写必要字段（名称、电子邮箱地址）。"

注意：关于如何在翻译中使用HTML字符实体，请参考下文的字符编码和HTML字符实体。

待翻译信息类型

标签（label）

标签通常用在HTML的 <label>, <legend>, <a>或<select>等标签中。标签是对UI（用户界面）元素用途的简短而精确的描述。有时标签的内容很难翻译，尤其是一些在英语中既可以作名词解释又可以作动词解释的单个词语。翻译大多数标签时，都得先熟悉整片代码内容，了解标签的语境，最后才可能为标签内容想出恰当的翻译。

大多数信息都是WordPress管理界面中的一部分，因此标签几乎是最常见的待翻译信息类型。

标签示例

msgid "Post"
msgstr "Artikkeli"

“post”本身有动词的意思，但在这里的语境中，post实际上是一个名词。很难在其它语言中找到与名词形式的post相应的表达，即使是翻译团队也没有想出对这个术语最最恰当的翻译。很多译者在翻译post时都用与英文中“article”相近意思的本国语来表示。（Finnish (Finland)翻译版本。）

#: wp-login.php:79 wp-login.php:233 wp-register.php:166
#: wp-includes/template-functions-general.php:46
msgid "Register"
msgstr "रजिस्टर"

以上代码摘自印度语翻译版本。

#: wp-admin/admin-functions.php:357
msgid "- Select -"
msgstr " - Dewis -"

如果目标语言用户难以理解被破折号围住的这些术语的意思，可以删除这些术语；如果目标语言中有约定俗成的相应术语，则可以用相应术语替换掉这些英文。（威尔士语版本）

内容丰富的信息

还有一种常见的待翻译信息类型，内容丰富的信息通常由意思完整的句子组成，向用户表达某种信息或要求用户进行某项操作。这种类型的信息比标签长，翻译难度相对较小。但将较长的内容翻译成正式语体（或者非正式语体）时会遇到更多变数，这正是一些翻译人员头疼的地方。

示例

#: wp-login.php:146
msgid "Your new password is in the mail."
msgstr "Вашата нова парола е в електронната ви поща."

该信息中有一个经过部分改动的英语固定表达（”the check/cheque is in the mail”），使内容倾向于非正式体。（摘自保加利亚语版本。）

#: wp-includes/functions.php:1636
msgid “<strong>Error</strong>: Incorrect password.”
msgstr “<strong>FEL</strong>: Felaktigt lösenord.”

由于错误信息的字数较少，语言简洁，更倾向于正式体。（瑞典语版本。）

#: wp-includes/functions-post.php:467
msgid "Sorry, you can only post a new comment once every 15 seconds. Slow down cowboy."
msgstr "Leider kannst du nur alle 15 Sekunden einen neuen Kommentar eingeben. Immer locker bleiben."

当然，就像上面的这个例子一样，也不是所有错误信息都使用正式体。（德语版本。）

带有描述性信息的字符串

有些字符串中包含一个竖线，竖线的右侧是一段描述性语言。这些描述性语言或说明字符串的语境，或提供字符串的相关信息，以帮助翻译人员更好地了解字符串的准确含义。

示例

#: wp-includes/locale.php:186
msgid ""
"number_format_decimal_point|$dec_point argument for http://php.net/number_format, default is ."
msgstr ","

各语种的时间和日期设置

PHP内置本地日期转换功能，但大多数虚拟主机只为少数语言配置了这一功能，因此WordPress使用gettext翻译模块来完成对日期和时间的翻译和格式转换。

WordPress翻译以下内容：

月份名称

#: wp-includes/locale.php:42 wp-includes/locale.php:57
msgid "May"
msgstr "Květen"

（捷克语版本。）

月份缩写

#: wp-includes/locale.php:57
msgid "May_May_abbreviation"
msgstr "Mag"

注意这里的msgid与平时略有不同。这里的msgid信息不能按照字面意思直接翻译：在英语中，May（五月）的全称和缩写都是May，上面的写法避免了Gettext将它们误看做同一个词。（意大利语翻译。）

一天在一星期中的名称

#: wp-includes/locale.php:7
#: wp-includes/locale.php:18
#: wp-includes/locale.php:31
msgid "Tuesday"
msgstr "火曜日"

（日语版本。）

星期名称缩写

#: wp-includes/locale.php:31
msgid "Tue"
msgstr "Уто"

（塞尔维亚语版本。）

星期名称首字母缩写

#: wp-includes/locale.php:18
msgid "T_Tuesday_initial"
msgstr "ti"

星期名称的首字母缩写要用在WordPress的日历功能中，在英语中星期二（Tuseday）和星期四（Thursday）的首字母相同，因此这里和月份缩写用法相同。不是所有语言都用星期的首字母缩写来表示星期名称：上面的挪威语就在字母t后又加了一个字母i来表示星期二（tirsdag），避免和星期四（torsday）混淆。（挪威语版本。）

日期格式字符串

这是PHP date()函数的格式字符串，译者可通过该函数将日期和时间格式修改为目标语言的日期和时间格式。

WordPress将修改后的日期和时间格式用在其他关于月份名称、星期名称的本地化文件中。修改后的字符串不仅规定了日期、时间元素，也包括日期和时间的显示顺序。

下面是theme.pot文件中的一个msgid信息：

#: archive.php:40 search.php:19 single.php:22
msgid "l, F jS, Y"
msgstr ""

在英语中，日期和时间格式为：

Sunday, February 27th, 2005  

而不同语言的日期格式也不尽相同。如丹麦语中的日期表示法是：

søndag, 27. februar 2005  

于是丹麦语中关于日期的完整的msgid信息将被翻译成：

#: archive.php:40 search.php:19 single.php:22
msgid "l, F jS, Y"
msgstr "l, j. F Y"

汉语和日语中有一种日期格式是：

2005年2月27日  

相应的翻译结果应是：

#: archive.php:40 search.php:19 single.php:22
msgid "l, F jS, Y"
msgstr "Y年n月j日"

最后，如果需要在日期格式中加入字母字符（西班牙语中有这种需要），可以在日期后面加上右斜线：

#: archive.php:40 search.php:19 single.php:22
msgid "l, F jS, Y"
msgstr "l j de F de Y "

输出结果：

domingo 27 de febrero de 2005  

通过WordPress-PHP翻译

可以用WordPress函数 mysql2date(日期格式, 日期字符串) 来翻译插件等地方的日期。

含有占位符的信息

很多信息中都包含特别的PHP格式化占位符，译者可通过占位符将不可翻译的动态内容插入到经过翻译的信息中。PHP占位符通常有两种形式：

%s 

只有一个占位符时，使用该占位符标记

%1$s, %2$s, %3$s, … 

这是被编号的占位符，翻译时可以重新排列占位符在字符串中的顺序，同时保留替掉换占位符的信息。

示例

#: wp-login.php:116
msgid "The e-mail was sent successfully to %s's e-mail address."
msgstr "El e-mail fue enviado satisfactoriamente a la dirección e-mail de %s"

某邮件的接收人姓名需要被插入到以上信息的占位符中。（西班牙语版本。）

#: wp-admin/upload.php:96
#, php-format
msgid "File %1$s of type %2$s is not allowed."
msgstr "类型为%2$s的文件%1$s不允许被上传。"

以上信息逆转了翻译中的文件名和文件类型顺序。（汉语版本）

高质量翻译技巧

不要按照字面意思逐字翻译，应根据自己的语言重新组织

毋庸置疑，作为双语甚至多语言用户，译者都明白，目标语言和源语言（就WordPress翻译中而言，这里的源语言即英语）之间存在语法结构、韵律、语调等方面的差异。经过翻译的信息没有必要完全和英语语法结构一致：翻译时先理解源语言所要表达的意思，然后用目标语言自然而完整地表达出相同的意思。这就是“意思相等”和“意思相当”之间的区别：翻译的精髓不是“复制”，而是“替代”。即便源语言中句法结构再复杂，如果目标语言中有更符合逻辑或者更容易被人接受的说法，译者完全可以重新组织句法结构，只要能表达出相同意思即可。

前后尽量保持相同语体（正式语体或非正式语体）

源语言中不同信息的正式程度可能有所不同。译者需要自己决定（或者与翻译团队共同决定）将信息翻译成目标语言时使用正式语体或是非正式语体。WordPress信息本身（尤其是资料性信息）倾向于礼貌性的非正式语体。翻译时请尽量根据目标语言的语言环境，使用统一的表达方式。

不要使用“行话”或仅有部分读者了解的术语

翻译时可以使用一定数量的术语，但应尽量避免用到那些只有“内行人”才明白的“行话”。如果有初次接触WordPress的博客用户安装了你翻译的WordPress版本，他们一定会被过多的专业术语弄得晕头转向。但pingback、trackback、feed这几个术语是例外；在其它语言中极难找到相应的词来代替这些词，因此很多翻译人员选择不翻译这几个术语，保留他们的英文。

借鉴同语种其它软件的翻译方式

翻译中遇到问题或需要灵感时，可以试着阅读其它常见的软件工具的本地化版本，从中了解一些常用的术语、翻译采用的表述方式等等。当然，WordPress也有自己独特的表达方式，在参考其他本地化资料时要牢记这一点，不过用户界面上的术语都是可以借鉴的。

WordPress本地化资料库

WordPress本地化资料库http://svn.automattic.com/wordpress-i18n/是官方WordPress翻译版本所在的版本资料库。很多团队共同合作，将WordPress翻译成各种语言，团队维护人员将所翻译的资料上传到版本资料库中。

参与

任何人都可以参与资料库的更新。只要订阅 wp-polyglots mailing list邮件发送清单，做个自我介绍，让大家了解你希望翻译的语言版本。如果已经有团队在进行相关翻译，他们会告诉你，你也可以加入他们的团队。如果还没有相关团队，你可以自荐成为新团队的维护人员，也可以直接开始翻译工作，资料库的维护人员会把你的翻译成果添加到资料库中。

翻译准则和要求

注意：以下翻译要求会随所用系统不同而有所变化，资料库管理员也会根据翻译要求的变化帮助翻译人员更新资料库中的文件。

字符编码要求

所有语种的本地化文件都至少应该具备一个与之相应的UTF-8编码版本文件，同时可以添加相应的、其它字符编码形式的文件。

PHP不支持BOM（字节顺序标记），因此要确保自己的UFT-8编码文件中没有BOM。

HTML字符实体要求

除了下文将要提到的一些例外情况，所有翻译结果都应该完整输入资料库。

为了避免与XHTML标记发生冲突，一些HTML字符不得不被转换成其它编码形式：尖括号（&lt; 与 &gt;），&符号（&amp;）。此外，还有一些字符也最好被转换成其它形式，如无间断空格 (&nbsp;)、 引号(&laquo;与 &raquo;)、以及‘符号(’) 和‘’引号。

更多关于W3C关于字符编码和字符实体的最佳用法，请参考以下资料：

• http://www.w3.org/TR/2004/WD-i18n-html-tech-char-20040509/#IDAPNGO
• http://www.w3.org/International/tutorials/tutorial-char-enc/#exceptional

资料库文件结构

资料库中包含不同语种的翻译文件夹，文件夹名称如下：

• ISO 639 语言代码 （小写字母）
• 一个下划线
• ISO 3166-1 alpha-2 国家码 （大写字母）
• 如果文件夹是以上语种的其它脚本变体，则文件夹名称除以上三部分外，还应加上一个@符号，@后应加上ISO 15924脚本代码。

每个语言版本的文件夹中都包括Subversion的常规版本文件夹：branches/，tags/以及trunk/。

相应的版本文件夹中包含以下子文件夹：

messages/

• messages/
  • kubrick

该文件夹中包含目标语言的Gettext MO文件和PO文件。以语种名称命名信息文件。

在kubrick文件夹中，应将对默认主题的翻译存放在wordpress-i18n版本资料库中。还有另一种翻译默认主题的方式：

dist/

该文件夹中包含有 WordPress 版本中所有不能在 Gettext中翻译的 已翻译文件。

如果当前语言的本地化文件中只有一份UTF-8格式的文件，dist/文件夹可直接用于该翻译版本，dist的内部结构能够直接反映wordpress根目录的结构：

• dist/
  • license.html
  • readme.html
  • wp-config-sample.php
  • …
  • wp-admin/

    install.php

    upgrade.php

    …

如果当前语言的本地化文件中有多份UTF-8格式的文件，dist/中其它编码形式下也应具备相应的子文件夹：

• dist/
  • UTF-8/
    • license.html
    • readme.html
    • wp-config-sample.php
    • …
    • wp-admin/

      install.php

      upgrade.php

      …

  • ISO-8859-1

    …

• …

   

theme/

相较于使用theme/文件，翻译经过国际化的Kubrick主题（参见上文的messages/部分）更为方便。

类似于与dist/文件，theme/文件文件中也包含一些难以翻译的主题文件。如果theme/中只有一个UTF-8格式的文件，那么theme/文件夹可直接用于被翻译主题的子文件夹。这些子文件夹中的文件与原始主题中的文件完全相同（区别在于子文件夹中的文件是经过翻译的），并且连文件名也和原始主题中的文件完全相同：

• theme/
  • default/
    • 404.php
    • index.php
    • sidebar.php
    • ….
    • images/
      • …

和dist/文件夹一样，如果当前语言的本地化文件中有多种字符编码形式，theme/也应该为各种编码形式配备相应的子文件夹，子文件夹中又含有被翻译主题的各个子文件夹。

使用本地化的WordPress

要本地化所安装的WordPress，首先需要在wp-includes中新建一个文件夹并命名为languages（若languages文件尚未创建）。然后从WordPress版本管理库中挑选相应的本地化文件。所选语言文件的.mo文件和.po文件会被存放在languages文件夹下。在wp-config.php文件中，将WPLANG设为所选语言。例如，如果需要使用法语，则设为：

define ('WPLANG', 'fr_FR');

常见问题

Rosetta无法以MO文件形式导入我的翻译结果，只是说“系统出错。”，这是怎么回事？

你的翻译中有一个语法错误，阻碍了Rosetta将翻译编译成MO文件。下载PO并且试着用msgfmt手动编译PO文件。了解到出现错误的具体位置后，手动更改这些错误。如果没有安装GNU Gettext软件包，可以试着在poEdit或者 KBabel中打开PO文件，看看这样是否能够发现并更改错误，也可以发送电子邮件到wp-polyglots mailing list让其他人来帮你解决问题。

相关资料

• Ryan Boren’s Localizing Plugins and Themes

• Translating WordPress into another language (themes and plugins too)

分类：中文手册