 |
Other languages Deutsch ; English ; Français ; Nederlands ; português brasileiro ; |
}}
| In het kort: Er is vaak sprake van grote verwarring en verkeerd gebruik van de termen i18n en l10n. Ze zijn verwant, maar hebben niet dezelfde betekenis; ze verwijzen naar verschillende niveaus van implementatie en expertise, dus een goed begrip is belangrijk om te zien waar precies een probleem of ontwikkelingsbehoefte thuishoort. |
Wat die acroniemen betekenen
Nou, wat betekenen die vreemde acroniemen eigenlijk? Het zijn in feite afkortingen die bestaan uit de eerste en laatste letter van een woord, en daartussen staat het aantal letters.
- i18n = Internationalization: i, dan 18 letters, dan n
- l10n = Localization: l, dan 10 letters, dan n
Is dat niet hetzelfde?
Dus, vraagt u zich misschien af, zijn internationalisatie en lokalisatie niet hetzelfde? Eigenlijk niet.
Er is veel verwarring; deels omdat de concepten relatief nieuw zijn; deels ook om historische redenen. Historisch gezien werd ondersteuning van computers die niet alleen Engelstalig waren, in het begin althans, gedaan met verschillende ad-hoc oplossingen, die alleen voor één taal geschikt waren. Dus u had bijvoorbeeld een besturingssysteem gelokaliseerd voor, laten we zeggen, Frans, en een andere versie voor Spaans. Ze kunnen heel goed onverenigbaar zijn, zelfs als beide talen daadwerkelijk een gemeenschappelijke en vrij eenvoudige tekenset delen.
Anders gezegd, historisch gezien is l10n gemaakt, voordat er aan i18n werd gedacht.
Maar conceptueel gezien moet i18n eerst komen; aangezien internationalisatie het proces is om ervoor te zorgen dat een stuk software daadwerkelijk flexibel genoeg is, en in staat is meerdere potentiële landinstellingen te ondersteunen. Er is geen echte taal betrokken bij het i18n-proces; een applicatie wordt misschien nooit vertaald, maar als zij goed geïnternationaliseerd is, is het vertalen ervan vrij eenvoudig (en, belangrijker nog, vereist helemaal geen ontwikkelings- of computervaardigheden, alleen kennis van de doeltaal). Internationalisatie maakt software dus 'localisatie-vriendelijk'.
Lokalisatie daarentegen draait (voornamelijk, zie hieronder) om het vertalen naar een gegeven, echte, taal. Lokalisatie vereist op zichzelf geen internationalisatie, maar als een programma niet eerst is geïnternationaliseerd, betekent dit dat het lokalisatieproces vrij diepgaande wijzigingen vereist in de broncode van het programma. Dat wil zeggen: er zijn ontwikkelingsvaardigheden voor nodig. Vroeger werd lokalisatie soms gedaan door 'gewoon' de broncode te bewerken en de tekst-reeksen in die bron te wijzigen. Dat leidt tot twee (of meer) verschillende binaire bestanden. Oftewel: twee (of meer) verschillende producten om te ondersteunen, met elk een apart versiebeheer, aparte foutentracering, etc. Soms zijn die twee zelfs onverenigbaar met elkaar. En als u het programma naar een andere taal wilde porteren, moest u dat allemaal helemaal opnieuw doen (en beslissen van welke versie u moest afwijken). Bovendien was er nooit een goed generaliseerbaar overzicht van het probleem; als er lokalisatie naar een nieuwe taal met specifieke behoeften werd aangevraagd, kon dat alles kapotmaken, omdat het niet was gepland.
Dus, l10n zonder i18n is slecht, heel slecht. Hopelijk is dit tegenwoordig, en met name in de wereld van de vrije software, ongewoon. In onze wereld van de vrije software hebben we heel goede internationalisatie-geraamtes, ingebouwd in de kern van de algemene gereedschapskisten (een gereedschapskist is een verzameling van werktuigen en bouwblokken waarmee ontwikkelaars programma's bouwen). Die frameworks zijn generiek genoeg om alle menselijke schrijfsystemen die momenteel in gebruik zijn, te ondersteunen en te omvatten.
De twee concepten van i18n en l10n zijn twee verschillende lagen. Ze zijn met elkaar verbonden, maar ze bevinden zich op verschillende niveaus - dat wil zeggen, ze vereisen de hulp van verschillende mensen, met verschillende vaardigheden. Dat is belangrijk om te weten, want het melden van een probleem op het verkeerde niveau zal niet helpen het op te lossen.
I18N
Internationalisatie is het proces (of het concept van het proces) om een programma "internationaal" te maken; dat wil zeggen, het programmain staat stellen om vrijwel elke taal of lokale instelling op aarde te ondersteunen.
Het omvat altijd wijzigingen in de broncode, dat wil zeggen dat dit werk ontwikkelaars vereist, die bovendien kennis moeten hebben van de i18n-problematiek. Er zijn verschillende aspecten van i18n, sommige complexer dan andere:
- De mogelijkheid om tekst weer te geven/af te drukken
- ondersteuning voor elk complex lettertype
- ondersteuning voor tekens-normalisatie
- ondersteuning voor glyph-substitutie en -rendering. Er bestaat geen gelijkheid tussen een letterteken en een glyph. In plaats daarvan produceren sommige reeksen lettertekens (kan zelfs een reeks zijn van slechts één letterteken) enkele reeksen glyphs (kan een reeks van één teken zijn)
- ondersteuning voor glyph-herordening (de weergave is niet altijd in dezelfde volgorde als logisch gesproken/geschreven)
- ondersteuning voor bidirectionele rendering (zowel van links naar rechts als van rechts naar links)
- De mogelijkheid om tekst te manipuleren
- ondersteuning voor manipulaties van tekstreeksen in programma's
- ondersteuning voor muisselectie, knippen en plakken, enz. (bedenk dat u glyphs op het scherm selecteert, maar de buffer selecteert tekst (lettertekens) => er komt complexe substitutie bij kijken)
- hulpprogramma's voor het converteren van tekensets (omdat we te maken hebben met een pre-Unicode erfenis)
- zoeken naar tekst (grep, etc.)
- sorteren van tekst op basis van complexe regels
- De mogelijkheid om tekst in te voeren
- ondersteuning voor het definiëren van toetsenbord-indelingen
- ondersteuning voor het koppelen aan invoertoepassingen, voor complexe gevallen waarbij een toetsenbord-indeling niet voldoende is)
- De mogelijkheid om datum/tijd te manipuleren/weer te geven
- weergave-/invoerformaat
- definiëren van de eerste dag van de week
- definiëren van tijdzones
- definiëren van niet-gregoriaanse kalenders
- functies om te converteren tussen verschillende formaten/kalenders
- De mogelijkheid om lokale instellingen te definiëren en te verwerken
- verschillende eenheden (km/mijl °C/°F, etc.), monetair, etc.
- verschillende manieren om getallen te formatteren/weer te geven
L10N
Lokalisatie is het proces (of het concept van het proces) om een toepassing "gelokaliseerd" te maken; dat wil zeggen, werkend in een gegeven lokale en concrete context, aangepast aan de gebruiker.
Lokalisatie leidt niet tot enige wijziging in de broncode; ontwikkelaars zijn er niet bij betrokken (nou ja, slechts een beetje, om de eerste haak toe te voegen; wanneer een taal beschikbaar is, moet een ontwikkelaar deze in een lijst zetten, toegang verlenen aan het l10n-team, etc.).
L10n gaat over het leveren van de inhoud, die de containers vult die het i18n-proces heeft gecreëerd.
De verschillende aspecten zijn:
- vertaalbare tekstgegevens vertalen (dat is de bekendste)
- unieke gelokaliseerde tekstgegevens leveren (geen vertaling van een bestaande tekst maar een zelfstandige tekst), indien nodig
- spellingcontrole (zie hieronder)
- toetsenbord-indelingen
- invoermethoden (zie hieronder)
- sorteerregels
Hier zijn geen ontwikkelaars bij betrokken, zoals ik al zei. Nou, in sommige gevallen kan er mogelijk enige ontwikkeling nodig zijn; bijvoorbeeld voor voor een aantal zeer specifieke dingen, zoals het maken van een nieuwe spellingcontrole, uniek voor een taal of taalfamilie, of een invoermethode-programma (maar er bestaan ook generieke spellingcontroles en invoermethoden, waarbij u alleen l10n-gegevens hoeft te leveren).
In het kort
- l10n: l10n-problemen zijn alleen van belang voor vertalers van een bepaalde taal; niemand anders bemoeit zich er mee, niemand kan er iets aan veranderen, alleen de vertalers voor die specifieke taal kunnen het oplossen.
- i18n: i18n-problemen zijn een probleem in de i18n-infrastructuur. Dit kan potentieel veel talen raken (zelfs als er misschien maar één taal de symptomen tegenkomt), maar vertalers kunnen er niets aan doen, alleen ontwikkelaars kunnen dat.
