Manual:语言
- 另可参见Manual:MediaWiki架构#语言(是否应合并至此?)
在MediaWiki中,有各种语言:
- 网站内容语言(
ContentLanguage
,基于$wgLanguageCode
),只要维基存在,通常应保持不变。- 网站内容语言变体($wgDefaultLanguageVariant )是为该语言实现LanguageConverter 时的默认变体。
- 用户界面语言($contextSource->getLanguage(),以前是
$wgLang
),可以在您的首选项中更改,或在URL中使用&uselang=xyz
,但在使用wiki时通常也应保持不变。
- 页面内容语言。即使站点和用户语言相同,每个页面也可能不同。它在Title中的getPageLanguage()中定义,表示wiki文本源的编写语言。
- 页面查看语言又名用户语言变体,它是页面内容语言的语言变体,由用户首选。它也可以通过URL中的
&variant
(或$wgVariantArticlePath
)进行设置(例如,通过选择其中一个选项卡),如果它是页面的内容语言的变体查看。它在标题中的getPageViewLanguage()中定义,表示呈现的HTML内容的语言。
- 页面查看语言又名用户语言变体,它是页面内容语言的语言变体,由用户首选。它也可以通过URL中的
所有这三个都是语言对象。
语言代码
语言代码是MediaWiki支持的语言的有效标准缩写,[1]使用此类代码作为语言的标准标识符(大多数符合ISO 639-3,除了ISO 639-1的“已建立”区域设置的双字母代码)并公开或要求它们接口和代码的许多要点。[2]
在下面的示例中,MediaWiki:Message/ar
,ar
是العربية语言代码。
需要使用Unicode标准的一致性来提供良好的语言支持,特别是与CLDR合作,拥有ISO 639-3代码的是要求添加到MediaWiki语言环境的语言。
Names.php
Names.php是MediaWiki支持的语言的主注册表。 请注意,这与MediaWiki将显示l10n的语言(JSON文件)或MediaWiki已知名称的语言(通过拓展:CLDR )不同。
备选语言
MediaWiki中的某些语言具有所谓的“后备序列”。如果MediaWiki无法找到所需的语言,那么这将是另一种语言。这方面的一个例子是语言代码frc
(Cajun French),它依赖于语言代码fr
(法语)。这样做的原因是有时语言中没有定义所有消息。
语言的后备可以在其关联的languages/messages/MessagesXX.php
文件中找到。
例如MessagesFrc.php。您可以搜索所有用途的代码。 在這個phabricator評論中還有一個來自2020年9月的簡單列表。
站点内容语言
- 查看/获取站点语言
mw.config.get( 'wgContentLanguage' );
用户界面语言
MediaWiki版本: | ≥ 1.18 |
- 设置通过
- Special:Preferences
&uselang=zxx
在URL(见uselang)&variant=xy
(或$wgVariantArticlePath
)在网址如果它是您的用户语言的变体
- 问题
- 由于接口消息可能来自后备语言,但未返回语言,因此不知道每条消息的实际语言。
页面内容语言
MediaWiki版本: | ≥ 1.18 |
- 默认值
- $wgLang在特殊页面上。
- CSS和JS页面的英文。
- 对于MediaWiki命名空间页面,该语言取决于子页面。例如,MediaWiki:Message/ar将设置为阿拉伯语(ar),MediaWiki:Message将为
ContentLanguage
。 - 所有其他页面默认为
ContentLanguage
。
- 配置
- 扩展可以通过PageContentLanguage 钩子更改所有其他页面。 无法覆盖特殊页面、CSS、JS和MediaWiki命名空间页面的值。
- 例子
- 翻译扩展将其用于页面翻译功能。参见translatewiki:Project:About/ar作为translatewiki:Project:About的翻译。 因此,对于阿拉伯语,页面的方向性被正确地设置为从右到左。
MediaWiki版本: | ≥ 1.24 |
- 手动更改页面语言
- 自MediaWiki 1.24以来,借助Special:PageLanguage,现在可以实现页面语言选择。
- 用户可以更改页面的内容语言,默认情况下是默认的Wiki语言(
ContentLanguage
)。无法更改MediaWiki名称空间中页面的语言。 - 需要使用
$wgPageLanguageUseDB = true
启用该功能,并且需要为pagelang
设置权限。權限必須授予wiki用戶權限組(然後他們可以執行頁面語言更改)。 - 更改页面语言会使源翻译页面及其单位移动到正确的目标语言。如果目标语言翻译页面已存在,则不允许更改语言。
- 相应的API可以在API:设置页面语言 上找到。
- 它定义了什么?
- 在SkinTemplate中,它在页面文本周围添加了
<div lang="xyz" dir="ltr/rtl" class="mw-content-ltr/rtl"></div>
。dir属性设置正确的写入方向。lang属性将始终是根代码,例如 “de”即使是“de-formal”。- 对于文件页面,它在ImagePage.php中设置,因为有很多用户语言的HTML。
- 在Parser.php中,它设置目录(TOC)编号和语法之类的东西,尽管大多数情况下并不真正相关。要做到这一点,请使用parserOptions->setTargetLanguage()。
- diff文本的方向(DifferenceEngine)设置为页面内容语言。在某些情况下,这不相同,在这种情况下可以使用$diffEngineObject->setTextLanguage($code)。
- 从1.19开始,它还设置时间和数字格式魔术字,包括方向标记,但不包括名字空间,因为真的取决于网站语言。请注意,在带有语言B的页面上包含标记为语言A的模板,将在该页面上使用语言B进行解析。
- 在SkinTemplate中,它在页面文本周围添加了
- 单个页面上的多种语言
- 理论上不支持单个页面上的多种语言,但这很简单
<div lang="xyz" dir="ltr/rtl" class="mw-content-ltr/rtl">
标签可用于将文本标记为使用其他语言编写。如果使用CSS类,当dir标记与页面内容语言的值相反时,ul/ol列表和编辑部分将很好地显示。然而,解析器中定义的内容(如TOC和魔术词)不会改变。
- 查看/获取页面语言
- JavaScript:
mw.config.get( 'wgPageContentLanguage' )
:请注意,例如查看页面历史记录,它将返回它是历史记录的页面的页面语言,而历史记录页面没有mw-content-ltr/rtl类。即/wiki/Page和/w/index.php?title=Page&action=history都将返回Page的语言。 1.19+ - 页面信息视图中提到了页面内容语言(
action=info
,在工具箱中链接) 1.21+ - 可以通过api.php?action=query&prop=info在API中检索页面内容语言 1.22+
Code structure
First, you have a Language object in Language.php . This object contains all the localisable message strings, as well as other important language-specific settings and custom behavior (uppercasing, lowercasing, printing dates, formatting numbers, direction, custom grammar rules etc.).
The object is constructed from two sources: sub-classed versions of itself (classes) and Message files (messages).
There's also the MessageCache class, which handles input of text via the MediaWiki namespace.
Most internationalisation is nowadays done via Manual:Messages API objects and by using the wfMessage()
shortcut function, which is defined in includes/GlobalFunctions.php
.
Legacy code might still be using the old wfMsg*()
functions, which are now considered deprecated in favor of the above-mentioned Message objects.
See also Manual:Messages API .
Language objects
There are two ways to get a language object.
You can use the globals $wgLang and ContentLanguage
service (MediaWiki\MediaWikiServices::getContentLanguage
) for user interface and content language respectively.
For an arbitrary language you can construct an object by using $languageFactory->getLanguage( 'en' )
by replacing en
with the code of the language.
You can get $languageFactory
, an object of the MediaWiki\Languages\LanguageFactory
class, using Dependency Injection .)
You can also use wfGetLangObj( $code );
if $code
could already be a language object.
The list of codes is in includes/languages/data/Names.php
.
Language objects are needed for doing language-specific functions, most often to do number, time and date formatting, but also to construct lists and other things. There are multiple layers of caching and merging with #Fallback languages, but the details are irrelevant in normal use.
Old local translation system
With MediaWiki 1.3.0, a new system was set up for localising MediaWiki.
Instead of editing the language file and asking developers to apply the change, users could edit the interface strings directly from their wikis.
This is the system in use as of August 2005.
People can find the message they want to translate in Special:AllMessages and then edit the relevant string in the MediaWiki:
namespace.
Once edited, these changes are live.
There was no more need to request an update, and wait for developers to check and update the file.
The system is great for Wikipedia projects; however a side effect is that the MediaWiki language files shipped with the software are no longer quite up-to-date, and it is harder for developers to keep the files on meta in sync with the real language files.
As the default language files do not provide enough translated material, we face two problems:
- New Wikimedia projects created in a language which has not been updated for a long time, need a total re-translation of the interface.
- Other users of MediaWiki (including Wikimedia projects in the same language) are left with untranslated interfaces.
This is especially unfortunate for the smaller languages which don't have many translators.
This is not such a big issue anymore, because translatewiki.net is advertised prominently and used by almost all translations. Local translations still do happen sometimes but they're strongly discouraged. Local messages mostly have to be deleted, moving the relevant translations to translatewiki.net and leaving on the wiki only the site-specific customisation; there's a huge backlog especially in older projects, this tool helps with cleanup.
Keeping messages centralised and in sync
English messages are very rarely out of sync with the code. Experience has shown that it's convenient to have all the English messages in the same place. Revising the English text can be done without reference to the code, just like translation can. Programmers sometimes make very poor choices for the default text.
What can be localised
So many things are localisable on MediaWiki that not all of them are directly available on translatewiki.net : see translatewiki:Translating:MediaWiki. If something requires a developer intervention on the code, you can request it on Phabricator, or ask at translatewiki:Support if you don't know what to do exactly.
- Namespaces - both core and extensions, plus gender-dependent user namespaces
- Weekdays (and abbreviations)
- Months (and abbreviations)
- Bookstores for Special:BookSources
- Skin names
- Math names
- Date preferences -
$datePreferences
- Date formats -
$dateFormats
- Default date format -
$defaultDateFormat
- Date preference migration map - for compatibility with old MediaWiki databases
- Default user option overrides
- Language names
- Country names (via 拓展:CLDR )
- Currency names (via 拓展:CLDR )
- Timezones
- Character encoding conversion via
iconv
- UpperLowerCase first (needs casemaps for some)[clarification needed]
- UpperLowerCase[clarification needed]
- Uppercase words
- Uppercase word breaks[clarification needed]
- Case folding[clarification needed]
- Strip punctuation for MySQL search (search optimisation)
- Get first character
- Alternate encoding
- Recoding for edit (and then recode input)[clarification needed]
- Fallback languages (that is, other more closely related language(s) to use when a translation is not available, instead of the default fallback, which is English)
- Directionality (left to right or right to left, RTL)
- Direction mark character depending on RTL
- Arrow depending on RTL
- Languages where italics cannot be used
- Number formatting (comma-ify, i.e. adding or not digits separators; transform digits; transform separators)[3]
- Truncate (multibyte)
- Grammar conversions for inflected languages
- Plural transformations
- Formatting expiry times[clarification needed]
- Segmenting for diffs (Chinese)
- Convert to variants of language (between different orthographies, or scripts)
- Language specific user preference options
- Link trails and link prefix -
$linkTrail
. These are letters that can be glued after/before the closing/opening brackets of a wiki link, but appear rendered on the screen as if part of the link (that is, clickable and in the same colour), e.g.:[[foo]]bar
. By default the link trail is "a-z"; you may want to add the accentuated or non-Latin letters used by your language to the list. - Language code (preferably used according to the latest RFC in standard BCP 47, currently RFC 5646, with its associated IANA database. Avoid deprecated, grandfathered and private-use codes: look at what they mean in standard ISO 639, and avoid codes assigned to collections/families of languages in ISO 639-5, and ISO 639 codes which were not imported in the IANA database for BCP 47)
- Type of emphasising
- The 扩展:引用 extension has a special page file per language,
cite_text-zyx
for language codezyx
.
Neat functionality:
- I18N
sprintfDate
- Roman numeral formatting
Namespaces
Currently making namespace name translations is disabled on translatewiki.net, so you need to do this yourself in Gerrit, or file a Phabricator task asking for someone else to do it.[4]
To allow custom namespaces introduced by your extension to be translated, create a MyExtension.i18n.namespaces.php
file that looks like this:
<?php
/**
* Translations of the namespaces introduced by MyExtension.
*
* @file
*/
$namespaceNames = [];
// For wikis where the MyExtension extension is not installed.
if( !defined( 'NS_MYEXTENSION' ) ) {
define( 'NS_MYEXTENSION', 2510 );
}
if( !defined( 'NS_MYEXTENSION_TALK' ) ) {
define( 'NS_MYEXTENSION_TALK', 2511 );
}
/** English */
$namespaceNames['en'] = [
NS_MYEXTENSION => 'MyNamespace',
NS_MYEXTENSION_TALK => 'MyNamespace_talk',
];
/** Finnish (Suomi) */
$namespaceNames['fi'] = [
NS_MYEXTENSION => 'Nimiavaruuteni',
NS_MYEXTENSION_TALK => 'Keskustelu_nimiavaruudestani',
];
Then load it from the extension.json
file using ExtensionMessagesFiles like this:
{
"name": "MyExtension",
"version": "0.0.1",
"descriptionmsg": "myextension-desc",
"ExtensionMessagesFiles": {
"MyExtensionNamespaces": "MyExtension.i18n.namespaces.php"
}
}
Now, when a user installs MyExtension on their Finnish (fi) wiki, the custom namespace will be translated into Finnish magically, and the user doesn't need to do a thing!
Also remember to register your extension's namespace(s) on the extension default namespaces page.
Special page aliases
See the manual page for Special pages for up-to-date information. The following does not appear to be valid.
Create a new file for the special page aliases in this format:
<?php
/**
* Aliases for the MyExtension extension.
*
* @file
* @ingroup Extensions
*/
$aliases = [];
/** English */
$aliases['en'] = [
'MyExtension' => [ 'MyExtension' ]
];
/** Finnish (Suomi) */
$aliases['fi'] = [
'MyExtension' => [ 'Lisäosani' ]
];
Then load it from the extension.json
file using ExtensionMessagesFiles like this:
{
"name": "MyExtension",
"version": "0.0.1",
"descriptionmsg": "myextension-desc",
"ExtensionMessagesFiles": {
"MyExtensionAlias": "MyExtension.i18n.alias.php"
}
}
When your special page code uses either SpecialPage::getTitleFor( 'MyExtension' )
or $this->getTitle()
(in the class that provides Special:MyExtension), the localised alias will be used, if it's available.
Namespace name aliases
Namespace name aliases are additional names which can be used to address existing namespaces. They are rarely needed, but not having them when they are, usually creates havoc in existing wikis.
You need namespace name aliases:
- When a language has variants, and these variants spell some namespaces differently, and you want editors to be able to use the variant spellings.
Variants are selectable in the user preferences. Users always see their selected variant, except in wikitext, but when editing or searching, an arbitrary variant can be used.
- When an existing wiki's language, fall back language(s), or localisation is changed, with it are changed some namespace names.
So as not to break the links already present in the wiki, that are using the old namespace names, you need to add each of the altered previous namespace names to its namespace name aliases, when, or before, the change is made.
The generic English namespace names are always present as namespace name aliases in all localisations, so you need not, and should not, add those.
Aliases can't be translated on Translatewiki.net , but can be requested there or on Bugzilla : see translatewiki:Translating:MediaWiki#Namespace name aliases.
Regional settings
Some linguistic settings vary across geographies; MediaWiki doesn't have a concept of region, it only has languages and language variants.
These settings need to be set once as a language's default, then individual wikis can change them as they wish in their configuration.
Time and date formats
Time and dates are shown on special pages and alike. The default time and date format is used for signatures, so it should be the most used and most widely understood format for users of that language. Also anonymous users see the default format. Registered users can choose other formats in their preferences.
If you are familiar with PHP's time() format, you can try to construct formats yourself. MediaWiki uses a similar format string, with some extra features. If you don't understand the previous sentence, that's OK. You can provide a list of examples for 开发者 .
注释
- ↑ 参见includes/languages/data/Names.php。
- ↑ 尽管如此,截至2012年,语言代码验证尚未解决。见2012年8月28日的NiklasLaxström的MediaWiki语言验证。
- ↑
These are configured by language in the respective
language/classes/LanguageXx.php
orlanguage/messages/MessagesXx.php
files. - ↑ https://gerrit.wikimedia.org/r/211677
参见
- 多语言MediaWiki
- 使用魔术字中记录的核心函数{{#language:<code>}},可以从代码中获取语言名称。