多言語対応のテンプレートとモジュール

This page is a translated version of the page Multilingual Templates and Modules and the translation is 13% complete.

このページでは、「グローバル、クロスウィキ、多言語対応のモジュールとテンプレート」の作成方法と、ウィキメディアの複数のウィキでそれらを同期させる方法について説明しています。

Synchronizer ツールは、ウィキ間でモジュールを最新の状態に保つために使用されます。

これが必要である理由は? 私たちは単一のウィキペディアを持っているわけではなく、300 以上の別々のウィキペディアやその他のウィキプロジェクトが存在しています。そして、誰かがいい新しいテンプレートや Lua モジュールを作成するたびに、それが 300 回以上コピーされ、翻訳されます。各翻訳者は MediaWiki マークアップを十分に理解する必要があり、コピー作業は非常に手間がかかり、エラーが起こりやすいです。これはテンプレート作成者が、自分のテンプレートが 1 つの言語でしか使われないと考えることが多いためです。コピーされた後、元のテンプレートは改善されることが多く、各コピーはすべての既存の翻訳を保持しながら更新しなければなりません。テンプレートやモジュールのコピーには非常に高い人的コストがかかり、そのため、多くはコピーされることも更新されることもありません。特に小規模なウィキでは、この負担が大きいため、維持や更新が難しくなります。

これは最善のアプローチですか? 現在の技術では、このアプローチが最善です。システムレベルでこれを可能にするためには、MediaWiki の大規模な書き換えが必要です。マルチサイトテンプレートは2001年から要求されていますが、この問題が解決困難であるため、ほとんど何も行われませんでした。このアプローチでは現在でも多言語コンテンツを作成でき、MediaWiki がサポートを提供すれば、新しいシステムへの移行が簡単に行えます。

例

Here are some examples of Lua modules that have been globalized and are being kept in sync across wikis using the Synchronizer tool:

Module:Excerpt (Q52428273-enwiki)
Module:Transcluder (Q96679044-enwiki)
Module:Cycling race (Q21707933-wikidatawiki)
Module:TNT (Q28132212-mediawikiwiki)

General method

To make a global module:

Design or redesign the module so as to provide ways for wikis to localize everything they may need to localize, without having to modify the source code. This page describes several techniques to accomplish this.
Use the Synchronizer tool to keep the source code identical across Wikimedia wikis.

Best practices

This section describes some of the current best practices to develop global modules.

Naming

This section can be ignored for modules designed to be called from templates only.

Global modules that are meant to be used by other modules should be named the same in all wikis to avoid dependency breaks with other global modules. For example, if a module named A requires a module named B, but in some wiki, module B is named C, then module A will not work in that wiki, unless the source code of module A is changed locally to require C instead of B, which would defeat globalization (of module A).

If a local community does not accept the global name, or renaming is too much trouble, then a workaround is to create a "redirect module" with the global name, that simply requires and returns the module with the local name.

Fortunately, the fact that the Module namespace is named differently in each language doesn't break dependencies, because "Module" is an alias for the Module namespace in all languages.

Master module

Global modules should pick one wiki where to do the development. Generally this will be the home wiki of the module, but it may migrate for various reasons, for example to increase the chances of recruiting new developers by centralizing the development in a larger or more appropriate wiki.

Global modules should start with a comment that includes a link to the master module, to reduce the chances of forking and help recruit new developers (example).

Sandbox

Global modules should have a /sandbox subpage where to test out changes before deploying them to the master module and the other wikis (example).

Testcases

Global modules should have a /testcases subpage with good unit tests to ensure high quality and stability of the module (example). Test cases should:

Use Module:ScribuntoUnit
Run with both the main module and the sandbox versions, so that we can compare the results (example)
Use require('strict') to avoid accidentally using non-declared variables
Output results both in /testcases/doc and the main /doc page of the module, to catch errors as early as possible

Documentation

Global modules should have a /doc subpage with documentation of all public functions of the module (example) and a section with the testcase runs for both the primary and the sandbox versions of the module (example).

Configuration

Global modules that require configuration should have a separate /config submodule to prevent local wikis from modifying the source code to configure the module (example).

Synchronization

Once a module is able to be copied unchanged to other wikis, the Synchronizer tool can be used to copy it and keep it synced across all Wikimedia wikis.

Backwards compatibility

Global modules should generally keep development backwards-compatible, because changes that are not backwards-compatible will often require manual updates to each and every wiki, template and module that uses the module.

Localization of template parameters

Global modules can have their parameters localized by the template callers. For example, consider the following module that simply outputs the given text (or "Example" if none is given):

local p = {}

function p.main(frame)
 	 local args = frame.args
 	 local text = args['text'] or 'Example'
 	 return text
end

return p

Then a Spanish template would localize the module like so:

{{#invoke:Example|main
| text = {{{texto|Ejemplo}}}
}}

Notice that the template not only localizes the name of the "text" parameter ("texto" means "text" in Spanish), but also the default text ("Ejemplo" means "Example" in Spanish).

See Plantilla:Extracto for a real case of a template that localizes a global module with this technique. Also, see Template:Excerpt for a case where a global module is localized to the English Wikipedia, demonstrating that localization is not always the same as translation.

Localization of user-readable strings

Many modules need to output user-readable strings, such as error messages and interface elements (like buttons). Hard-coding the text of these strings forces other wikis to modify the code in order to localize them, preventing globalization. To avoid this, developers should provide ways to localize user-readable strings without having to modify the code itself. This section explains several ways to accomplish this.

Template parameters

User-readable strings can be localized through template parameters when calling the module. This approach is convenient when:

The text is likely to vary with each template call
The text is likely to be changed by users when calling the template
The text is likely to contain a magic word, a template call, a parser function or some other wiki element

An example of a module using this approach would be:

local p = {}

function p.main(frame)
 	 local args = frame.args
 	 local text = args['text'] or 'Example'
 	 return text
end

return p

This way, every template may modify the text when calling the module, like so:

{{#invoke:Example|main
| text = Ejemplo
}}

Notice that in this example, if a template calls the module without specifying the text parameter, then the hard-coded English text 'Example' would be used. This is not necessary. Modules may require template callers to set the text parameter by throwing an error if they don't. However, it's often friendlier to have a fallback.

Config file

Another way to localize user-readable strings is through a separate /config subpage. This approach is convenient when:

The module is meant to be called by many templates per wiki, thus allowing localization to be done only once and then reused
There're many messages to localize, so it's easier to have them all together in their own place
There's already a need for a /config file for other reasons, so we might as well use it for localization too

An example of a module using this approach would be:

local config = require('Module:Example/config')

local p = {}

function p.main(frame)
 	 local text = config.text or 'Example'
 	 return text
end

return p

Then wikis would be able to create /config files like the following:

return {
 	 text = 'Ejemplo'
}

Translation tables

Another way to localize user-readable strings is through a central translation table at Commons. This approach is convenient when:

The strings should vary with the preferred language of the user, rather than the language of the wiki or page.
We want to centralize localization efforts on a single page.

The Module:TNT was created specifically to get strings from translation tables. An example module using TNT could look like this:

local TNT = require('Module:TNT')

local p = {}

function p.main(frame)
 	 local text = TNT.format('I18n/Example', 'text')
 	 return text
end

return p

See Data:I18n/Template:Graphs.tab for a simple but real example of a translation table with two messages, each having a single parameter. It's important to store parameters as parts of the strings because in many languages the parameter would have to be placed at a different position in the string according to the norms of the language.

Translation tables should start with the "Data:I18n/..." prefix to separate them from other types of tabular data. If a message has not yet been localized, TNT will fall back to English (or other fallback language as defined by the language's fallback sequence ). TNT also supports all standard localization conventions such as {{PLURAL|...}} and other parameters .

One downside of this approach is that it requires installing and setting up Extension:JsonConfig , which may not have been done on non-Wikimedia wikis, limiting the ability to reuse these modules on third-party wikis.

MediaWiki messages

In some cases, MediaWiki itself (or some extension) may have the messages we need already localized. For example, if we need the string "New page" we may use MediaWiki:Newpage, like so:

local p = {}

function p.main(frame)
 	 local msg = mw.message.new('newpage')
 	 local text = msg:plain()
 	 return text
end

return p

See Special:AllMessages for a list of all available messages.

All of the above

Depending on the case, all of the above methods may be combined. For example, MediaWiki messages may be used when available, and when not, a translation table or config file is queried, and if no localization is found there, then a hard-coded English text is used, unless a template parameter overrides it.

Combining several methods can be effective, but the benefits should be weighted against the downsides of the increased complexity, which may cause performance loss and bugs, as well as more difficulty in maintaining the code and recruiting new developers.

Template data

Template parameters are usually stored as a JSON templatedata block inside the template's /doc subpage. This makes it convenient to translate, but when a new parameter is added to a global template, all /doc pages need to be updated in every language. Module:TNT helps with this by automatically generating the templatedata block from a table stored on Commons. Placing the following line into every /doc subpage will use Data:Templatedata/Graph:Lines.tab table to generate all the needed templatedata information in every language. Even if the local community has not translated the full template documentation, they will be able to see all template parameters, centrally updated.

{{#invoke:TNT|doc|Graph:Lines}}