Een meertalige site bouwen

Voorwoord: Wat is een meertalige site?

Dit artikel is niet bedoeld als een ​​volledig tutorial over meertalige sites; ten eerste zijn er meerdere ’visies’ over wat met ’meertaligheid’ wordt bedoeld en ten tweede hebben we nog steeds niet kunnen bepalen wat "best practice" is.

We geven hier een overzicht van de verschillende tools die SPIP aanbiedt om meertalige websites te beheren. Het is aan aan jou om ze te gebruiken en te bespreken op de plekken die daarvoor zijn ingericht (forums, wiki, discussielijsten, enz.).

Maar denk voor je dit verder leest eens na over de volgende situaties:
-  Een poëzie-site, ingedeeld naar thema’s (rubrieken);
-  Een documentatie-site, bijvoorbeeld over SPIP;
-  Een corporate website in 25 talen;
-  Een tweetalige corporate website;
-  De site van een Bulgaarse vereniging met een paar pagina’s in het Engels.

De poëzie-website selecteert de taal per artikel; de SPIP documentatie-site zal een uitsplitsing maken in talen (hoofdrubrieken) en dezelfde artikelen in meerdere talen in de respectievelijke rubrieken publiceren. De corporate website in 25 talen zal waarschijnlijk niet alle 25 vertalingen tegelijk willen laten zien, maar nog steeds proberen om een parallel structuur te behouden; de tweetalige corporate website moet een vertaling voor elk onderdeel hebben in een tweedelige structuur, waarbij de ene taal wordt "gekloond" van de andere. De Bulgaarse vereniging heeft slechts één bepaald deel in het Engels beschikbaar, maar alle andere rubrieken zijn in het Bulgaars geschreven.

Principe

Om met deze verschillende (en nog andere) situaties om te kunnen gaan voorziet SPIP in een taal per artikel, per rubriek en per nieuwsbericht. Zowel in de publieke site als in het privé gedeelte bepaalt deze taal de typografische correctiemethode die op de teksten wordt toegepast; in de publieke site bepaalt de taal ook de elementen die rond deze "objecten" wordt ingevoerd, zoals de datumweergave en de taal van formulieren.

Om een meertalige site met SPIP te maken, moet de site eerst dienovereenkomstig worden geconfigureerd: in het taalgedeelte van de site-configuratie. Daar kan het meertalig beheer mogelijk worden gemaakt en worden de talen gekozen die op de site gebruikt gaan worden.

Configuratie van het privé gedeelte

Om de site gemakkelijker te onderhouden kan in de siteconfiguratie worden gekozen hoe nauwkeurig we de talen willen beheren, zodat fouten kunnen worden voorkomen [1]. SPIP biedt drie verschillende interface-niveaus voor de taalkeuze van een artikel (en nieuwbericht, enz.). Je vindt ze hieronder in oplopende volgorde van complexiteit:

-  Per hoofdrubriek (of sector, een rubriek van het eerste niveau): elke hoofdrubriek heeft een (door een beheerder instelbare) taal, die wordt overgenomen door de subrubrieken en alle publicaties. Deze instelling voldoet voor de meeste meertalige sites. De structuur en de interface blijven eenvoudig.

-  Per rubriek: een fijnere instelling, waarbij de taal op elk niveau van rubriek kan worden aangepast.

-  Per artikel: de taal kan worden gewijzigd in elk artikel. Deze keuze is in overeenstemming met de vorige (je kunt nog altijd kiezen voor een taal per rubriek, maar soms voor enkele artikelen een uitzondering maken) en maakt alle denkbare verfijningen mogelijk. Maar wees voorzichtig, want je loopt het risico een onoverzichtelijke site te maken...

Meertalige blokken

Bepaalde objecten, zoals auteurs en trefwoorden, moeten afwijkend worden weergegeven naar gelang de taal van een artikel. Het is niet de bedoeling deze objecten te klonen in een ander taal, want het is tenslotte één en dezelfde auteur en het «concept» van een trefwoord is ook niet taalafhankelijk. De objecten hebben dan ook geen taaleigenschap, maar toch is het mogelijk een context-afhankelijke taal weer te geven met behulp van «multi blocs». Zo zou je hetzelfde trefwoord verschillend kunnen weergeven: «Nederland», «The Netherlands», «Pays-Bas».

Het «multi bloc» is een SPIP opmaakcode, waarvan de structuur redelijk intuïtief is. Nemen we het voorbeeld dat we hierboven gaven, dan zou dit als volgt in het privé gedeelte worden ingevoerd:

<multi>[nl]Nederland [en]The Netherlands[fr]Pays-Bas</multi>

Wordt een multi bloc opgeroepen in een context waarvan de taal niet is voorzien, dan wordt altijd het eerste deel weergegeven, dus «Nederland» in ons vorige voorbeeld. Zo wordt voorkomen dat niets wordt weergegeven [2].

NB: dezelfde structuur kan ook worden toegepast in skeletten, vgl. Skeletten internationaal maken.

Bakens en lussen: wat te doen

We gaan ons nu op de publieke site richten. Onze artikelen kunnen in de juiste taal geschreven worden, maar de skeletten voor de pagina’s van de site moeten wel rekening houden met de meertalige configuratie van de site.

1. We beginnen met goed nieuws: meertaligheid kan met één en hetzelfde skelet worden weergegeven; het is niet noodzakelijk om voor iedere taal een andere ste skeletten te maken. Hetzelfde skelet past zich automatisch aan aan de huidige taal.

Alle elementen rond een artikel zullen in de aangegeven taal worden weergegeven. Dat geldt zowel voor de publicatiedatum, als voor het formulier waarmee bezoekers in een forum kunnen reageren of waarmee ze een petitie kunnen ondertekenen, enz. Meer algemeen gezegd: alle SPIP bakens in een lus ARTICLES zullen in de taal van het artikel worden weergegeven (en dat geldt ook voor rubrieken en nieuwsberichten).

Voorbeeld: wanneer je homepage een opsomming van de 10 laatst gepubliceerde artikelen bevat met hun datum van publicatie, zal die datum worden weergegeven in de taal van het artikel.

Let op: deze werking gaat ervan uit dat de taal onderdeel vormt van de vertalingen van SPIP. Is dat niet het geval, dan zal de standaardtaal van de site worden gebruikt.

2. De schrijfrichting

Wanneer je site talen bevat die van rechts naar links geschreven worden, dan moet je kleine aanpassingen maken aan de HTML voor een probleemloze weergave [3].

SPIP heeft hier een aantal speciale bakens voor: #LANG_DIR wat de schrijfrichting van de huidige taal aangeeft. Dit baken kan gebruikt worden als attribuutwaarde van dir in de meeste HTML tags (dat betekent dus «ltr» voor links naar rechts en «rtl» voor rechts naar links.

Een lus voor de weergave op de homepage wordt dus:

<ul>
<BOUCLE_sommaire(ARTICLES){par date}{inverse}{0,10}>
  <li dir="#LANG_DIR">[(#DATE|affdate)]:
  <a href="#URL_ARTICLE">#TITRE</a></li>
</BOUCLE_sommaire>
</ul>

Is de pagina-indeling gebaseerd op linkse of rechtse uitlijning, dan wordt dit voor de rtl-talen omgekeerd: je kunt daarbij denken aan alle elementen van een skelet die zijn aangeduid met left of right door de bakens #LANG_LEFT en #LANG_RIGHT. Voor de definitie van de pagina zelf kunnen we hiermee aangeven wat de instelling is:

<html dir="#LANG_DIR" lang="#LANG">
<head>
...
</head>
<body>
...
</body>
</html>

3. Links voor vertalingen

SPIP biedt een systeem voor het vertalen van artikelen: je kunt aangeven wat (welke artikelen) de vertalingen zijn van een bepaald artikel (deze vertalingen zijn dus artikelen op zich). De voorwaarde {traduction} kan in een lus ARTICLES alle versies van hetzelfde artikel weergeven.

Om bijvoorbeeld alle vertalingen van het huidige artikel weer te geven, wordt dat:

<BOUCLE_trad(ARTICLES){traduction}{exclus}>
[<a href="#URL_ARTICLE" rel="alternate" hreflang="#LANG">(#LANG|traduire_nom_langue)</a>]
</BOUCLE_trad>

De voorwaarde {exclus} zorgt ervoor dat het artikel zelf niet wordt weergegeven en het filter |traduire_nom_langue toont de naam van de taal (in zijn eigen taal) in plaats van de taalcode (zo kunnen we dus « français » toten in plaats van «fr», «English» in plaats van «en», enz.).

-  Een extra voorwaarde {origine_traduction} selecteert alleen de «originele versie» van het artikel.

Een wiki-pagina in verzamelt de voorbeelden van lussen met deze voorwaarden op: spip-contrib.net.

4. Aanvullende elementen

Een aantal extra elementen kunnen nog bijdragen tot een meertalige site:

— de voorwaarde {lang_select} forceert de taalkeuze in de lus (AUTEURS), wat normaal niet gebeurt (omgekeerd vertelt de voorwaarde {lang_select=non} aan de lussen (ARTICLES), (RUBRIQUES) of (BREVES) om de taalkeuze te negeren).

— de variabele $forcer_lang geeft SPIP aan dat het moet controleren of de bezoeker een taalcookie heeft en het hem vervolgens naar de corresponderende pagina moet sturen. Dit gebeurt bijvoorbeeld standaard bij de toegang tot het privé gedeelte van SPIP.

— de bakens #MENU_LANG (en #MENU_LANG_ECRIRE) tonen een taalmenu waarmee de bezoeker «deze pagina in het ...» kan kiezen. Het eerste baken toont de talenlijst van de site; de tweede is die voor het privé gedeelte (je vindt hem op het inlogscherm voor het privé gedeelte).

— tenslotte bieden optionele voorwaarden je de mogelijkheid eenzelfde lus (in feite eenzelfde skelet) te gebruiken voor alle artikelen in alle talen, of alleen de artikelen in de taal die via de URL wordt doorgegeven. Dat kan bijvoorbeeld nuttig zijn in de backend, of in een zoeklus:

<BOUCLE_recents(ARTICLES){lang?}{par date}{inverse}{0,10}>

<BOUCLE_recherche(ARTICLES){lang?}{recherche}{par points}{inverse}{0,10}>

Internationale skeletten voor een zeer veeltalige site

Het bovenstaande heeft ons toegelaten om het "SPIP gedeelte" van ons skelet meertalig te maken: alles wat uit een lus komt, wordt in de juiste richting en met de juiste typografie geschreven en de door SPIP geleverde producten (formulieren, data ... ) is in de gevraagde taal.

Voor een site met een bescheiden aantal talen (bijvoorbeeld tweetalig), of met een hoofdtaal en enkele verwante talen kunnen we hier stoppen. De "hardcoded" teksten in skeletten (dat wil zeggen: direct in HTML geschreven) zoals "sitemap", "homepage" of "menu" kunnen soms in één taal worden weergegeven. Zo niet, dan zal een meertalige website aparte skeletten moeten gebruiken voor elke taal.

Maar voor een effectief beheer van een meertalige site is het onrealistisch om afzonderlijke skeletten bij te houden, of een navigatiesysteem in één taal aan te bieden (zelfs als is dat in het Engels of in Esperanto ...). Om met een ​​enkele set van skeletten alle talen te kunnen bereiken, moeten we de skeletten "internationaliseren" om de tekst onafhankelijk van de HTML te veranderen. Deze taak vereist een speciale aanpak die wordt besproken in een afzonderlijk artikel.

Wat aanvullende opmerkingen

-  De typografische opmaakcodes <code> en <cadre> leveren altijd een tekst die van links naar rechts geschreven wordt, zelfs als de taalinstelling het omgekeerde zegt. Deze twee opmaakcodes zijn bedoeld om informatica code of gegevens weer te geven, die nagenoeg altijd van links naar rechts geschreven worden (en ook meestal in westers schrift).

-  Voor wat betreft de schrijfrichting zijn de HTML attributen left en right ook aanwezig in stylesheets. Dat wil zeggen dat je misschien een deel van je stylesheet in het skelet moet opnemen (voor het gebruik van de bakens #LANG_LEFT en #LANG_RIGHT) in plaats van ze in een apart bestand op te nemen.

Een korte samenvatting van het gedrag van SPIP bakens die betrekking hebben op de schrijfrichting:

-  Met het filter |direction_css kan je een stylesheet «inverteren» voor talen die van rechts naar links worden geschreven. Heet die stylesheet bijvoorbeeld style.css, dan zal het filter in voorkomend geval een stylesheet style_rtl.css gebruiken en als deze niet bestaat wordt het gemaakt, waarbij overal left door right wordt vervangen en omgekeerd. Het wordt vervolgens opgeslagen in map IMG/cache-css/. Het filter wordt meestal toegepast op een baken #CHEMIN, zoals: [(#CHEMIN{style.css}|direction_css)].