Directionality support/nl

Ondersteuning voor verschillende richtingen (lins-naar-rechts, rechts-naar-links) is een belangrijk aspect bij meertalige software. De ondersteuning is vanaf aanmerkelijk verbeterd.

Deze pagina geeft wat relevante informatie en richtlijnen voor ontwikkelaars en wiki-beheerders als die een functie of extensie willen maken die compatibel is met de rechts-naar-links interface of met verschillende richtingen in het algemeen.



Gebruikersniveau tips
Eerst wat enkele algemene tips voor gebruikers voordat we op de details voor de ontwikkelaars ingaan.


 * De meeste browsers ondersteunen het wijzigen van de richting van een platte tekstbewerkingsgebied, zoals een artikel zoekbox, wiki syntaxis bewerking, bewerkingssamenvatting, enz. Afhankelijk van browsers en besturingssystemen wordt dit gedaan met Ctrl-Shift (Chrome en IE op Windows), Ctrl-Shift-X (Firefox), Option-Click-Change richting (Mac). Hiermee zou u moeten kunnen tikken in een richting die afwijkt van de normale richting op die website.
 * Bij het invoeren in een taal die een richting heeft die anders dan die van de website, voeg een div tag toe met de goede lang, dir en class attributen. Voorbeeld: in een Engelse sectie op een Arabische Wikipedia, tik eerst  in en aan het eind.
 * Als het maar een paar woorden in een alinea zijn, zet ze dan binnen een tag met de toepasselijke lang en dir attributen. (Veel wiki's hebben hier een sjabloon voor, bijv.  ).
 * Om gescheiden getallen van een aanliggend woord met een andere schrijfrichting te scheiden, gebruik RLM of LRM tekens. Veel wiki's hebben hiervoor sjablonen, in de Hebreeuwse Wikipedia,  in de Arabische Wikipedia,  in de Iraanse Wikipedia, enz. Als er een sjabloon beschikbaar is, dan wordt er meestal de voorkeur gegeven om het teken zelf te gebruiken.

U kunt fouten in de afhandeling van RTL melden in Phabricator op elk gerelateerd MediaWiki project met gebruik van de tag RTL.

ResourceLoader
Thanks to ResourceLoader including CSSJanus, CSS is automatically flipped to right-to-left when the user language is RTL. This is default since 1.18 (in previous versions it was dependent on the wiki content language). There is relatively little CSS that must depend on the content language.

As a temporary work-around test RTL interface with debug off. (Issue being tracked as T29025.)
 * Attention: when using ResourceLoader's debug mode, the CSS may be inconsistently rendered compared to the production mode.

What kind of languages?
Main article:

This returns $wgLang in 1.18 and higher but $wgContLang in 1.17 (by default).
 * $wgLang - user language (and the respective direction)
 * $wgContLang - site content language (and respective direction) -> here LTR
 * Title->getPageLanguage - page content language (and respective direction) -> by default the same as site content language
 * There are some default exceptions: see below
 * It can be set in extensions by the hook
 * This sets the TOC (and stuff like grammar, although not really relevant mostly) to that language. To do that only, use parserOptions->setTargetLanguage
 * In extensions that should remain compatible with 1.17, you can use wfUILang, however this breaks compatibility with 1.16 and below.

What should follow which kind?

 * Special pages follow the user language by default.
 * Source code should be English (CSS/JS pages are set to English by default).
 * Pages with translation as subpages should follow the language of the translation (e.g. "Page" is wgContLang, "Page/he" is "he"). This is the default for the MediaWiki namespace.
 * Input boxes and textareas follow content direction by default.
 * When viewing a diff, it follows the user language, but the actual diff text is in the page content language.

What should I add in the source code?

 * Anything on special pages that is different from the user language should have a  tag.
 * Example: SpecialRecentchanges->setTopText which adds the "recentchangestext" message in the wiki content language.
 * Anything on custom namespaces that contains text different from the default wiki content should also have a  tag.
 * When the diff text is not the same as the page content language, use where $diff is a DifferenceEngine object.

lang/dir attributes
You should use HTML:

but sometimes that is difficult in dynamically generated elements and you can fall back on CSS:

Wiki content
You can use  and   classes to make use of edit section links and ul/ol elements based on that direction.


 * E.g.

This is of course used for the page content of articles.

A piece of text on special pages can be in the content language, which should then be embedded in these classes. It is for example used in the CodeReview extension for the code summary and code comments, which can contain ul/ol elements (* and # wikitext) in the wiki content language and in principle not the user language obviously.
 * On file pages, it is only added around the actual text while the rest of the file page is custom UI (file history, ...).
 * On category pages it is added as on regular pages, but the text in the user language is embedded in a  with   and   attributes according to the user language.
 * On special pages it is not added because these are largely in the user language.

Adding UI stuff within these classes should not be done. For example, the category links and FlaggedRevs review form are inside #bodyContent but outside .mw-content-ltr/rtl.

A new feature is that these classes can be used within these classes. For example, .mw-content-rtl can be used in an LTR (mw-content-ltr) article. This is useful for multilingual pages. Prior to this, local MediaWiki:Common.css hacks had to be used to make e.g. bullet lists show correctly in  text. You should therefore use  instead of   when editing wiki pages.

See also IDs and classes.

body classes
The body tag has an  or   class by default, which follows the user language. You shouldn't use that, because CSS is automatically flipped based on the user language. The body tag also features a new (1.18)  and   class which follows. If there is need for it, a "userlang-ltr/rtl" and/or "pagelang-ltr/rtl" could be added as well.

float/text-align
You can use, , , which gives the appropriate 'right' or 'left' values.

You can use CSS  or   of which the value (left/right) is flipped for RTL interface languages.

Examples
Special:AllMessages is a special page, which means it follows the user language direction. However, the actual messages should follow the direction of the selected language.


 * Special:Allmessages = English, LTR
 * Special:Allmessages/he = Hebrew, RTL

The cells in the table containing the content of the messages, have a  &   attribute.

The extension, making use of the PageContentLanguage hook, sets the right language (and consequently direction) for translated pages, see e.g. Wikimedia_maintenance_notice/ar which benefits from the mw-content-rtl class on an LTR wiki.

Local wikis
MediaWiki:Common.css pages and relatives are also flipped. This means that you have to add @noflip where needed.

See T33923: site CSS should not be flipped by default.

Issues

 * Most major features and extensions have improved support since about 1.19, see translatewiki:Project:Better directionality and i18n development for that.
 * Known remaining issues:
 * External link icons are flipped according to user language direction (minor issue)
 * - Use  instead of , otherwise special page returns
 * - kittens aligned left should be aligned right in RTL wikis (minor issue)
 * OmegaWiki: needs general overhaul (Expression and DefinedMeaning pages should follow user direction) + 23035
 * Search bugs: https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=rtl