Manual:Language/ja


 * Manual:MediaWiki architecture#Languages も参照してください (このページに統合すべきかも)

MediaWiki には、さまざまな種類の言語があります:


 * サイトの本文の言語（ に依拠する ）とは通常、ウィキが存在する限り不変であるべきです.
 * サイト本文の言語の変種 とは  を実行したときに既定となるものです.
 * ユーザー インターフェイスの言語（$contextSource->getLanguage、旧来の ）は本来はウィキの利用中一意であり、個人設定もしくはURLの で指定を変更できます.
 * ページ内容の言語について. これはサイトとユーザー言語が同じでもページごとに異なることがあります. 定義はTitleのgetPageLanguageに示してあり、ウィキ文の原文を記した言語を示します.
 * ページ表示言語ないしはユーザー言語の変種とはページの本文言語の変種で、ユーザーが選んだものです. これももし表示中のページのページ本文言語の変種であるなら、設定は変更でき、URLの （またはを例えばタブのひとつを選んで指定できます. 定義はTitleのgetPageViewLanguageにあり、HTMLを解析して本文の記述言語を示します.

これら3つすべてを指して言語オブジェクトと呼びます.

言語コード

 * Wikimedia project codeのことではありません. メタのLanguage codesも参照

言語コードとはMediaWikiがサポートする言語の有効な標準略称であり 、用いるコードは言語の標準識別子 （ほぼISO 639-3に準拠し例外は「定着した」ロケール用のISO 639-1準拠の2文字コード）をインターフェイスとコーディングでしばしば提示または要求されます.

下記の例  では、  が  (訳注: アラビア語) の言語コードです.

適切な言語サポートを行うにはユニコード標準との統一、わけてもCLDRとの連携が欠かせません. MediaWikiロケールに特定の言語を追加する必須条件は該当するISO 639-3 コードがあることです.

Names.php
is the master registry of languages supported by MediaWiki. This is not the same as languages of which MediaWiki will show l10n (JSON files) nor languages of which MediaWiki knows the names (via ), mind you!

フォールバック言語
MediaWiki の言語版により「代替方式」を用意しています. もし使用言語で必要な定義がない時は、MediaWikiが別の言語で表示されます. 一例として言語コード （ケージャン・フランス語）は （フランス語）で代替します. この処置は言語版によって定義していないメッセージを補うためです.

言語の代替は、対応する言語の  ファイル内に記述されています. For instance. You can search the code for all uses. There is also a plain list from in this Phabricator comment.

サイトのコンテンツ用言語
サイトのコンテンツ言語の閲覧/取得



ユーザーインターフェイスの言語

 * 既定値
 * $contextSource->getLanguage


 * 変更する方法


 * Special:Preferences (個人設定)
 * URL で  の形式で指定する (uselang を参照)
 * URLを設定できる （または ）は、それがユーザー言語の言語変種である場合に限定


 * 問題
 * インターフェースのメッセージの言語が代替されても、どの言語と代替したのか返さないため、メッセージ単位で実際に使われた言語は判別できません.

ページの本文言語

 * 既定値


 * 特別ページの言語は $wgLang です.
 * CSS ページおよび JS ページは英語です.
 * MediaWiki 名前空間のページでは、言語は下位ページによって異なります. 例えば、MediaWiki:Message/ar はアラビア語 (ar) になり、MediaWiki:Messsage は  になります.
 * その他のページはすべて、既定では  です.


 * 構成
 * 拡張機能は フックを使用し、その他のページを一括して変更します.  特別ページ、CSS、JS および MediaWiki 名前空間のページの値はオーバーライドされません.


 * 例
 * Translate extensionではページ翻訳機能に利用. 一例としてtranslatewiki:Project listの訳文translatewiki:Project list/arを見ると、アラビア語の書字方向は正しく反映され左書き.


 * Manually changing page language
 * Page language selection is now achievable with help of Special:PageLanguage since MediaWiki 1.24.


 * Users can change content language of a page which is by default the default Wiki language . Language of pages in the MediaWiki namespace can't be changed.


 * The feature needs to be enabled with  and the   permission must be granted to a wiki user rights group (who can then perform page language changes).


 * Changing page language causes the source translation page and its units to be moved to the correct target language. In case the target language translation page already exists, the language change isn't allowed.


 * Matching API can be found on.


 * 定義する対象


 * SkinTemplate (外装) ではページの文字表示について  を追加します. dir属性によりwriting direction (書字方向) が正しく設定されます. lang属性は例えば「de」に対して「de-formal」が出力されても、常にルートのコードを取ります.
 * ファイルページにおいては、ユーザー言語にHTML記述が多いため、設定はImagePage.phpで行います.
 * Parser.phpは見出し一覧(TOC) の付番や文法を設定するものの、本文言語にはほとんど影響しません. もし本文言語のみ設定するのなら、使用するのはparserOptions->setTargetLanguageです.
 * diff 文の書字方向 (DifferenceEngine) はページの本文言語に設定されます. 場合によってはこの2つが一致せず$diffEngineObject->setTextLanguage ($code) を代用します.
 * 以降は時刻と数字の設定マジックワードのうち、サイトの言語設定の規制によりDIRECTIONMARKを対象に、NAMESPACE(E)は対象外にしています. これは言語Bを用いるページにおいて言語Aを指定するテンプレートがあったとしても、対象のページでは言語Bで処理されるということを指します.


 * 複数言語を用いた単一ページ
 * 単一のページに複数言語を使った場合には原則は適用外ですが、文が他の言語で記述されたとマークするには

単純な  タグを使用できます. CSSクラスを適用した場合は、dirタグがページの本文言語の値と衝突してもul/ol 一覧とeditsectionは正しく表示されます. しかしながらパーサーで定義する見出し一覧（TOC）やマジックワードなどの要素に影響はありません.


 * ページ言語の閲覧/取得

mw-content-ltr/rtlクラスの設定がない点が要注意. つまり「/wiki/Page」と「/w/index.php?title=Page&action=history」が返すのは、どちらも「Page」の言語.
 * JavaScript:  - 例えばページの変更履歴の閲覧では履歴が該当ページの本文言語で表示されるものの、変更履歴ページそのものには
 * ページの本文言語はページの情報表示に定義 (ツールボックスのリンク )
 * ページの本文言語はapi.php?action=query&prop=infoを介してAPIで取得

Code structure
First, you have a Language object in. 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 objects and by using the   shortcut function, which is defined in. Legacy code might still be using the old  functions, which are now considered deprecated in favor of the above-mentioned Message objects.

も参照してください.

Language objects
There are two ways to get a language object. You can use the globals and   service  for user interface and content language respectively. For an arbitrary language you can construct an object by using by replacing   with the code of the language. You can get, an object of the class, using .)  You can also use   if   could already be a language object.  The list of codes is in.

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  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:

This is especially unfortunate for the smaller languages which don't have many translators.
 * 1) New Wikimedia projects created in a language which has not been updated for a long time, need a total re-translation of the interface.
 * 1) Other users of MediaWiki (including Wikimedia projects in the same language) are left with untranslated interfaces.

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, [//toolserver.org/~robin/?tool=cleanuplocalmsgs 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 : 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
 * - for compatibility with old MediaWiki databases
 * Default user option overrides
 * 言語名
 * Country names (via )
 * Currency names (via )
 * タイムゾーン
 * Character encoding conversion via
 * UpperLowerCase first (needs casemaps for some)
 * UpperLowerCase
 * Uppercase words
 * Uppercase word breaks
 * Case folding
 * Strip punctuation for MySQL search (search optimisation)
 * Get first character
 * Alternate encoding
 * Recoding for edit (and then recode input)
 * Get first character
 * Alternate encoding
 * Recoding for edit (and then recode input)




 * 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)
 * Truncate (multibyte)
 * Grammar conversions for inflected languages
 * Plural transformations
 * Formatting expiry times
 * Segmenting for diffs (Chinese)
 * Convert to variants of language (between different orthographies, or scripts)
 * Language specific user preference options
 * Link trails and link prefix, e.g.: . 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). 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, 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,   for language code.

Neat functionality:


 * I18N
 * 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 task asking for someone else to do it.

To allow custom namespaces introduced by your extension to be translated, create a  file that looks like this:

Then load it from the  file using ExtensionMessagesFiles like this:

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 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:

Then load it from the  file using ExtensionMessagesFiles like this:

When your special page code uses either or  (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:

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. 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.
 * 1) When a language has variants, and these variants spell some namespaces differently, and you want editors to be able to use the variant spellings.
 * 1) When an existing wiki's language, fall back language(s), or localisation is changed, with it are changed some namespace names.

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, but can be requested there or on : 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.

See Help:System message#Message sources.

関連項目

 * 多言語 MediaWiki
 * コードから言語名を読み取るには、コアの機能 が使えます. 解説はマジックワードを読んでください.