Friedel en ander frappanthede

Ons het onlangs 'n interessante gesprek in die kantoor gehad oor taal- en dialekkodes. As ons vertalings stoor in vertaalgeheue, hoe moet ons maak met 'en' (Engels) tenoor 'en-US' (Engels in die VSA)? Moet ons aanneem dat dit dieselfde is, of dit as twee heeltemal verskillende tale hanteer? Die probleem is nie heeltemal so eenvoudig as wat mens dalk sou hoop nie.

Baie vertalers in die wêreld van Vry Sagteware sal bekend wees met kodes soos 'af' (Afrikaans), 'pt_BR' (Portugees in Brasilië), en dalk selfs iets soos "sr@Latn" (Serwies geskryf met Latynse skrif). Laasgenoemde is 'n formaat wat in glibc (dus in die Linux-wêreld) te sien is en word gebruik in gevalle waar 'n enkele taal met meer as een alfabet of skrifstelsel geskryf word. Daar is standaarde vir hierdie taalkodes:

• Opsomming by die W3C
  
• RFC 4646
  
• BCP 47
  

Hierdie standaarde laat ruimte vir net omtrent enigiets, insluitend private uitbreidings. Meeste toepassings sal seker nooit 'n volledige taalkode met sewe dele sien nie. Dit word ook sterk afgemoedig. Ons gesprek het spesifiek gegaan oor hoe om taalspesifeseerders te stoor, en hoe om dit later tydens leesoperasies te gebruik te midde van passings wat verwag word tussen eenvoudige en uitgebreide taalkodes. Ons het spesifiek 'n stoor vir vertaalgeheue gedagte gehad. 'n Gebruiker wat TM soek vir Afrikaans ('af') soek sekerlik ook resultate wat gestoor is onder 'af-ZA' (Afrikaans in Suid-Afrika).

RFC 4647 verduidelik hoe verskillende passings behoort te werk binne sekere soekoperasies. Dit dek 'n klomp gevalle, en maak goeie sin. Ek raai ons gaan nie 'n taalkode soos '*' of 'fr-*' ooit in ons toepassings teëkom nie. Hierdie stukkie kompleksiteit kan ons dus dalk vryspring.

Maar hoe gemaak in die geval waar data nie 100% korrek gestoor is nie? Ons het juis die geval van Arabies bespreek. 'n Vertaler in Marokko se sagteware sal dalk outomaties 'ar-MA' voorstel as die werkstaal, en die vertaler sal dit sommermeer aanvaar en sy vertalings sal só in sy lêers gestoor word. In werklikheid is daar nie veronderstel om enige verskil te wees tussen die Arabies van die verskillende lande nie, dus is hierdie nie werklik akkuraat vir optimale hergebruik nie. Iemand wat vir 'ar' (generiese Arabies) aanvra, kan volgens RFC 4647 dan wel hierdie resultate kry. Maar 'n Arabiese vertaler in Egipte se sagteware kan outomaties 'ar-EG' (Arabies in Egipte) voorstel as die werkstaal. 'n Navraag vir voorstelle in 'ar-EG' sal nie resultate lewer wat gestoor is onder 'ar-MA' nie, al is dit in werklikheid wat 'n Arabiese vertaler in omtrent alle gevalle sal wil hê.

Vereenvoudiging lyk aanloklik, maar sal bv. nie werk in die geval van Sjinees nie - 'zh-CN' (Sjinees van Sjina) vereenvoudigd na 'zh' (generiese Sjinees) beteken niks - daar is nie werklik lokalisering wat vir 'zh' gedoen word nie - eintlik net 'zh-CN'/'zh-TW' of 'zh-Hans'/'zh-Hant' (waar die onderskeid op skrif eerder as land getref word). Iemand wat voorstelle uit alle tipes Sjinees wil hê sal dit moet spesifiseer net soos wat 'n Afrikaanse vertaler dalk 'n belangstelling in Nederlands sal aandui.

Die uitdaging gaan dus wees om op 'n toepassingsvlak dit so maklik as moontlik te maak vir die gebruiker om die regte keuse te maak, sonder om dinge outomaties te vereenvoudig. Die moontlikheid van taalspesifieke reëls lyk aantreklik, maar dit sou tog lekker wees as dit nie nodig is nie. Ek raai ons sal dinge met detail stoor, maar in die gebruikerkoppelvlak probeer om te vereenvoudig wanneer die navraagtaal bepaal word.