ISO 639

ISO-standaard
(Doorverwezen vanaf RFC 3066)

ISO 639 is in de taaltypologie een internationale norm, uitgegeven door de International Organization for Standardization (ISO), voor het coderen van talen in twee- en drieletterige codes. ISO 639 bestaat al erg lang in twee basissmaken, ISO 639-1 en ISO 639-2. Een derde versie, ISO 639-3 is per 5 februari 2007 door de ISO bekrachtigd.[1] Voor de gehele ISO 639 geldt dat de geprefereerde schrijfwijze van de taalcodes volledig in onderkast is, maar er wordt nadrukkelijk bij vermeld dat in verwerkende systemen het onderscheid tussen onderkast en bovenkast niet verplicht is.

De taalcode mag niet verward worden met landcodes, zoals ISO 3166-1. Zo is be de taalcode voor Wit-Russisch (Belarussisch) maar is BE de landcode voor België.

ISO 639-1

bewerken

De oudste variant ISO 639-1 legt tweeletterige taalcodes vast voor een tamelijk beperkt aantal veelgebruikte talen. Om taal- en landcodes te onderscheiden, vooral wanneer ze dezelfde lettercombinatie zijn, wordt aanbevolen de ISO 639-taalcodes in kleine letters te schrijven en de ISO 3166-landcodes in hoofdletters.

Talen die een ISO 639-1-code hebben, hebben per definitie ook een ISO 639-2-code. Converteren gaat gemakkelijk via de zoekopdracht op de site van SIL International (SIL).[2]

ISO 639-2

bewerken

ISO 639-2 is hoofdzakelijk ontstaan door de taalcodes uit ISO 639-1 samen te brengen met de MARC-taalcodes, een verzameling drieletterige codes ontwikkeld voor bibliografische toepassingen die al in 1987 als ANSI Z39.53 tot standaard verheven was. Wel zijn er door verschillende voorkeuren en historie van beide standaarden subtiele verschillen in de opgenomen 'talen' en de gebruikte codes.

Om dat enigszins op te vangen bestaan in ISO 639-2 soms twee codes voor één taal, opgesplitst in twee subversies van de standaard. De versie ISO 639-2/B wordt voor bibliografie gebruikt en ISO 639-2/T voor terminologie. Hoewel ze grotendeels gelijk zijn kunnen er verschillen tussen optreden. Momenteel[bron?] zijn de /B en /T codes voor 23 talen verschillend, onder andere voor Nederlands (/T=nld, /B=dut).

ISO 639-2/B (Bibliografie) is gebaseerd op MARC-voorkeur:

  • voorkeur van de landen die de taal gebruiken
  • bestaande codes in nationale en internationale bibliografische gegevensbanken
  • de naam van de taal in de taal zelf of in het Engels

ISO 639-2/T (Terminologie) is gebaseerd op ISO-voorkeur:

  • de naam van de taal in de taal zelf
  • voorkeur van de landen die de taal gebruiken

ISO 639-3

bewerken

ISO 639-1 en -2 zijn vooral ontstaan vanuit technische organisaties en dekken lang niet alle bekende talen af - zelfs ISO 639-2 omvatte aanvankelijk maar ca. 400 talen. Met name in linguïstiek gespecialiseerde instituten zoals SIL International hadden hun eigen coderingen met duizenden 'talen' (zoals de SIL-codes uit de Ethnologue), die totaal niet op ISO 639 aansloten.

Met ISO 639-3 worden deze werelden nu samengebracht in een aanzet om alle bekende 'talen' onder te brengen in een coderingssysteem met drie letters per taal, waarbij ook coderingen voor historische/dode en geconstrueerde talen worden opgenomen. Hierbij zijn de ISO 639-2-codes samengevoegd met de codes uit de Ethnologue (meer dan 6900 levende talen) en Linguist List (voor historische/dode en geconstrueerde talen en dergelijke). SIL is daarbij aangewezen als de registratieve autoriteit voor het project.[3]

RFC 3066BIS

bewerken

RFC 3066 is ondertussen vervangen door RFC 3066BIS.[4] Toch steunt die nog steeds op ISO 639-1 en -2 en volgt grotendeels dezelfde regels als de oude RFC 3066. Een belangrijke ontwikkeling is dat IANA en ISO overeengekomen zijn dat ISO 639 zodanig verder wordt ontwikkeld dat al bestaande op RFC 3066bis gebaseerde taalcoderingen niet meer ongeldig zullen kunnen worden en dat IANA in RFC 3066bis ook nog opmerkingen inbouwt om het scheppen van nieuwe ISO 639-codes uit te sluiten of op te vangen. De standaard is dus robuuster geworden.

Opvallend is dat de huidige versie zich nog steeds baseert op het beperkte aantal door IANA geregistreerde alfa-3 codes uit ISO 639-2 en dus nog niet de enorme lijst van ISO 639-3 specificeert.

Wel zijn er extra mogelijkheden gedefinieerd voor toekomstige uitbreidingen (waardoor software daar nu in principe al rekening mee kan houden) en zijn wat extra coderingsmogelijkheden toegevoegd. Door deze nieuwe mogelijkheden zijn veel voor de oude 3066 expliciet apart geregistreerde combinatie-codes impliciet ondersteund.

Om een idee te geven is de specificatie hieronder sterk samengevat en onvolledig weergegeven, maar wel met de meest praktisch-relevante regels:

Primaire taal-subtag

bewerken

Vrijwel gelijk aan de regels voor de oude RFC 3066, met het verschil dat de startversies van ISO 639-1 en -2 zijn vastgelegd, en dat veranderingen/uitbreidingen hieraan zodanig zullen zijn dat bestaande met RFC 3066 geconstrueerde taalcodes geldig blijven.

  • Alle tweeletterige codes zijn ISO 639-1:2002 of latere uitbreidingen hierop.
  • Alle drieletterige codes zijn ISO 639-2:1998 of latere uitbreidingen hierop (qaa t/m qtz zijn voor privé gebruik).
  • Vier- tot achtletterige codes zijn vooralsnog gereserveerd.

Nog steeds geldt dat voor alle talen die zowel een twee- als een drieletterige code hebben de alpha-2 code gebruikt wordt en dat van de drielettercodes de 'Terminologie' variant (ISO 639-2/T) gebruikt wordt (maar alle talen waarbij /T en /B verschillen hebben ook een alpha-2 code, dus speelt dit praktisch gezien geen rol).

Script-subtag

bewerken

Script-subtags beschrijven de gebruikte schriftvorm zoals het Latijnse alfabet, cyrillisch of ook braille.

  • Er mag maximaal één script-subtags worden gebruikt (of geen) en deze moet achter de primaire taal-subtag komen en voor eventuele ander subtags.
  • De geprefereerde schrijfwijze (maar niet verplicht) is beginnend met een kapitaal en de overige lettertekens in onderkast.
  • Alle vierletterige codes zijn ISO 15924 alpha-4 scriptcodes
  • De codes 'Qaaa' t/m 'Qabx' zijn voor privé gebruik.

Er is een groot aantal script codes geregistreerd, waaronder Arabisch ('Arab'), Braille ('Brai'), Cyrillisch ('Cyrl'), Grieks ('Grek'), Latijns ('Latn') etc.

Regio-subtags

bewerken

De reeds bestaande mogelijkheid voor landcodes volgens ISO 3166 is uitgebreid met een aantal regiocodes uit de lijst UN M.49 voor identificatie van regio's van de Verenigde Naties. Deze samenvatting van de regels geeft een globaal idee van de toepassing:

  • Maximaal één regio-code mag gebruikt worden en wel achter taal- en script-subtags en voor alle andere.
  • Alle tweeletterige codes zijn ISO 3166-1 alpha-2 landcodes (AA, QM-QZ, XA-XZ en ZZ zijn voor privé gebruik).
  • Alle drieletterige codes die met een cijfer beginnen zijn UN M.49, maar niet alle UN M.49 codes zijn toegestaan:
    • Niet: Alles waar ook een ISO 3166 alpha-2 code voor bestaat.
    • Niet: Economische groeperingen.
    • Wel: Macro-geografische gebieden (niet aan territoriale grenzen gebonden).
    • Wel: Codes voor landen of gebieden met onduidelijk gedefinieerde ISO 3166 alpha-2 codes.

Een paar voorbeelden van geregistreerde regiocodes zijn: Wereld (001), Afrika (002), Europa (150), West-Europa (155), Latijns-Amerika en het Caribisch gebied (419).

Variant-subtags

bewerken

Deze leggen algemeen erkende varianten van talen of dialecten vast die niet door de al bestaande taal-subtags worden afgedekt. Hier zijn geen algemene standaarden voor en ze worden bepaald op basis van (verplichte) registratie bij IANA.

  • Variant subtags komen achter alle gedefinieerde subtags en voor alle uitgebreide- en privé-subtags.
  • Codes die met een letter beginnen moeten minimaal vijf lettertekens lang zijn.
  • Codes die met een cijfer beginnen moeten minimaal vier lettertekens lang zijn.
  • Er kan bij de registratie een prefix zijn vastgelegd die bepaalt achter welke voorloop-taalcodes de variant code uitsluitend geldig is (stel de Sloveense variant code 'nedis' is gedefinieerd met prefix 'sl' dan zijn sl-nedis en sl-IT-nedis geldig, maar it-IT-nedis niet).

Er zijn momenteel opvallend weinig variant-subtags bij IANA geregistreerd. Behalve een aantal taalvarianten zoals dialecten zijn bijvoorbeeld voor het Duits spellingsvarianten voor de taalrevisies van 1901 en 1996 geregistreerd. Zo is de-1996 dus Duits 'nieuwe spelling' of de-CH-1901 Zwitsers Duits oude spelling. Voor het Nederlands zijn zulke varianten overigens niet geregistreerd.

Uitbreidings- en privé-subtags

bewerken

Verder kunnen er nog uitbreidings-subtags geregistreerd worden. Deze beginnen dan met een enkele letter met minteken (een singleton), gevolgd door de tag, analoog aan de privé-tags die ook al in de oudere RFC 3066 mogelijk waren (x-blabla). Meer dan één uitbreidings-subtag is toegestaan, maar elke singleton mag maar één keer in de complete taalcode voorkomen. Dus bijvoorbeeld nl-BE-a-mijncode-b-jouwcode zou kunnen (mits geregistreerd), maar en-c-yourcode-c-thatcode kan nooit vanwege de dubbele c- singleton.

De standaarden toepassen

bewerken

Het in kaart brengen van talen en taalvarianten is geen erg exacte wetenschap, emoties en politiek hebben duidelijk invloed op de indeling in categorieën en er kan bijna eindeloos worden doorgegaan met het aanbrengen van verfijningen. Voeg daar nog verhitte discussies aan toe over wat nu precies een taal, dialect, streektaal (of wat dan ook) is en het wordt snel onoverzichtelijk.

Zeker voor toepassing in geautomatiseerde (informatie)systemen is een verregaande verfijning eerder hinderlijk dan bevorderlijk. De tweeletterige ISO 639 alpha-2 codes voldoen voor verreweg de meeste toepassingen, omdat de meestgebruikte talen er toch al mee kunnen worden aangeduid (zeker in combinatie met de ISO 3166 landcodes). De alpha-3 codes uit ISO 639-2 dekten nog eens een grotere hoeveelheid talen af, maar zorgden tegelijkertijd voor wat problemen vanwege de verschillen tussen de /B en /T varianten.

Op basis van ISO 639 en de RFC 3066 zijn er in de loop der tijd door 'derden' substandaarden ontwikkeld om op een gestructureerde manier meer talen te coderen. Zo heeft bijvoorbeeld SIL International een uniforme manier voorgesteld om de SIL-codes uit de Ethnologue in het RFC 3066 kader toe te passen als x-sil-XXX, waarbij 'XXX' de SIL-taalcode is, dus bijvoorbeeld x-sil-VLS voor Vlaams en x-sil-DUT voor Nederlands.

SIL heeft overigens met de 15e editie van de Ethnologue al hun codes gelijk getrokken met ISO 639-3 en zal dus voortaan ook nld en vls gebruiken (was DUT en VLS). Wel zijn er verschillen tussen de nieuwe SIL-codes en ISO 639-3 in die zin dat sommige talen waarvoor ISO-codes bestaan niet in de Ethnologue voorkomen en dat er vooral bij de keuzes die gemaakt zijn voor het groeperen van talen (familie- of groepscodes) verschillen zijn.

RFC 3066bis stelt overigens duidelijk dat het altijd de voorkeur geniet een zo eenvoudig mogelijke code toe te passen en extra subtags nooit te gebruiken als ze niets wezenlijks toevoegen. Gebruik dus nooit nl-Latn-NL voor toepassingen waarbij niet verwacht wordt dat er verschil wordt gemaakt in schrift en in lokale taalvarianten van het Nederlands; simpelweg nl is dan genoeg. Mocht je echter een toepassing hebben waarin bijvoorbeeld ook braille mogelijk is (voorleessysteem?) kan het wel zinnig zijn om delen te markeren als nl-Latn of nl-Brai.

De invoering van ISO 639-3 eraan komt zal vermoedelijk wel consequenties hebben voor het gebruik van de oude combinatiecodes. Mogelijk gaan we Vlaams voortaan aanduiden als vls (ISO 639-3), maar oude coderingen als nl-BE of x-sil-VLS zullen wel niet als sneeuw voor de zon verdwijnen, dus zal veel software deze voorlopig ook nog wel moeten ondersteunen. IANA heeft overigens dergelijke combinatiecodes nooit voor Vlaams geregistreerd en brengt nadrukkelijk 'Flemish' onder bij nl.

Verwarring, probleemgevallen en onenigheid over welke code nu wanneer de voorkeur geniet zullen ook met de komst van ISO 639-3 niet uit de wereld zijn. Tot nu kon je je misschien druk maken of Vlaams nu nl-BE moest zijn of misschien nl-FR (vanwege Frans-Vlaanderen) of misschien dan toch x-sil-VLS of nog wat anders. Dergelijke problemen zullen blijven, maar dan nu op veel detaillistischer niveau - dus om bijvoorbeeld weer varianten binnen het Vlaams te kunnen coderen.

Een ander/nieuw probleem dat nu eventueel zou kunnen ontstaan is onduidelijkheid door "macrotalen". Zo hadden we ooit qu (of que) heel in het algemeen voor Quechua. Dat is er nog steeds, maar geldt in ISO 639-3 als macrotaal voor een veertigtal individuele talen uit de Quechuan-taalfamilie. Bij reeds bestaande, als qu/que gemarkeerde documenten, zou je nu dus de vraag moeten stellen of deze voortaan inderdaad als lingua franca-variant van het Quechua door het leven moeten gaan of dat er niet toch eerder voor een van de individuele taalcodes gekozen moet worden. Veel nazorg dus en voorlopig veel mogelijke twijfel over de interpretatie of 'juistheid' van oude codes qu of que.

Bij het opstellen van ISO 639-3 is aanvankelijk foutief aangenomen dat de oude fy/fry code in ISO 639-1 en -2 voor 'Fries in brede zin' stond en is dus fry opgenomen als macrotaal (bovendien met een verkeerde keuze voor de talen die binnen deze groep zouden horen), waarbij fri dan de functie kreeg van het Nederlandse Frysk, maar inmiddels is SIL tot het inzicht gekomen dat een macrotaal voor Fries niet nodig is en fry altijd al het Nederlandse Westerlauwers Fries als individuele taal betekende. De code die voor Westerlauwers Fries was ingevoerd (fri) is daarom nu alweer als Retired gemarkeerd en moet dus nooit gebruikt gaan worden (de norm is immers nog niet bekrachtigd). Wel nieuw zijn nu de andere individuele 'talen' Nordfriisk (frr), Saterfries (stq) en Oost-Fries Platduits (frs) (waarbij die laatste dus geen Friese taal is, maar een Nedersaksisch dialect).

Op een vergelijkbare manier zou je vraagtekens kunnen zetten bij het gebruik van nl. Dat is géén macrotaal geworden, maar is nu als individuele taal nld op gelijke voet naast onder andere Vlaams (vls), Zeeuws (zea), Twents (twd) en dergelijke gezet. Van oudsher veegde je zonder na te denken al die talen gewoon onder nl, maar nu bedoel je kennelijk met nl impliciet nld. Een Vlaams document als nl coderen zou dus in zekere zin niet meer juist zijn, maar door vls te gebruiken breng je misschien een nuancering aan die te ver voert en dus ook niet wenselijk is.

Bedenk wel dat IANA de codes uit ISO 639-3 nog helemaal niet geregistreerd heeft voor RFC 3066(bis) en dat een en ander voor toepassing in RFC 3066 conforme systemen (internet!) dus officieel nog geen rol speelt.

Het werken met deze taalcodes blijft dus een kwestie van nadenken, oppassen en de goede keuzes maken.

Tabellen

bewerken
  Voor de lijst van taalcodes, zie Lijst van ISO 639-codes.
  Voor de lijst van Wikipedia's met hun codes, zie Lijst van Wikipedia's.

Onderstaande tabel illustreert verschillen tussen ISO 639-1, -2 en -3 en andere taalcodesystemen aan hand van een paar voorbeeldtalen:

ISO/DIS 639-3
SIL(Ed.15)
ISO 639-2/T(/B)
alpha-3
ISO 639-1
alpha-2
RFC 3066
(alternatief)
SIL(Ed.14) Nederlandse naam (nl) Engelse naam (en) Lokale naam Taalgebied
(ISO 3166)
afr afr af af (x-sil-AFK) AFK Afrikaans Afrikaans Afrikaans of Taal BW, MW, NA, ZA, ZM
deu deu (ger) de de (x-sil-GER) GER Duits German Deutsch AT, CH, CZ, DE, DK, HU, IT, KZ, LI, LU, PL, PY, RO, SK
nld nld (dut) nl nl (x-sil-DUT) DUT Nederlands Dutch Nederlands AW, BE, BQ, CW, FR, NL, SR, SX
vls - - - (nl-BE, x-sil-VLS) VLS Vlaams Flemish Vlaemsch BE, FR, NL

Complete overzichten en tabellen zijn online te vinden via de externe links hieronder.

Zie de categorie ISO 639 van Wikimedia Commons voor mediabestanden over dit onderwerp.