Overeenstemming voor gebruik van ISO 639 subset voor attributen die de taal opslaan

[joeribekker]

In sommige API's is het relevant om de taal van een document of de taal van ingestuurde gegevens vast te leggen. Voor het vastleggen van talen zijn verschillende ISO 639 subsets.

Graag zou ik zie dat er een keuze wordt gemaakt in welke ISO subset wordt gehanteerd zodat dit niet per API gaat verschillen. Bij de ZGW API's van VNG is ooit gekozen voor ISO 639-2/B (Nederlands=dut) maar wellicht is ISO-639-3 tegenwoordig beter (Nederlands=nld).

[sanderke]

Gezien beide subsets reeds zijn ingetrokken en de ISO-documenten achter een paywall zitten, is het wellicht een idee om naar RFC 5646 te verwijzen en de daaruit gerolde IANA Language Subtag Registry (Nederlands=nl).

[joeribekker]

Ah, open standaarden hebben uiteraard de voorkeur! De IANA lijst was (destijds in ieder geval) nog niet echt uitgebreid maar des te meer reden om een keuze te maken :)

[TimvdLippe]

Ik kwam BCP47 vandaag tegen in een andere API in ontwikkeling. BCP47 verwijst ook naar RFC5646. We kunnen naar deze standaarden wel refereren en dan ook een verwijzing naar de language registry, omdat beide openbaar zijn.

Ik zal hier een wijziging voor opstellen en dan kunnen we die bij het komende TO bespreken.

[TimvdLippe]

Ik heb een eerste poging gedaan om hier een regel voor te schrijven: https://logius-standaarden.github.io/Publicatie-Preview/API-Design-Rules/language-codes/#/core/lang-code

[dvh]

RFC5646 lijkt mij idd de juiste, ook de Accept-Language en Content-Language headers verwijzen hiernaar. Daarover gesproken, zoals ik deze regel nu lees gaat het om extra informatie bij een attribuut die expliciet de taal van de value aangeeft, en niet om de hele response. Misschien moeten we dat nog verduidelijken? Stel: ik heb een API voor een meertalige website, dan wil ik gewoon met Accept-Language werken ipv allemaal arrays terug te geven.

[TimvdLippe]

De eerste opzet is besproken op het TO vorige week. We zullen binnenkort een werksessie houden om dit verder uit te werken.

[joeribekker]

Volgens mij zijn er 2 regels die ik uit het overleg heb gehaald:

1. Om in response-bodies talen aan te geven, hanteer RFC 5646
2. Header t.b.v. content negotiation. Hanteer BCP 47, je mag de set aan door de API geaccepteerde talen limiteren in de API specificatie. In dat geval, indien een niet geaccepteerde taal wordt gevraagd geeft de API een HTTP 406 terug.

en, er wordt niet perse iets gezegd over de bericht structuur (array, dict discussie)