wordpress更改语言
With the worldwide success and geographical reach of WordPress, it’s pretty easy to understand why it’s useful to be able to seamlessly translate plugins, themes and WordPress itself into other languages.
随着WordPress在全球范围内的成功发展和地理影响，很容易理解为什么能够无缝地将插件，主题和WordPress本身翻译成其他语言很有用。
However, that doesn’t necessarily make it easily adopted, and for good reason.
但是，这并不一定使它容易采用，这是有充分理由的。
Localization (or internationalization, as it is sometimes referred to) is the source of a lot of confusion and general angst for many a WordPress developer. After all, we’re web developers, right? We’re not linguistic experts, and it’s a lot easier to just apply labels to fields in our programs in plain English.
本地化(或国际化，有时被称为)是许多WordPress开发人员感到困惑和普遍焦虑的根源。 毕竟，我们是Web开发人员，对吗？ 我们不是语言专家，只用简单的英语将标签应用于程序中的字段会容易得多。
Plus, the notion of trying to figure out how to translate text strings into other languages on your own (much less having somebody else do it for you) might induce mild nausea in even seasoned developers who’ve never really had the need or inclination to do so before.
另外，试图弄清楚如何自行将文本字符串翻译成其他语言的想法(更不用说别人为您完成翻译了)，即使是从未真正有过需求或喜好的经验丰富的开发人员也可能引起轻微的恶心。这样做之前。
But trust me… it’s really not all that bad, and it can significantly increase the usefulness as well as the user-base of your custom WordPress plugins and themes. Let’s break it down into bite-sized pieces, starting with the foundations.
但是请相信我……这还不是很糟糕，它可以显着提高自定义WordPress插件和主题的实用性以及用户群。 让我们从基础开始，将其分解成小块。
The Basics of Internationalization & Localization
国际化和本地化的基础
Let’s examine that aforementioned development nausea just a bit. The way many of us learned to code, the notion of keeping language considerations in mind when coding a PHP program was, at best, rather academic.
让我们稍微检查一下上述发展恶心。 我们许多人学习编码的方式，在编写PHP程序时牢记语言考虑的概念充其量只是学术上的。
The majority of commercial coding projects have targeted scopes with defined audiences, and it’s often been a reasonable assumption to proceed without regard to translation.
大多数商业编码项目都有针对性的范围，并具有明确的受众，因此通常不考虑翻译就可以合理地进行下去。
However, since WordPress plugins and themes ultimately become much more useful when a user can use it in their own language, we need a systematic way to correct for this issue.
但是，由于WordPress插件和主题最终在用户可以使用其自己的语言使用时变得更加有用，因此我们需要一种系统的方法来更正此问题。
Enter i18n – another fun acronym to tuck under your belt. Named for the fact that there are 18 letters between the i and the n in the word “internationalization”, I18n describes the notion of creating software systems that are designed to be translated into other languages.
输入i18n –另一个有趣的首字母缩写，塞在皮带下。 以“国际化”一词中的i和n之间有18个字母命名，I18n描述了创建旨在翻译成其他语言的软件系统的概念。
The process of actually translating that software into a specific language is referred to as localization or l10n (can you guess how many letters are between the “l” and the “n” in the word “localization”?). WordPress utilizes a specific framework to handle i18n called GNU gettext – the de facto standard system that is used in nearly all open-source software. GNU gettext is really just a library of PHP helper functions.
将该软件实际翻译成特定语言的过程称为本地化或l10n (您能猜出“本地化”一词中“ l”与“ n”之间有多少个字母)。 WordPress利用一个特定的框架来处理称为GNU gettext的i18n，这是几乎所有开源软件中都使用的事实上的标准系统。 GNU gettext实际上只是PHP帮助程序函数的库。
Since it is coded right into core, WordPress has the hooks necessary to allow you as a developer to define text string variables in your themes and plugins, as well as a standardized system to provide translations for each string in an unlimited number of languages.
由于它是正确编码的，因此WordPress具有必要的钩子，使您作为开发人员可以在主题和插件中定义文本字符串变量，以及一个标准化的系统，可以为每种字符串提供无限数量的语言翻译。
Anatomy of a Localization Process
本地化过程的剖析
In general terms, the localization process is pretty straightforward. Conceptually, there are three key components to the process for either a theme or a plugin:
一般而言，本地化过程非常简单。 从概念上讲，主题或插件的过程包含三个关键组件：
using GNU gettext markers in your theme or plugin that lets WordPress know which strings to translate 在主题或插件中使用GNU gettext标记，使WordPress知道要翻译的字符串 a function linking the markers in your theme or plugin to a file that provides a translation key, and 将主题或插件中的标记链接到提供翻译键的文件的功能，以及 a file that providers a translation key, essentially creating and one-to-one relationship between translatable strings and what the translation should be for a given string. 提供翻译密钥的文件，本质上在可翻译字符串与给定字符串的翻译内容之间创建并一对一的关系。Let’s talk in a bit more detail about what each of these three components do.
让我们更详细地讨论这三个组件各自的功能。
Component #1: GNU gettext markers that let WordPress know which strings to translate
组件＃1：GNU gettext标记使WordPress知道要翻译的字符串
First of all, we need to let WordPress know what which strings we will want to translate. This is done directly in the output code of your theme or plugin by wrapping a specific string with a PHP function that identifies the type of localization you want to do, and then running your original string through a filter that will return the correct version.
首先，我们需要让WordPress知道我们要翻译哪些字符串。 这可以通过在主题或插件的输出代码中直接完成，方法是使用PHP函数包装一个特定的字符串，该函数标识您要执行的本地化类型，然后通过将返回正确版本的过滤器运行原始字符串。
While there are an array of functions that exist that allow you to define or output localized strings in different ways, there are really only two localization functions you will use the vast majority of the time:
虽然存在一系列允许您以不同方式定义或输出本地化字符串的函数，但实际上，您将在绝大多数时间中仅使用两个本地化函数：
__( 'string', $domain )This is a double underscore, and it returns a localized string.
这是一个双下划线 ，它返回一个本地化的字符串。
_e( 'string', $domain )This is an underscore “e”, and it prints out a localized string directly to the browser
这是一个下划线“ e” ，它直接在浏览器中打印出本地化的字符串
Note that both __ and _e take two parameters: a string and a domain. In this context, a domain is strictly a unique identifier and is nothing more than the label that is attached to a specific translation file. This relationship is defined in Component #2.
注意__和_e都带有两个参数：字符串和域。 在这种情况下，域严格来说是唯一的标识符，无非就是附加到特定翻译文件的标签。 此关系在组件2中定义。
Component #2: A function linking the markers in your theme or plugin to a file that provides a translation key
组件2：将主题或插件中的标记链接到提供翻译密钥的文件的功能
Within your theme or plugin, you’ll need to create a relationship between the strings you want to translate and a translation file that provides a key for the string translation.
在主题或插件中，您需要在要翻译的字符串和为字符串翻译提供密钥的翻译文件之间建立关系。
This is done using one of two PHP functions: load_theme_textdomain() for themes, or load_plugin_textdomain() for plugins.
这是使用以下两个PHP函数之一完成的：用于主题的load_theme_textdomain()或用于插件的load_plugin_textdomain() 。
In the case of theme localization, you’ll use load_theme_textdomain() in your functions.php file. The function takes two parameters as described below:
如果是主题本地化，则将在functions.php文件中使用load_theme_textdomain() 。 该函数采用两个参数，如下所述：
load_theme_textdomain( $domain, $path )$domain: A unique identifier assigned to a your custom translatable strings
$domain ：分配给您的自定义可翻译字符串的唯一标识符
$path: The path to your translation key file within the theme
$path ：主题中翻译密钥文件的路径
Theme localization keys off the WPLANG constant in wp-config.php, but we’ll discuss that in more detail later.
主题本地化在wp-config.php禁用了WPLANG常量，但是稍后我们将对其进行详细讨论。
Plugin localization works in a very similar to theme localization, but with a few differences. Set either within the core PHP files or the i18n-enabled plugin, load_plugin_textdomain() takes three parameters as described below:
插件本地化的工作原理与主题本地化非常相似，但有一些区别。 在核心PHP文件或启用i18n的插件中进行设置， load_plugin_textdomain()采用三个参数，如下所述：
load_plugin_textdomain( $domain, $abs_rel_path, $plugin_rel_path )$domain: A unique identifier assigned to a your custom translatable strings
$domain ：分配给您的自定义可翻译字符串的唯一标识符
$abs_rel_path: An optional, deprecated function as of WP 2.7. Default it to false or just omit it – it’s nothing to worry about
$abs_rel_path ：自WP 2.7起不推荐使用的可选功能。 将其默认设置为false或忽略它–无需担心
$plugin_rel_path: The relative path to your translation key file. If you fail to define this path, it’ll default to the root directory that the file is in. While this is by definition an optional parameter, it’s best practice to keep your language translation files separate from your logic files and so you’ll usually want to specify a value here.
$plugin_rel_path ：翻译密钥文件的相对路径。 如果无法定义此路径，则默认为文件所在的根目录。尽管根据定义，这是一个可选参数，但最佳做法是将语言翻译文件与逻辑文件分开，因此，通常要在此处指定一个值。
In both of these instances, $domain is the unique identifier that we referred to in Component #1, and serves only to define a relationship between the the strings in the code that require translation and Component #3, the translation key.
在这两种情况下， $domain是我们在组件＃1中引用的唯一标识符，并且仅用于定义需要翻译的代码中的字符串与组件＃3(翻译密钥)之间的关系。
Component #3: A file that providers a translation key
组件3：提供翻译密钥的文件
GNU gettext offers us a systematic way of both providing a mechanism to create one-to-one string translation relationships between individual default strings and their respective translations, and then feeding those various string translations to WordPress in an efficient manner. This is done through .PO and .MO files.
GNU gettext为我们提供了一种系统的方法，既提供了一种机制，可以在各个默认字符串及其各自的翻译之间创建一对一的字符串翻译关系，然后以有效的方式将这些各种字符串翻译提供给WordPress。 这是通过.PO和.MO文件完成的。
A .PO file is a file that provides a human-readable and editable translation key for a specific language. For instance, if your theme or plugin was written in English and you had translations readily available for French, German, and Pirate English, you would have three corresponding .PO files: one for each of the languages. When a specific string translation is made, it happens in this file.
.PO文件是为特定语言提供人类可读且可编辑的翻译密钥的文件。 例如，如果您的主题或插件是用英语编写的，并且可以轻松获得法文，德文和海盗英文的翻译，则您将拥有三个相应的.PO文件：每种语言一个。 进行特定的字符串翻译后，它会在此文件中发生。
While .PO files are human friendly and easily editable, they are not ideal to for WordPress to use while processing translation in practice. Instead, WordPress will use a .MO file for it’s actual translation. .MO files are compiled files that can be automatically generated for you when you use helper tools like Poedit. Each .PO file has a corresponding .MO file which is updated each time the .PO file is updated.
虽然.PO文件对人类友好并且易于编辑，但它们并不是WordPress在实际处理翻译时使用的理想选择。 取而代之的是，WordPress将使用.MO文件进行实际翻译。 .MO文件是已编译的文件，使用诸如Poedit之类的辅助工具时，这些文件会自动为您生成。 每个.PO文件都有一个对应的.MO文件，该文件在.PO更新.PO文件时都会更新。
The final file pertinent file type is the .POT file, or .PO Template file. A .POT file is a special kind of .PO file that is an exact copy of any of the .PO files in a localization instance with the exception that it is void of any translations. Making .POT files available to translators allows anybody to easily create translations for your themes and plugins into their own native language using helper tools.
最终文件相关的文件类型是.POT文件或.PO模板文件。 一个.POT文件是一种特殊的.PO文件，它是任何的精确副本.PO文件与异常的本地化实例，它是无效的译文。 通过将.POT文件提供给翻译人员，任何人都可以使用帮助器工具轻松地将主题和插件翻译成自己的母语。
Putting the pieces together
拼凑在一起
So now that we know the main components in a localization process, let’s have a visual look at how they work together in WordPress. Consider the following diagram:
因此，既然我们知道了本地化过程中的主要组件，我们就可以直观地了解它们在WordPress中如何协同工作。 考虑下图：
We’ll start with the program’s source code.
我们将从程序的源代码开始。
When a browser initially moves to call a specific page, the translation process is initiated when it recognizes the __() and _e() functions in the source code wrapping text strings.
当浏览器最初移动以调用特定页面时，翻译过程将在它识别包裹文本字符串的源代码中的__()和_e()函数时启动。
WordPress recognizes these functions because GNU gettext is built into core, and automatically seeks to translate them. Your functions.php file has already been loaded at this time, and WordPress is able to use the load_plugin_textdomain() or load_theme_textdomain() functions in the functions.php file to identify the connect the strings to a library location (Depicted in Step 1 in the diagram above).
WordPress可以识别这些功能，因为GNU gettext内置在核心中，并会自动尝试翻译它们。 您的functions.php文件目前已加载，并且WordPress能够使用functions.php文件中的load_plugin_textdomain()或load_theme_textdomain()函数来标识将字符串连接到库位置(如上图) 。
load_plugin_textdomain() or load_theme_textdomain() then retrieve the locale information from the WPLANG Constant set in wp-config.php (Step 2 in the diagram above) and retrieve the proper .MO file associated with the locale (Step 3 in the diagram above).
load_plugin_textdomain()或load_theme_textdomain()从wp-config.php设置的WPLANG常量中检索语言环境信息( WPLANG 步骤2)，并检索与该语言环境关联的正确的.MO文件(上图中的步骤3)。 。
If the properly named .MO exists, the functions output the translated strings to the browser (Step 4 in the diagram above).
如果存在正确命名的.MO ，则这些函数将转换后的字符串输出到浏览器(上图中的第4步) 。
If a properly named .MO file does not exist, or for any strings that do not have translated entries within the .MO file, the default verbiage is instead output to the browser.
如果不存在正确命名的.MO文件，或者对于.MO文件中没有转换条目的任何字符串，则将默认.MO输出到浏览器。
Finally, the .MO file is a compiled version of a .PO file, which is human editable. Likewise, .PO files have template files that allow translators to easily modify strings in your program into other languages.
最后， .MO文件是一个编译版本.PO文件，这是人类可编辑的。 同样， .PO文件具有模板文件，这些文件使翻译人员可以轻松地将程序中的字符串修改为其他语言。
Looks like I don’t have enough room in this article to illustrate all this with some examples that really bring the whole conceptual process to life in WordPress, but I’ll follow up with another article that digs into the actual code involved next week.
看起来我在本文中没有足够的空间来通过一些示例真正说明整个概念过程在WordPress中的实现来说明所有这些，但是我将在下周继续研究另一篇文章，以深入探讨所涉及的实际代码 。
翻译自: https://www.sitepoint.com/language-fluency-in-wordpress-understanding-the-basics-of-i18n/
wordpress更改语言
相关资源：i18n-command：为WordPress项目提供国际化工具-源码