Suporte de Direcionalidade

From mediawiki.org
Jump to navigation Jump to search
This page is a translated version of the page Directionality support and the translation is 26% complete.
Other languages:
English • ‎Türkçe • ‎français • ‎português • ‎中文 • ‎日本語
i18n docs

Support for different writing directions (left-to-right, right-to-left) is an important aspect for multilingual software. Since MediaWiki 1.18 , the support has been considerably improved.

This page gives some relevant information, and guidelines for developers and wiki administrators if you want to make a feature or extension compatible with the right-to-left interface and different directionality in general.

Dicas de nível do utilizador

Algumas dicas gerais para os utilizadores, antes de obterem detalhes para os programadores:

  • Most browsers support changing the direction of a plain-text editing area, such as article search boxes, wiki syntax editing, edit summary, etc.

Depending on browsers and operating systems, this is done by Ctrl-Shift (Chrome and IE on Windows), Ctrl-Shift-X (Firefox), Option-Click-Change direction (Mac). This should help you typing in a direction that is different from the site's usual direction.

  • When typing a section in a language that has a direction that is different from the site's, add a div tag with appropriate lang, dir and class attributes.

For example, when typing an English section in the Arabic Wikipedia, type <div lang="en" dir="ltr" class="mw-content-ltr"> in the beginning and </div> in the end.

  • When typing just a few words inside a paragraph, put them inside a <span> tag with appropriate lang and dir attributes.

(Many wikis have a template for this, such as {{lang}}).

  • To separate numbers from an adjacent word with different directionality, use RLM or LRM characters.

Many wikis have templates for this, for example {{כ}} in the Hebrew Wikipedia, {{RLM}} in the Arabic Wikipedia, {{رچ}} in the Persian Wikipedia, etc.

When a template is available, it's usually preferred to using the Unicode character itself.

You can report bugs in RTL handling in Phabricator in any MediaWiki-related project using the RTL tag.

Carregador de Recursos

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.

  • Attention: when using ResourceLoader's debug mode, the CSS may be inconsistently rendered compared to the production mode.

As a temporary work-around test RTL interface with debug off. (Issue being tracked as Phabricator:T29025.)

Que tipo de idiomas? =

Artigo principal: Manual:Idioma

  • $wgLang - idioma do utilizador (e respetiva direção)
  • $wgContLang - o idioma do conteúdo do site (e respetiva direção) -> aqui LTR
  • Title->getPageLanguage() - idioma do conteúdo da página (e respetiva direção) -> por predefinição o mesmo que o idioma do conteúdo do site
    • Existem algumas exceções predefinidas: veja abaixo
    • It can be set in extensions by the hook PageContentLanguage
    • 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.

This returns $wgLang in 1.18 and higher but $wgContLang in 1.17 (by default).

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 translated 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.
Directionality can be confusing, but you can watch mooeypoo's linux.conf.au talk entitled "Wait, ?tahW: The Twisted Road to Right-to-Left Language Support" to get a better understanding of the issues and solutions involved.

O que eu deverei adicionar no código fonte?

  • Anything on special pages that is different from the user language should have a <div dir="..." lang="..."> 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 div tag.
  • When the diff text is not the same as the page content language, use $diff->setTextLanguage( 'code' ); where $diff is a DifferenceEngine object.

atributos lang/dir

Deveria utilizar HTML:

Xml::rawElement( 'div', array( 'lang' => $wgContLang->getCode(), 'dir' => $wgContLang->getDir() );

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

.class { direction: ltr; }

Código da wiki

MediaWiki version:
1.18

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

Por exemplo:
Xml::rawElement( 'div', array(
        'class' => 'mw-content-' . $wgLang->getDir(),
        'lang' => $wgLang->getCode(),
        'dir' => $wgLang->getDir(),
        'Text'
);

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

  • 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 div with lang and dir attributes according to the user language.
  • On special pages it is not added because these are largely in the user language.

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.

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 <div dir="ltr/rtl"> text. You should therefore use <div class="mw-content-ltr/rtl"> instead of <div dir="ltr/rtl"> when editing wiki pages.

See also IDs and classes.

classes de corpo

The body tag has an ltr or rtl 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) sitedir-ltr and sitedir-rtl class which follows $wgContLang->getDir(). 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 $wgLang->alignStart(), $wgContLang->alignStart(), $wgLang->alignEnd(), $wgContLang->alignEnd() which gives the appropriate 'right' or 'left' values.

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

Exemplos

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.

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

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

Wikis Locais

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.

Problemas

Consulte também