Manual:زبان

در مدیا ویکی ، انواع زبان های که اینجا هستند:

It can also be set through &variant (or $wgVariantArticlePath ) in the URL (e.g. by selecting one of the tabs) if it is a variant of the content language of the page being viewed.

A language code is a valid standard abbreviation for a language supported by MediaWiki,^[1] which uses such codes as standard identifiers for languages (mostly in accordance with ISO 639-3, except two-letter codes from ISO 639-1 for "established" locales) and exposes or requires them in many points of the interface and code.^[2]

There are some special language codes for internal or development use: qqq (for message documentation, does not work with uselang etc.), qqx (shows message names for debugging), en-x-rtl (English, but pretends it is a right-to-left language), en-x-piglatin (when $wgUsePigLatinVariant is enabled, for LanguageConverter testing), x-xss (when $wgUseXssLanguage is enabled, tests XSS vulnerabilities in messages).

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 CLDR ), mind you!

Some languages in MediaWiki have what is known as a "fallback sequence". This is where MediaWiki will fall back on a different language if it cannot find what it needs. An example of this is the language code frc (Cajun French), which falls back on the language code fr (French). The reason for this is that sometimes languages don't have all messages defined in them.

The fallback for a language can be found in its associated languages/messages/MessagesXX.php file. For instance MessagesFrc.php. You can search the code for all uses. There is also a plain list from سپتامبر ۲۰۲۰ in this Phabricator comment.

JavaScript :

mw.config.get( 'wgContentLanguage' );

The value for special pages, CSS, JS, and MediaWiki namespace pages cannot be overridden.

1.19+

1.21+

1.22+

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.).

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.

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.

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.

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.

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.

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 Extension:CLDR )
• Currency names (via Extension: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 Cite extension has a special page file per language, cite_text-zyx for language code zyx.

• I18N sprintfDate
• Roman numeral formatting

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.^[4]

<?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',
];

{
	"name": "MyExtension",
	"version": "0.0.1",
	"descriptionmsg": "myextension-desc",
    "ExtensionMessagesFiles": {
		"MyExtensionNamespaces": "MyExtension.i18n.namespaces.php"
	}
}

See the manual page for Special pages for up-to-date information. The following does not appear to be valid.

<?php
/**
 * Aliases for the MyExtension extension.
 *
 * @file
 * @ingroup Extensions
 */

$aliases = [];

/** English */
$aliases['en'] = [
	'MyExtension' => [ 'MyExtension' ]
];

/** Finnish (Suomi) */
$aliases['fi'] = [
	'MyExtension' => [ 'Lisäosani' ]
];

{
	"name": "MyExtension",
	"version": "0.0.1",
	"descriptionmsg": "myextension-desc",
    "ExtensionMessagesFiles": {
		"MyExtensionAlias": "MyExtension.i18n.alias.php"
	}
}

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.

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.

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 Developers .