Help:Systeembericht

Let op: Als u deze pagina bewerkt, gaat u akkoord met het vrijgeven van uw bijdragen onder de CC0. Zie Helppagina’s Publiek Domein voor meer informatie.

Diagram van het Special:Upload-formulier met labels, waar meerdere systeemberichten worden getoond.

Een systeembericht is een fragment van platte tekst (nowiki), wikitext, CSS of JavaScript dat kan worden gebruikt om het gedrag van MediaWiki en het uiterlijk ervan voor elke taal en locale aan te passen. MediaWiki gebruikt berichten voor elk gebruikersdeel van de interface, waardoor de MediaWiki UI wordt geïnterneerd en gelokaliseerd, zowel voor de kern als voor extensies. Alle berichten die in MediaWiki worden gebruikt, worden gedefinieerd in een bestand messages.
NB: Dit is een vertaalde tekst over het werken met en opstellen van de bronberichten, die teksten zijn nagenoeg altijd in het Engels. Vandaar dat gedeelten soms in het Engels zijn gelaten. Het gaat hier meer over de oorspronkelijke berichten en niet over de vertalingen.

Berichten op de wiki overschrijven

De standaardwaarde van een bericht kan overschreven worden door het op wiki te bewerken. Elk bericht heeft een wikipagina in de MediaWiki-namespace met de berichtsleutel als de naam van de pagina. Het bericht 'aboutsite' wordt bijvoorbeeld opgeslagen op MediaWiki:aboutsite. Standaard kan deze namespace niet bewerkt worden, tenzij de gebruiker het recht "editinterface" heeft. Een lijst met alle berichtpagina's is te vinden op Special:AllMessages. Het bewerken van interfaceberichten is meestal eenvoudig, net als het bewerken van een normale wiki-pagina, maar het is beperkt tot gebruikers met het recht editinterface, dat standaard is verleend aan beheerders (en interfacebeheerders).

Voorbeeld rij op de oude Special:AllMessages.

De tabel Special:AllMessages bevat twee kolommen: de naam van de gekoppelde interface en de tekst. De tekst wordt horizontaal gesplitst om de standaardtekst erboven en de aangepaste tekst eronder weer te geven. Als er geen aangepaste tekst bestaat, wordt alleen de standaardtekst weergegeven. Als u een bericht wilt aanpassen, klikt u op de bovenste link in de linkerkolom (de naam van het bericht). Deze link is rood als de standaardtekst in gebruik is, omdat de bewerkingspagina leeg is.

De onderste links in de cellen in de linkerkolom linken naar de discussiepagina's voor dat bericht.

Het overschrijven van berichten op de wiki wordt alleen aanbevolen in de volgende gevallen:

• Het bericht bevat een ernstige fout die zo snel mogelijk moet worden verholpen. In dit geval is het aan te raden om deze fout ook in de broncode te herstellen als deze in het Engels is of in de vertaling op translatewiki als dat niet het geval is. Wanneer de correctie is geïmplementeerd, moet de pagina met de lokale aanpassing worden verwijderd.
• Als de lokale wiki andere terminologie gebruikt. In veel berichten wordt bijvoorbeeld het woord 'page' gebruikt, maar op de Engelse Wikipedia staat vaak 'article'.
• In de lokale versie is een unieke functionaliteit toegevoegd, bijvoorbeeld voor een gadget of een sjabloon. (In zo'n geval is het nog steeds aan te raden om te overwegen het bronbericht te wijzigen of deze functionaliteit in een extensie in te kapselen, zodat andere wiki's het gemakkelijk kunnen gebruiken, zonder aanpassingen handmatig te hoeven kopiëren.)

Berichten vinden en documentatie

Hoe elk bericht door MediaWiki wordt gebruikt, beschikbare variabelen, gebruikte parameters, beperkingen, enzovoort wordt uitgelegd met de volledige documentatie in de qqq pseudo-taal bestanden, volgens deze richtlijnen. Voor sommige interfaceberichten op de oudere Category:Interface messages/nl -pagina's kunnen er enkele langere uitlegpagina's bestaan.

In de wiki-basis van translatewiki.net is qqq de pagina die de gebruikersdocumentatie van het bericht bevat (in het Engels omdat het hetzelfde wordt getoond aan alle lezers).

Op dezelfde manier als /en, /zu, /fr, ... is /qqq is een subpagina van het artikel en direct te bekijken.

• Probeer translatewiki:MediaWiki:Tog-hideminor/en om een bericht in het Engels te bekijken,
• Probeer translatewiki:MediaWiki:Tog-hideminor/fr om hetzelfde bericht in het Frans te bekijken,
• Probeer translatewiki:MediaWiki:Tog-hideminor/qqq om de bijbehorende documentatie te lezen (in het Engels).

Vanuit dit perspectief wordt qqq beschouwd als een taal in parameter language= van het verzoek.

MediaWiki-versie:

≥ 1.18

In MediaWiki 1.18 en hoger, kunt u een berichtsleutel vinden door een wiki te doorzoeken met de speciale pseudo-taal code qqx, wat kan worden gedaan door ?uselang=qqx aan de URL toe te voegen, of &uselang=qqx als de URL al een ? teken bevat (voorbeeld). Alle berichten worden vervolgens vervangen door hun berichtsleutels, zodat u kunt identificeren welk bericht verantwoordelijk is. Berichten die altijd in de inhoudstaal zijn, worden niet weergegeven met qqx.

In het geval dat de pagina tabbladen gebruikt zoals bijv. de speciale pagina 'Voorkeuren' moet u het tabblad toevoegen na de uselang parameter, bijv. Special:Preferences?uselang=qqx#mw-prefsection-rendering.

MediaWiki-versie:

≥ 1.38 Gerrit change 765385

Vóór MediaWiki 1.38 werden fallback-berichtsleutels niet getoond, wat het moeilijk maakte om de bron van sommige berichten te identificeren, met name de pagina navigatietabbladen. Sinds MediaWiki 1.38 worden terugvalberichtsleutels weergegeven, gescheiden door slashes (/).

MediaWiki-versie:

≥ 1.43 Gerrit change 1025837

Vóór MediaWiki 1.43, overschrijft u berichtsleutels (met behulp van hooks zoals MessageCacheFetchOverrides) die werden ook niet getoond, wat het moeilijk maakte om de bron te identificeren van berichten die werden overschreven door extensies (zoals WikimediaMessages ). Aangezien MediaWiki 1.43 override message key wordt getoond na een gelijkteken (=).

Bestandsformaat vertalingen

Alle berichten die in MediaWiki worden gebruikt, worden gedefinieerd in een bestand messages.

Er zijn twee types berichtenbestanden in MediaWiki: JSON en PHP. Vanaf april 2014 zijn de berichten van de kern van MediaWiki en de meeste van de onderhouden extensies gemigreerd naar het JSON-formaat. U zou JSON moeten gebruiken voor alle nieuw ontwikkelde software. Voor meer informatie over de migratie naar JSON zie Requests for comment/Localisation format.

JSON

Vanaf eind 2013 is er een nieuw bestandsformaat voor berichten geïntroduceerd: JSON. Dit is gewone JSON, bekend als een veelgebruikt algemeen formaat voor gegevensopslag. Elke sleutel in het bestand is een berichtsleutel, en de waarde is de tekst van het bericht. Daarnaast wordt de speciale sleutel @metadata gebruikt om informatie over de vertaling op te slaan, zoals de makers van de vertalingen.

Het gebruik van JSON maakt de lokalisatiebestanden veiliger omdat het een niet uitvoerbaar bestand is. Het is ook compatibel met jquery.i18n, een bibliotheek van JavaScript die is ontwikkeld als onderdeel van Project Milkshake, dat MediaWiki-achtige frontend-lokalisatiemogelijkheden biedt en wordt gebruikt door sommige extensies die minder afhankelijk willen zijn van MediaWiki, zoals de Visuele tekstverwerker en de UniversalLanguageSelector.

Omdat het bredere pakket aan hulpmiddelen voor internationalisering en lokalisatie 'Project Milkshake' werd genoemd, noemen sommige mensen dit formaat 'banana'.

Locatie bestand

In MediaWiki core worden de localisatiebestanden geplaatst in de map languages/i18n . De extensies plaatsten ze meestal in een submap van i18n/. Als er binnen een project een groot aantal berichten bestaan, kan men deze in twee of meer submappen (bijvoorbeeld per onderwerp) opdelen om ze te kunnen onderhouden. In de context van MediaWiki wordt de configuratie-sleutel $wgMessagesDirs gebruikt om deze submappen op te slaan. Hier is een voorbeeld van de extensie VisualEditor van MediaWiki:

{
  "MessagesDirs": {
    "VisualEditor": [
      "lib/ve/modules/ve/i18n",
      "modules/ve-mw/i18n",
      "modules/ve-wmf/i18n",
      "lib/ve/lib/oojs-ui/i18n"
    ]
  }
}

U voegt nieuwe berichten toe aan het Engelse "en" berichtenbestand en.json en documenteert ze in het berichtendocumentatiebestand met de speciale pseudo-taalcode "qqq" - qqq.json. Zie ook: Berichten toevoegen.

Metadata

Op dit moment worden de volgende metadatavelden gebruikt in de bestanden:

authors

Een JSON-lijst met de auteurs van de berichten. Voor het Engels (en) en de berichtdocumentatie (qqq) worden deze handmatig toegevoegd wanneer het berichtbestand wordt bewerkt. Voor alle andere talen wordt dit automatisch ingevoegd wanneer het berichtbestand wordt geëxporteerd vanaf translatewiki.net. De documentatie van het bericht kan worden bewerkt op translatewiki.net, en documentatie-editors worden automatisch ook in het bestand qqq.json ingevoegd.

message-documentation

Dit is de pseudo-taalcode voor het opslaan van de berichtdocumentatie. Voor MediaWiki is dit altijd qqq. (Dit wordt in sommige extensies getoond, maar het wordt niet verwerkt op welke manier dan ook.)

Conventies

Bijzondere tekens zoals 'nieuwe regel' worden onderdrukt ("\n").

Unicode-tekens die letters in verschillende alfabetten vertegenwoordigen worden opgeslagen als echte tekens en niet als tekencodes, omdat deze bestanden soms door mensen worden gelezen en omdat dit de bestanden kleiner maakt ("誼" en niet "\u8ABC"). In elk geval hebben ontwikkelaars weinig redenen om berichten in andere talen te bewerken dan het Engels, omdat deze meestal worden bewerkt via translatewiki.net.

In HTML-code wordt geen escape gebruikt, dus "<strong>Warning</strong>", niet "\u003cstrong\u003eWarning\u003c/strong\u003e".

In JSON-bestanden wordt ingesprongen met behulp van tabs.

PHP

Deze sectie verwijst naar het gebruik van bestanden MessagesXx.php voor het lokaliseren van berichten, dat in 2014 is afgeschaft/ontraden. De bestanden worden echter nog steeds gebruikt voor andere taalspecifieke configuratie .

Het oudere lokalisatiebestandsformaat is PHP. Dit is een PHP-array met alle berichten. In de core van MediaWiki bevindt elke taal zich in een eigen bestand in de map languages/message van de MediaWiki broncode. In de extensies staan alle talen en de berichtdocumentatie (qqq) in hetzelfde bestand: ExtensionName.i18n.php, meestal in de hoofdmap van de extensie.

Om systeemberichten van PHP naar JSON te migreren, gebruikt u het script generateJsonI18n.php . Het zal de berichten naar JSON-bestanden verplaatsen en de tekst van het PHP-bestand vervangen door een verwijzing (shim) naar de JSON-bestanden. Deze boilerplate code is nodig voor achterwaartse compatibiliteit met MediaWiki 1.19. Het wordt niet gebruikt in nieuwe extensies die geen MediaWiki 1.19-compatibiliteit vereisen.

Berichten gebruiken

MediaWiki maakt gebruik van een centrale repository van berichten waarnaar wordt verwezen door keys in de code. Dit is anders dan bijvoorbeeld het systeem gettext, dat de vertaalbare strings uit de bronbestanden extraheert. Het op keys gebaseerde systeem maakt sommige dingen eenvoudiger, zoals het verfijnen van de originele teksten en het bijhouden van wijzigingen in berichten. Het nadeel is dat de lijst met gebruikte berichten en de lijst met bronteksten voor die keys uit de pas kunnen gaan lopen. In de praktijk is dit geen groot probleem, en het enige grote probleem is dat extra berichten die niet meer worden gebruikt, soms toch blijven staan voor vertaling.

Om de keys beter beheersbaar en gemakkelijker te vinden te maken, moet u ze altijd volledig schrijven en niet te veel vertrouwen op het dynamisch maken ervan. U kunt delen van keys samenvoegen als u denkt dat dit uw code een betere structuur geeft - maar doe dit alleen als er zeker meerdere mogelijkheden zijn, en zorg ervoor dat u een opmerking in de buurt plaatst met een lijst van de mogelijke resulterende keys. Bijvoorbeeld:

// Berichten die hier gebruikt kunnen worden:
// * myextension-connection-success
// * myextension-connection-warning
// * myextension-connection-error
$text = wfMessage( 'myextension-connection-' . $status )->parse();

Zie ook de conventies voor het coderen van dynamische identifiers.

Om een bericht in JavaScript te gebruiken, moet u het noemen in de definitie van uw ResourceLoader-module, in de eigenschap "messages".

Het gedetailleerde gebruik van berichtfuncties in PHP en JavaScript staat op Handleiding:Messages API . Dit is een belangrijke documentatiepagina en u moet deze lezen voordat u code schrijft die gebruikmaakt van berichten.

Berichten bronnen

In de code worden systeemberichten in de volgende bronnen opgezocht:

• de namespace MediaWiki. Dit stelt wiki's in staat om een bericht over te nemen of te overschrijven, wanneer het standaardbericht niet past of niet gewenst is.
  • MediaWiki:Message-key is het standaardbericht,
  • MediaWiki:Message-key/language-code is het bericht dat moet worden gebruikt wanneer een gebruiker een andere taal heeft geselecteerd dan de standaardtaal van de wiki.
• Uit de berichtenbestanden:
  • Core MediaWiki zelf en de meeste onderhouden extensies gebruiken een bestand per taal, genaamd zyx.json, waarbij zyx de taalcode voor de taal is.
  • Sommige oudere extensies gebruiken een gecombineerd berichtenbestand met alle berichten in alle talen, meestal met de naam MijnExtensieNaam.i18n.php.
  • Veel Wikimedia Foundation wiki's krijgen toegang tot enkele berichten vanaf de extensie WikimediaMessages , waardoor ze berichten op WMF wiki's kunnen standaardiseren zonder ze op elke MediaWiki-installatie op te leggen.
  • Een paar extensies gebruiken andere technieken.

Caching

Systeemberichten zijn een van de belangrijkste componenten van MediaWiki, vooral omdat het wordt gebruikt in elk webverzoek. De PHP-berichtenbestanden zijn groot, omdat ze duizenden berichtenkeys en -waarden opslaan. Het laden van dit bestand (en mogelijk meerdere bestanden, als de taal van de gebruiker verschilt van de taal van inhoud) zorgt voor een grote belasting van geheugen en prestatie. Een agressief, gelaagd caching systeem wordt gebruikt om de impact op de prestatie te verminderen.

MediaWiki heeft veel ingebouwde caching-mechanismen, waardoor de code iets moeilijker te begrijpen is. Sinds 1.16 is er een nieuw caching systeem, dat berichten in de cache opslaat in cdb bestanden of in de database. Aangepaste berichten worden in het bestandssysteem gecached en in memcached (of een alternatief), afhankelijk van de configuratie.

Onderstaande tabel geeft een overzicht van de relevante instellingen:

Locatie van opslag cache		$wgLocalisationCacheConf
		'store' => 'db'	'store' => 'detect' (standaard)	'store' => 'files'	'store' => 'array' (experimenteel sinds MediaWiki ≥ 1.26)
$wgCacheDirectory	= false (standaard)	l10n cache table	l10n cache table	fout (pad niet gedefinieerd)	fout (pad niet gedefinieerd)
	= path	l10n cache table	lokaal bestandssysteem (CDB)	lokaal bestandssysteem (CDB)	lokaal bestandssysteem (PHP-array)

MediaWiki-versies:

1.27.0 – 1.27.2 Gerrit #Id3e2d2

In MediaWiki 1.27.0 en 1.27.1 is de automatische detectie gewijzigd om de backend te bevoordelen. In het geval van 'store' => 'detect' (de standaard), wordt de backend van het bestand gebruikt met het pad vanaf $wgCacheDirectory . Als deze waarde niet is ingesteld (wat de standaard is), wordt een tijdelijke map gebruikt die door het besturingssysteem wordt bepaald. Als er geen tijdelijke map kan worden gedetecteerd, wordt de database backend als een fallback gebruikt. Dit is teruggedraaid in 1.27.2 en 1.28.0 vanwege conflict van bestanden op gedeelde hosts en beveiligingsproblemen (zie T127127 en T161453).

Functie backtrace

Om de lagen van caching beter te visualiseren, is hier een functie achtergrond van welke methoden worden genoemd bij het ophalen van een bericht. Zie de onderstaande secties voor een uitleg van elke laag.

• Message::fetchMessage()
• MessageCache::get()
• Language::getMessage()
• LocalisationCache::getSubitem()
• LCStore::get()

MessageCache

De MessageCache class is het hoogste niveau van caching van berichten. Het wordt in de class Message aangeroepen en geeft de laatste ruwe inhoud van een bericht terug. Deze laag behandelt de volgende logica:

• Controleren of berichten in de database worden overschreven
• Caching van overschreven berichten in memcached , of op welke $wgMessageCacheType dan ook
• Het oplossen van de rest van de taal fallback sequentie

Het laatste punt is belangrijk. Taal fallback stelt MediaWiki in staat om terug te vallen op een andere taal als het gevraagde bericht niet in de gevraagde taal bestaat, Zoals in het volgende gedeelte is vermeld, vinden de meeste taal fallbacks plaats op een lager niveau. Alleen de laag MessageCache controleert de database echter op overschreven berichten. Het integreren van overschreven berichten uit de database in de fallback-keten gebeurt dus hier. Als u de database niet gebruikt, kan deze hele laag worden uitgeschakeld.

LocalisationCache

Zie LocalisationCache.php

LCStore

De class LCStore is slechts een back-end-implementatie die door de class LocalisationCache wordt gebruikt voor het cachen en ophalen van berichten. Net als de class BagOStuff, die wordt gebruikt voor algemene caching in MediaWiki, zijn er een aantal verschillende caches (geconfigureerd met $wgLocalisationCacheConf ):

• "db" (standaard) - Caches berichten in de database
• "file" (standaard indien $wgCacheDirectory is gezet) - Gebruikt CDB om berichten te cachen in een lokaal bestand
• "accel" - Gebruikt APC of een andere opcode cache op data op te slaan

De optie "file" wordt gebruikt door de Wikimedia Foundation, en wordt aanbevolen omdat het sneller is dan naar de database en betrouwbaarder is dan de APC-cache, vooral omdat APC onverenigbaar is met PHP-versie 5.5 of later.

Berichten toevoegen

De berichtensleutel kiezen

Zie ook: Manual:Coding conventions#System messages

De key van het bericht moet globaal uniek zijn. Dit omvat ook de kern MediaWiki en alle extensies en skins.

Houd het bij kleine letters, cijfers en streepjes in berichtnamen; De meeste andere karakters zijn minder praktisch of werken niet goed. In de MediaWiki-conventie is het eerste karakter niet hoofdlettergevoelig, maar zijn de anderen wel hoofdlettergevoelig.

Volg de globale of lokale conventies bij het toekennen van een naam. Voor extensies wordt standaardvoorvoegsel gebruikt, bij voorkeur de naam van de extensie in kleine letters, gevolgd door een streepje (-). Uitzonderingen zijn:

Berichten die door de API worden gebruikt

Deze moeten beginnen met apihelp-, apiwarn- of apierror-. Na deze prefix komt de prefix van de extensie. (Deze berichten moeten in een apart bestand staan, meestal onder includes/i18/api.)

Berichten met betrekking tot de log

Deze moeten beginnen met logentry-, log-name- of log-description.

Gebruikersrechten

De key voor het gebruikersrecht zoals getoond op Special:ListGroupRights moet beginnen met right-. De naam van de actie die de zin "U hebt geen toestemming om $2, want:" voltooit, moet beginnen met action-.

Revisie-tags

De revisie-tags moeten beginnen met tag-.

Titels van speciale pagina's

Deze titels moeten beginnen met special-.

Beschrijvingen van extensies

Deze beschrijvingen moeten beginnen met de naam van de extensie en eindigen met -desc.

They appear in the table on Special:Version, and their content must briefly explain what the extension does.

Geslacht

Engelse berichten hebben bijna nooit verschillende woorden nodig vanwege het geslacht van een gebruiker. Engels heeft dit alleen nodig in de derde persoon voornaamwoorden "he" en "she", maar deze zijn verrassend zeldzaam in berichten. Wanneer dit nodig is, gebruik dan he of they.

Veel andere talen hebben echter verschillende woorden nodig, afhankelijk van het geslacht van de gebruiker, niet alleen voor voornaamwoorden van de derde persoon, maar ook voor andere voornaamwoorden, evenals voor werkwoorden in verschillende tijden, zelfstandig naamwoorden, bijvoeglijke naamwoorden, enz. Het is daarom vaak handig om GENDER in Engelse berichten te gebruiken, zelfs als er maar één Engels woord is. Dit geeft vertalers een hint dat GENDER in een bericht kan worden gebruikt. Het vermijdt ook waarschuwingen op translatewiki over ontbrekende parameters wanneer een optionele parameter ontbreekt (dit gebeurt vooral vaak in log entry berichten).

Andere dingen om op te letten bij het maken van berichten

1. Zorg ervoor dat u de juiste manier gebruikt om het bericht te behandelen (parseren, vervanging {{, escapen van HTML, enz.)
2. Als uw bericht deel uitmaakt van de kern, moet het meestal worden toegevoegd aan languages/i18n/en.json, hoewel sommige componenten, zoals Installer, EXIF-tags en ApiHelp hun eigen berichtbestanden hebben.
3. Als uw bericht van een extensie is, voeg het dan toe aan het bestand i18n/en.json of het bestand en.json in de juiste submap. API-berichten die alleen door ontwikkelaars en niet door de meeste eindgebruikers worden gezien, staan meestal in een apart bestand, zoals i18n/api/en.json. Als een extensie veel berichten bevat, kunt u submappen van i18n maken. Alle berichtmappen, inclusief de standaard i18n/, moeten in de sectie MessagesDirs in extension.json of in de variabele $wgMessagesDirs worden vermeld.
4. Neem een pauze en bekijk de tekst van de bericht. Is het zo duidelijk mogelijk? Kan het verkeerd begrepen worden? Vraag indien mogelijk opmerkingen van andere ontwikkelaars of vertalers. Volg de tips over het vertalen.
5. Voeg documentatie toe aan qqq.json in dezelfde map.
6. De volgorde van de berichten in het bestand moet ongeveer overeenkomen met de kenmerken van uw project. Zet berichten van dezelfde functie bij elkaar. Dit helpt vertalers om gefocust te blijven en efficiënt en consistent te zijn.
7. Zet de berichten die naar verwachting het meest elementair zijn en het meest worden gebruikt aan het begin van het bestand, en de berichten die zeldzamer en technisch geavanceerder zijn aan het einde.

Berichten die niet vertaald mogen worden

1. Ignored (genegeerde) berichten zijn berichten die alleen in het Engelse berichtenbestand zouden moeten staan. Het zijn berichten die geen vertaling nodig zouden moeten hebben, omdat ze alleen verwijzen naar andere berichten of taalneutrale kenmerken, bijvoorbeeld een bericht van "{{SITENAME}}".
2. Optional (optionele) berichten mogen alleen worden vertaald als ze in de doeltaal worden gewijzigd.

Om dergelijke berichten te markeren:

• gebruik het sjabloon in de qqq berichtdocumentatie, dat is respectievelijk
  1. {{notranslate}} of
  2. {{optional}};
• vertel de extensie Translate/nl die gebruikt wordt op translatewiki.net wat te doen met de berichten door een patch in te dienen waarin ze indien nodig worden vermeld (zie ook volledige configuratiedocumenten ):
  • voor kern, in groups/MediaWiki/MediaWiki.yaml voeg de berichtsleutels toe
    1. onder ignored: of
    2. onder optional:;
  • Voor extensies, voeg in groups/MediaWiki/mediawiki-extensions.txt een regel toe onder de naam van de extensie als
    1. ignored = msg-key-1,msg-key-2 or
    2. optional = msg-key-1,msg-key-2.

Bestaande berichten verwijderen

Verwijder het uit en.json en qqq.json. Maak u geen zorgen over andere talen. Updates vanaf translatewiki.net zullen die automatisch afhandelen.

Controleer ook of het bericht ergens in de configuratie van translatewiki staat, bijvoorbeeld in de lijst met optionele of meest gebruikte berichten (een eenvoudige git grep zou voldoende moeten zijn). Verwijder het uit deze lijsten indien nodig.

Bestaande berichten wijzigen

1. Overweeg om de documentatie van het bericht bij te werken.
2. Wijzig de berichtcode als oude vertalingen niet passen bij de nieuwe tekst. Dit omvat ook wijzigingen in de afhandeling van berichten (parseren, escappen, parameters, enz.). Het verbeteren van de formulering van een bericht zonder technische wijzigingen is meestal geen reden om een berichtcode te veranderen. Bij translatewiki.net, zullen de vertalingen worden gemarkeerd als verouderd zodat ze door vertalers kunnen worden aangepast. Het wijzigen van een berichtcode vereist niet dat u met het i18n-team spreekt of een ondersteuningsverzoek indient. Als u echter speciale omstandigheden of vragen heeft, stel deze dan in #translatewiki ^verbinden of in de ondersteuningspagina translatewiki.net .
3. Als de extensie wordt ondersteund door translatewiki.net , wijzig dan alleen het Engelse bronbericht en/of de berichtcode en de bijbehorende vermelding in qqq.json. Indien nodig zal het translatewiki.net team de vertalingen updaten, ze als verouderd markeren, het bestand schoonmaken of de berichtcodes waar mogelijk hernoemen. Dit geldt ook als u alleen dingen verandert zoals HTML tags die u in andere talen kunt veranderen zonder die talen te spreken. De meeste van deze acties zullen plaatsvinden op translatewiki.net en zullen Git bereiken met ongeveer een dag vertraging.

Berichten documentatie

Er is een pseudo-taalcode qqq voor berichtdocumentatie. Het is een van de ISO 639-codes die is gereserveerd voor privégebruik. Daar houden we geen vertalingen van elk bericht bij, maar verzamelen we Engelse zinnen over elk bericht: ons vertellen waar het wordt gebruikt, hints geven over hoe het te vertalen, en de parameters ervan opsommen en beschrijven, link naar gerelateerde berichten, enzovoort. Op translatewiki.net worden deze hints getoond aan vertalers wanneer ze berichten bewerken.

Programmeurs moeten elk bericht documenteren. Berichtdocumentatie is een essentiële bron – niet alleen voor vertalers, maar voor alle mensen die de module onderhouden. Telkens wanneer een bericht aan de software wordt toegevoegd, moet ook een overeenkomstige vermelding van qqq worden toegevoegd; Revisies die dit niet doen, worden gemarkeerd met "V-1" totdat de documentatie is toegevoegd.

Documentatie in qqq-bestanden mogen alleen rechtstreeks worden bewerkt bij het toevoegen van nieuwe berichten of bij het wijzigen van een bestaand Engels bericht op een manier die een documentatiewijziging vereist, bijvoorbeeld het toevoegen of verwijderen van parameters. In andere gevallen moet documentatie meestal worden bewerkt in translatewiki. Elke documentatie string is benaderbaar op https://translatewiki.net/wiki/MediaWiki:message-key/qqq, alsof het een vertaling is. Deze bewerkingen worden samen met de vertalingen naar de bronrepositories geëxporteerd.

De documentatie moet nuttige informatie bevatten:

1. Berichtenverwerking (parseren, escapen, platte tekst).
2. Type parameters met voorbeeldwaarden.
3. Waar het bericht wordt gebruikt (pagina's, locaties in de gebruikersinterface).
4. Hoe het bericht wordt gebruikt waar het wordt gebruikt (een paginatitel, knoptekst, enz.).
5. Welke andere berichten worden gebruikt samen met dit bericht, of naar welke andere berichten het verwijst.
6. Alles wat begrepen kan worden wanneer het bericht in de context wordt gezien, maar niet wanneer het alleen wordt weergegeven (wat het geval is bij het gaan vertalen).
7. Indien van toepassing, notities over grammatica. Bijvoorbeeld, 'open' in het Engels kan zowel een werkwoord als een bijvoeglijk woord zijn. In veel andere talen zijn de woorden anders en is het onmogelijk om te raden hoe ze te vertalen zonder documentatie.
8. Bijvoeglijke naamwoorden die dingen beschrijven, zoals 'disabled', 'open' of 'blocked', moeten altijd zeggen wat ze beschrijven. In veel talen moeten bijvoeglijke naamwoord het geslacht van het zelfstandig naamwoord hebben dat ze beschrijven. Het kan ook gebeuren dat verschillende soorten zaken verschillende bijvoeglijke naamwoorden nodig hebben.
9. Als het bericht speciale eigenschappen heeft, bijvoorbeeld als het een pagina-naam is, of als het niet een directe vertaling moet zijn, maar aangepast is aan de cultuur of het project.
10. Of het bericht in de buurt van een ander bericht wordt getoond, bijvoorbeeld in een lijst of een menu. De formulering of de grammaticale kenmerken van de woorden moeten waarschijnlijk vergelijkbaar zijn met de berichten in de buurt. Ook kan het zijn dat items in een lijst op de juiste manier moeten worden gerelateerd aan de titel van de lijst.
11. Delen van het bericht die niet mogen worden vertaald, zoals generieke namespaces, URL's of tags.
12. Verklaringen van mogelijk onduidelijke woorden, bijvoorbeeld afkortingen, zoals 'CTA', of specifiek jargon, zoals 'template', 'suppress' of 'stub'. (Het is sowieso beter om dergelijke woorden te vermijden!)
13. Schermafdrukken zijn erg handig. Niet bijsnijden - een beeld van het volledige scherm waarin het bericht verschijnt geeft volledige context en kan opnieuw worden gebruikt in verschillende berichten.

Nog een paar tips:

• Onthoud dat vertalers de berichten heel vaak vertalen zonder de software te gebruiken.
• Meestal hebben vertalers geen contextinformatie, noch van uw module, noch van de andere berichten.
• Een geherformuleerde tekst alleen is in de meeste gevallen zinloos.
• Gebruik geen jargon van ontwerpers zoals 'hamburger', 'nav' of 'comps'.
• Overweeg om een woordenlijst te schrijven van de technische termen die in uw module worden gebruikt. Als u dat doet, link dan hiernaar vanuit de documentatie van de berichten.

U kunt naar andere berichten linken met behulp van {{msg-mw|message key}}. Dit moet u doen als delen van de berichten afkomstig zijn van andere berichten (als dit niet kan worden vermeden), of als sommige berichten samen of in dezelfde context worden weergegeven.

translatewiki.net heeft een aantal standaardsjablonen voor documentatie:

• {{doc-action|[...]}} - voor action- berichten
• {{doc-right|[...]}} - voor right- berichten
• {{doc-group|[...]|[...]}} - voor berichten rond gebruikersgroepen (group, member, page, js en css)
• {{doc-accesskey|[...]}} - voor accesskey- berichten

Bekijk de sjabloonpagina's voor meer informatie.

Aanwijzingen voor internationalisatie

Naast documentatie vragen vertalers aan ontwikkelaars om enkele hints te geven om hun werk gemakkelijker en efficiënter te maken en om een daadwerkelijke en goede lokalisatie voor alle talen mogelijk te maken. Zelfs als men alleen berichten in het Engels toevoegt of bewerkt, moet men zich bewust zijn van de behoeften van alle talen. Een bericht kan in meer dan 300 talen worden vertaald en dat moet op de best mogelijke manier worden gedaan. De juiste toepassing van deze tips zal u ook vaak helpen om betere berichten in het Engels te schrijven.

Deze pagina geeft een overzicht van de belangrijkste plaatsen waar u de hulp van ervaren en deskundige mensen kunt vinden met betrekking tot i18n.

Berichtparameters en switches correct gebruiken

Dat is een voorwaarde voor het maken van een juiste tekst voor uw berichten.

Hergebruik van berichten vermijden

De vertalers raden het hergebruik van berichten af. Dit lijkt misschien anders dan verwacht, omdat het kopiëren en dupliceren van code meestal een slechte praktijk is, maar in systeemberichten is het vaak nodig. Hoewel twee concepten in het Engels met hetzelfde woord kunnen worden uitgedrukt, betekent dit niet noodzakelijkerwijs dat ze in elke taal met hetzelfde woord uitgedrukt kunnen worden. "OK" is een goed voorbeeld: in het Engels wordt dit gebruikt voor een algemeen label op een knop, maar in sommige talen gebruiken ze liever een label dat de operatie aangeeft die door de knop wordt uitgevoerd. Een ander voorbeeld is praktisch elk bijvoeglijk naamwoord: een woord als "meerdere" verandert in verschillende talen afhankelijk van geslacht, dus u kunt het niet opnieuw gebruiken om verschillende dingen te beschrijven, en moet u verschillende afzonderlijke berichten maken.

Als u meerdere identieke berichten toevoegt, voeg dan berichtdocumentatie toe om de verschillen in hun context te beschrijven. Maak u geen zorgen over het extra werk voor de vertalers. Het vertaalgeheugen helpt hierbij veel, terwijl het flexibiliteit biedt om indien nodig andere vertalingen te kunnen maken.

Gefragmenteerde of "lappendeken" berichten vermijden

Talen hebben verschillende woordvolgordes en complexe grammaticale en syntactische regels. Berichten die worden gevormd door meerdere stukken tekst, mogelijk met een zekere indirectie, ook wel "tekstsamenvoeging" genoemd, in code die niet direct door vertalers kan worden beheerd, worden "lego" of "patchwork/lappendeken" berichten genoemd in het jargon van ontwikkelaars. Het is bijna onmogelijk om deze berichten correct te vertalen.

Zorg dat elk bericht een volledige zin is. Meerdere zinnen kunnen meestal wel gemakkelijk worden gecombineerd in een tekstblok. Als u meerdere strings in één bericht wilt combineren, geef ze dan door als parameters, omdat vertalers ze correct kunnen ordenen voor hun taal bij het vertalen.

Berichten waarin onderling wordt verwezen

Belangrijkste pagina: Manual:Messages API#Referring to other messages

Een uitzondering op de regel kunnen berichten zijn die naar elkaar verwijzen: 'Voer de naam van de oorspronkelijke auteur in het veld met het label "{{int:name}}" in en klik op "{{int:proceed}}" als u klaar bent'. Dit maakt het bericht consistent wanneer een softwareontwikkelaar of wiki-operator de berichten "name" of "proceed" later verandert. Zonder deze methode zouden ontwikkelaars en exploitanten zich moeten bewust zijn van alle gerelateerde berichten die moeten worden aangepast wanneer ze een van deze berichten veranderen.

Berichten in een natuurlijke taal schrijven

Schrijf een bericht zo veel mogelijk in een natuurlijke, menselijke taal. Probeer de tekst hardop voor te lezen en denk: is dit taal die klinkt alsof het door mensen zo wordt gezegd? Als het complex, moeilijk uit te spreken of op een andere manier onnatuurlijk klinkt in het Engels, zal het nog moeilijker zijn voor vertalers en voor gebruikers in andere talen.

Vermijd punctuatie die te technisch of bureaucratisch is of niet nodig voor het lezen. Een schuine streep (/) moet meestal worden vervangen door or. And/or moet worden vervangen door and resp. or. Zinnen met komma's gescheiden kunnen worden opgesplitst in kortere zinnen.

Gebruik geen termen en sjablonen die specifiek zijn voor specifieke projecten

MediaWiki wordt gebruikt door zeer diverse mensen, binnen en buiten de Wikimedia-beweging. Hoewel het oorspronkelijk was gebouwd voor een encyclopedie, wordt het nu gebruikt voor verschillende soorten inhoud. Gebruik daarom algemene termen. Vermijd bijvoorbeeld termen als 'article' en gebruik in plaats daarvan 'page', tenzij u er absoluut zeker van bent dat de functie die u aan het ontwikkelen bent, alleen zal worden gebruikt op een site waar een pagina 'article' wordt genoemd. Gebruik geen "village pump", wat de naam is van een pagina van de Engelse Wikipedia-gemeenschap, en gebruik in plaats daarvan een algemene term, zoals "gemeenschapsbesprekingspagina" of in het Nederlands "Kroeg".

Veronderstel niet dat er een bepaalde sjabloon bestaat op elke wiki bestaat. Templates zijn lokaal voor wiki's. Dit geldt zowel voor de bronberichten als voor hun vertalingen. Als berichten sjablonen gebruiken, werken ze alleen als er een sjabloon is gemaakt op elke wiki waar de functie is geïmplementeerd. Het is het beste om sjablonen in berichten volledig te vermijden. Als u deze echt moet gebruiken, moet u dit duidelijk in de berichtdocumentatie en in de installatie-instructies voor extensies documenteren.

Scheid in zinnen tijden van datums

Sommige talen moeten iets tussen een datum en een tijd invoeren dat grammaticaal afhankelijk is van andere woorden in een zin. Zij kunnen dus geen gecombineerde datum/tijd gebruiken. Andere vinden de combinatie handig, dus het is meestal de beste keuze om in dergelijke gevallen drie parameters (datum/tijd, datum, tijd) te verstrekken en in elke vertaling de eerste of de laatste twee niet te gebruiken, naargelang nodig in een taal.

Vermijd {{SITENAME}} in berichten

{{SITENAME}} heeft verschillende nadelen. Het kan van alles zijn (acroniem, woord, korte zin, enz.) en, afhankelijk van de taal, kan het gebruik van {{GRAMMAR}} nodig zijn voor elk voorkomen. Ongeacht wat er gebeurt, elk bericht met {{SITENAME}} zal in de meeste wiki-talen moeten worden beoordeeld voor elke nieuwe wiki waarop uw code is geïnstalleerd. In de meeste gevallen, wanneer er geen algemene configuratie GRAMMAR voor een taal is, moeten wiki-operators PHP-code toevoegen of wijzigen om {{GRAMMAR}} voor {{SITENAME}} te laten werken. Dit vereist dan meer vaardigheden en meer begrip. Het is gemakkelijker om generieke referenties te hebben zoals "deze wiki". Dit voorkomt niet dat installaties deze berichten lokaal veranderen om {{SITENAME}} te gebruiken, maar tenminste hoeven ze dat niet te doen, en ze kunnen de bericht aanpassing uitstellen totdat de wiki al wordt uitgevoerd en gebruikt.

Vermijd verwijzingen naar visuele lay-out en posities

Wat wordt opgebouwd hangt af van de skins. Meestal worden schermindelingen van talen die van links naar rechts zijn geschreven gespiegeld in vergelijking met die welke worden gebruikt voor talen die van rechts naar links zijn geschreven, maar niet altijd, en voor sommige talen en wiki's niet helemaal. Handheld devices, smalle schermen en dergelijke kunnen onder en boven blokken tonen, die op grotere schermen naast elkaar worden getoond. Aangezien JavaScript-scripts en gadgets die door gebruikers en sites zijn geschreven, delen kunnen verbergen of dingen op een onvoorspelbare manier kunnen verplaatsen, is er geen betrouwbare manier om de werkelijke lay-out te voorspellen.

Het is verkeerd om lay-outinformatie aan de taal van de inhoud te koppelen, aangezien de taal van de gebruikersinterface mogelijk niet die taal van de pagina is, en de lay-out kan afhankelijk van de omstandigheden een mix van de twee zijn. Niet-visuele gebruikersmiddelen zoals akoestische schermlezers en andere hulpmiddelen hebben zelfs geen concept van visuele lay-out. In de meeste gevallen moet u dus niet verwijzen naar visuele lay-outposities, hoewel semantische lay-outtermen nog steeds kunnen worden gebruikt ("vorige stappen in het formulier", enz.).

MediaWiki ondersteunt niet het weergeven van verschillende berichten of berichtfragmenten op basis van de huidige richting van de interface (zie T30997).

De komende browser en MediaWiki-ondersteuning voor het van bovenaf schrijven in Oost- en Noord-Azië zal de lay-out nog meer onvoorspelbaar maken, met ten minste acht mogelijke lay-outs (links/rechts startpositie, bovenaf/onder startpositie en wat het eerst gebeurt).

Vermijd verwijzingen naar schermkleuren

De kleur waarin iets wordt weergegeven, is afhankelijk van veel factoren, waaronder skins, door de site en de gebruiker geschreven JavaScript-scripts en gadgets, en lokale user-agent overrides om redenen van toegankelijkheid of technologische beperkingen. Niet-visuele gebruikersmiddelen zoals akoestische schermlezers en andere hulpmiddelen hebben zelfs geen concept van kleur. Daarom moet u zich niet verwijzen naar schermkleuren. (U mag ook om dezelfde reden ook niet alleen op de kleur vertrouwen als een mechanisme om de gebruiker over de status te informeren.)

Vermijd onvertaalde HTML-opmaak in berichten

HTML-opmaak die geen vertaling vereist, zoals het gegevens tussen ‎<div>-tags, rulers boven of onder, en dergelijke, moeten meestal geen deel uitmaken van berichten. Ze vormen beveiligingsrisico's, belasten de vertalers onnodig, verhogen de grootte van het berichtbestand en kunnen per ongeluk worden gewijzigd of overgeslagen tijdens het vertaalproces. Vermijd in het algemeen ruwe HTML in berichten.

Vertaalde berichten zijn vaak langer dan u denkt!

Als u berichtenbestanden in vreemde talen doorbladert, vindt u bijna nooit vertaalde berichten die korter zijn dan Chinese en zelden korter dan Engelse. U zult echter vaak vertalingen vinden die veel langer zijn dan Engelse.

Vooral in formulieren, voor de invoervelden, zijn Engelse berichten vaak beknopt en kort. Dat is vaak niet zo in vertalingen. Taalgebruikers kunnen een minder brede woordenschat in het Engels hebben en kunnen meerdere woorden of zelfs volledige zinnen nodig hebben om bepaalde concepten uit te leggen. Bijvoorbeeld, het korte Engelse bericht "TSV file:" moet letterlijk in een taal worden vertaald:

Schrijf hier een naam in die een verzameling computergegevens aanwijst die bestaat uit een sequentiële reeks regels die elk als een reeks informatievelden worden georganiseerd, waarbij de genoemde informatievelden omheind zijn en de omheinden tussen hen een enkel teken zijn van het soort dat een typemachine naar de volgende vooraf gedefinieerde positie brengt. Hier gaan we:

Dit is weliswaar een extreem voorbeeld, maar het gaat om het idee. Stelt u zich deze zin voor in een kolom in een vorm waar elk woord een eigen regel heeft, en het invoerveld verticaal in het midden van de volgende kolom staat. :-(

Vermijd het gebruik van vergelijkbare of identieke woorden om verschillende dingen of concepten aan te duiden

Pagina's kunnen bijvoorbeeld oudere revisies hebben (van een specifieke datum, tijd en bewerking), bestaande uit eerdere versies van die pagina. De woorden revisie en versie kunnen door elkaar worden gebruikt. Er doet zich een probleem voor, wanneer pagina's met versiebeheer worden herzien, en de herziening, d.w.z., het proces van het herzien ervan, wordt ook genoemd. Dit kan geen ernstig probleem vormen wanneer de twee synoniemen van "revisie" verschillende vertalingen hebben. Vertrouw daar echter niet op. Het is dan beter om het gebruik van "revisie" ook wel "versie" helemaal te vermijden, om te voorkomen dat het verkeerd wordt geïnterpreteerd.

Basiswoorden kunnen onvoorziene gevoelswaarden hebben, of helemaal niet bestaan

Er zijn enkele woorden die moeilijk te vertalen zijn vanwege hun zeer specifieke gebruik in MediaWiki. Sommige kunnen niet worden vertaald. In verschillende talen is er bijvoorbeeld geen woord "user" met betrekking tot "iemand die iets gebruikt". Evenzo, in Kölsch worden de Engelse woorden "namespace" en "apartment" met hetzelfde woord vertaald. In Kölsch zeggen ze ook "corroborator and participant" in één woord, omdat elke verwijzing naar "gebruik" te sterk "misbruik" zou betekenen. De term "wiki-farm" wordt vertaald als "stable full of wikis", omdat een boerderij met één gewas een contradictio in terminis zou zijn in de taal, en niet zou worden begrepen, enz..

Gebruik waar nodig ‎<code>, ‎<var> en ‎<kbd> tags

Als u het heeft over technische parameters, waarden of toetsenbordinvoer, markeer deze dan op de juiste manier als zodanig met behulp van de HTML-tags ‎<code>, ‎<var> en ‎<kbd>. Zo worden zij typografisch anders weergegeven dan de normale tekst. Dat helpt de lezers de tekst te lezen en te begrijpen en om verwarring, fouten en misverstanden te vermijden. Zorg ervoor dat uw berichtafhandeling dergelijke markeringen toestaat.

Symbolen, dubbele punten, haakjes, etc. zijn onderdelen van berichten

Veel symbolen zijn ook vertaalbaar. Sommige talen hebben andere soorten haakjes dan het Latijnse schrift. In sommige talen is een dubbele punt mogelijk niet geschikt na een label of invoerprompt. Het opnemen van die symbolen in berichten helpt om betere en minder Engelse klinkende vertalingen te maken, en vermindert ook de wirwar van code.

Er zijn bijvoorbeeld verschillende aanhalingstekenconventies die worden gebruikt in «Noors», ”Zweeds”, »Deens«, „Duits”, en 「Japans」.

Als u een tekst in de haakjes/tekens van een land moet zetten, kunt u de berichten parentheses ($1), brackets [$1] of quotation-marks "$1" gebruiken als volgt:

wfMessage( 'parentheses' )->rawParams( /* tekst voor tussen aanhalingstekens */ )->escaped()
wfMessage( 'brackets' )->rawParams( /* Tekst voor tussen haakjes */ )->escaped()
wfMessage( 'quotation-marks' )->rawParams( /* tekst tussen quotes */ )->escaped()

Verwacht niet dat symbolen en interpunctie er na de vertaling nog zijn

Talen die van rechts naar links worden geschreven (in tegenstelling tot het Engels) wisselen meestal met "volgende" en "voorgaande" links de pijl symbolen die worden gepresenteerd, en de plaatsing ervan in relatie tot een tekst kan eventueel worden omgedraaid. Het beletselteken kan worden vertaald naar "enz.", of naar woorden. Vraagtekens, uitroeptekens, punten worden anders geplaatst dan aan het einde van een zin, helemaal niet, of twee keer. Als gevolg hiervan moet u altijd al die tekens in de tekst van uw berichten opnemen en nooit proberen ze in de programmataal in te voeren.

Gebruik 'full stops'

Beëindig normale zinnen niet met 'full stops'. Dit is vaak de enige indicatie voor een vertaler om te weten dat het geen koppen of lijstkoppen zijn, die anders moeten worden vertaald.

Link anchors

Wikitext van links

Link anchors kunnen op verschillende technische manieren in berichten worden geplaatst:

1. via wikitext: … [[een wiki-pagina|anchor]] …,
2. via wiki-text: … [een-url anchor] …
3. een anchor tekst is een bericht in de MediaWiki namespace. Vermijd dit!

Dat laatste is vaak moeilijk of onmogelijk te hanteren voor vertalers, vermijd ook hier gefragmenteerde of 'lappendeken'-berichten. Zorg dat de "een-url" geen spaties bevat.

Gebruik zinvolle link anchors

Wees voorzichtig met je formulering. Link anchors spelen een belangrijke rol bij de beoordeling van pagina's door zoekmachines, zowel de gelinkte woorden als het doel anchor. Zorg ervoor dat het anchor de doelpagina goed beschrijft. Vermijd altijd gewone en generieke woorden. Bijvoorbeeld, "Klik hier" is een absolute no-go, omdat doelpagina's bijna nooit over "klik hier" gaan. Zet dat ook niet in zinnen rond links, want "hier" was niet de plek om te klikken. Gebruik in plaats daarvan precieze actiewoorden die aangeven wat een gebruiker krijgt als hij de link volgt, zoals "U kunt een bestand uploaden als u dat wilt."

Zie ook Help gebruikers te voorspellen waar ze heen gaan, en Mysterieuze navigatie, en De belangrijkste redenen waarom we klik hier niet als linktekst zouden moeten gebruiken.

Jargon en platte taal vermijden

Vermijd het jargon van ontwikkelaars en power-gebruikers in berichten. Probeer eenvoudige taal te gebruiken. Vermijd het zeggen "gelukt", "mislukt", "fout is opgetreden", enz., wanneer u de gebruiker wilt informeren dat er iets is gebeurd of er iets niet is gebeurd. Dit komt vanuit het perspectief van de ontwikkelaars om alles als 'ja' of 'nee' te zien, maar gebruikers willen gewoon weten wat er eigenlijk gebeurd is of niet gebeurd is, en wat ze er aan moeten doen (als er überhaupt iets aan gedaan kan worden). Dus:

• "Het bestand is met succes hernoemd" -> "Het bestand is hernoemd".
• "Hernoemen bestand mislukt" -> "Er is al een bestand met deze naam. Kies a.u.b. een andere naam."

Let op witruimte en regeleinden

MediaWiki's gelocaliseerde berichten worden meestal binnen de wiki bewerkt, hetzij door wiki-operaties op live wiki's, of door de vertalers op translatewiki.net. U moet zich ervan bewust zijn hoe witte ruimte, vooral aan het begin of einde van uw bericht, redacteuren zal beïnvloeden:

• Spaties en nieuwe regels aan het einde van het bericht worden altijd automatisch verwijderd door de wikitext-editor. Uw bericht mag niet eindigen met een ruimte of een nieuwe regel, omdat het verloren gaat wanneer het wordt bewerkt op de wiki.
• Spaties en nieuwe regels aan het begin worden niet automatisch verwijderd, maar ze zullen waarschijnlijk per ongeluk worden verwijderd tijdens het bewerken en moeten worden vermeden.

Begin en beëindig uw bericht met actieve tekst; als u een nieuwe regel of alinea nodig hebt er om heen, moet u omliggende code omgaan met het toevoegen ervan aan de teruggegeven tekst.

Er zijn enkele berichten die een ruimte nodig hebben aan het einde, zoals 'woord-scheidingsteken' (die in de meeste talen slechts uit een spatie bestaat). Om dergelijke gebruik te ondersteunen, zijn de volgende HTML-entiteiten toegestaan in berichten en worden ze omgezet in de werkelijke tekens, zelfs als het bericht anders geen wikitext of HTML-opmaak toestaat:

•   – spatie
•   of   – harde spatie
• ­ – zacht koppelteken

Overigens mogen alle andere syntaxiselementen die worden beïnvloed door vooraf opgeslagen transformaties ook niet worden gebruikt in berichten, omdat ze worden getransformeerd wanneer het bericht op de wiki wordt bewerkt.

Gebruik standaard hoofdletters

Hoofdletters geven vertalers hints over wat ze vertalen, zoals losse woorden, lijst- of menu-items, zinnen of volledige zinnen. Het juiste (standaard) gebruik van hoofdletters kan ook een rol spelen bij de beoordeling van uw pagina's door zoekmachines. MediaWiki gebruikt regel met hoofdletter (The quick brown fox jumps over the lazy dog) in interface-berichten.

Vergeet niet dat veel schrijfsystemen geen hoofdletters hebben, en sommige die ze hebben, gebruiken ze anders dan Engels. Gebruik daarom geen ALL-CAPS om nadruk aan te geven. Gebruik CSS, HTML ‎<em> of ‎<strong> voor het onderstaande:

Nadruk (Emphasis)

In normale tekst, moet opmaak met nadruk als vet of schuin deel uitmaken van de tekst van het bericht. Plaatselijke conventies met nadruk verschillen vaak, vooral sommige Aziatische scripts hebben hun eigen conventie. De vertalers moeten in staat zijn de nadruk op hun doeltaal en -gebieden aan te passen. Probeer "‎<em>" en "‎<strong>" in uw gebruikersinterface te gebruiken om opmaak per taal of per script toe te staan.

In de moderne schermlay-outs van Engelse en Europese stijlen wordt de nadruk minder gebruikt. Vermeld het nog steeds in uw berichtendocumentatie, omdat het waardevolle hints kan geven over hoe iets te vertalen. De nadruk kan en moet worden toegepast in andere culturele contexten, mits de vertalers er van op de hoogte zijn.

Zie ook

• Aanpassen
• Handleiding:Configuratie instellingen
• Manual:Skins
• Handleiding:Messages API
• Localisation/nl
• Handleiding MediaWiki architectuur en het lokaliseren van berichten
• translatewiki:FAQ