Chatbotin kielen automaattinen tunnistus: mieltymykset, vara-ratkaisut ja käyttäjän valinta

Monikielisen verkkosivuston chatbotin ei pitäisi ohjata kävijöitä väärälle kielelle heti ensimmäisessä vastauksessa. Kuitenkin chatbotin kielen automaattinen tunnistus tarkoittaa muutakin kuin selaimen ensimmäisen arvon ottamista käyttöön. Selaimen asetukset voivat olla vanhentuneita, laite saattaa olla yhteiskäytössä ja käyttäjä voi mieluummin lukea teknistä sisältöä englanniksi, vaikka hänen käyttöjärjestelmänsä kieli olisi saksa.

Vankka ratkaisu pitääkin automaattista tunnistusta vain aloitusmerkkinä. Käyttäjän nimenomainen valinta on aina etusijalla, käyttöliittymän, tietopohjan ja ihmiagentille siirron saatavuus asettavat rajat, ja näkyvä vara-ratkaisu (fallback) estää sen, että näennäisesti sopiva kieli johtaisi puutteellisiin tai keksittyihin vastauksiin.

Miksi selaimen kieli on vain vihje

Selaimet lähettävät usein HTTP-otsakkeen Accept-Language. Se sisältää kielialueita ja voi ilmaista järjestyksen niin kutsuttujen laatuarvojen (quality values) avulla, kuten de-AT,de;q=0.9,en;q=0.7. Standardi RFC 9110 kuvaa näitä mieltymyksiä nimenomaan apuna esitystavan valinnassa, ei varmana tietona henkilöstä.

Selaimessa navigator.languages tarjoaa järjestetyn luettelon ensisijaisista BCP-47-kielitunnisteista. Standardin mukaan MDN selaimet voivat tietosuojasyistä kuitenkin paljastaa vähemmän mieltymyksiä. Lisäksi selain saattaa täydentää yleisempiä muunnelmia: tunnisteesta de-AT voi vertailua varten tulla lisäksi merkityksellinen de .

Seuraus chatboteille on käytännöllinen: Accept-Language ja navigator.languages ovat hyviä ehdokkaita ensimmäiseksi ehdotukseksi. Ne eivät kuitenkaan saa korvata sijaintia tai kansallisuutta. IP-osoite ei paljasta luotettavaa kielitoivettta. Pelkkä verkkotunnus tai sivun kieli ei sekään riitä, jos kävijä on tietoisesti vaihtanut toiseen kieliversioon.

Selkeä prioriteettiketju estää yllätykset

Valinnan tulee olla deterministinen. Hyväksi havaitussa järjestyksessä jokaiselle lähteelle annetaan selkeä painoarvo:

1. Nimenomainen valinta nykyisessä istunnossa: Jos käyttäjä klikkaa ranskaa, chatbotin seuraavan vastauksen täytyy olla ranskaksi.
2. Tallennettu, edelleen voimassa oleva mieltymys: Aiempi valinta voi olla voimassa myöhemmällä käynnillä, jos tallennus on läpinäkyvää ja teknisesti sallittua.
3. Nykyisen sivun kieli: Chatbotin ei pitäisi ilman syytä poiketa käyttäjän tietoisesti avaamasta kieliversiosta.
4. Selaimen mieltymykset: Luetteloa verrataan chatbotin tosiasiallisesti tukemiin BCP-47-aluekoodeihin (locale).
5. Dokumentoitu oletuskieli: Jos mikään ei sovi, käytetään tietoisesti valittua peruskieltä sattumanvaraisen tuloksen sijaan.

Tämä ketju erottaa tunnistuksen päätöksenteosta. Se on lokitoitavissa ja testattavissa: source=user, source=stored, source=page, source=browser tai source=default. Analytiikalle riittää yleensä lähde ja valittu kielikoodi. Selaimen koko kieliluetteloa ei pitäisi tallentaa tarpeettomasti, sillä RFC 9110 huomauttaa yksityiskohtaisten kielimieltymysten mahdollisista tietosuoja- ja laitetunnistusriskeistä (fingerprinting).

Normalisoi BCP-47-tunnisteet menettämättä merkitystä

Kielitunnisteet eivät koostu vain kahdesta kirjaimesta. pt-BR ja pt-PT jakaavat saman kielen, mutta voivat erota toisistaan äänensävyn, sanavalintojen, muotoilujen ja oikeudellisten termien osalta. Myös kirjoitusjärjestelmät voivat olla ratkaisevia. Siksi sovelluksen tulisi syntaktisesti normalisoida saapuvat tunnisteet ja sen jälkeen tarkistaa ne tuettujen aluekoodien luetteloa vasten.

Tarkasta tunnisteesta turvalliseen vara-ratkaisuun

Järkevä täsmäytys yrittää ensin tarkkaa muunnelmaa. Jos de-AT ei ole saatavilla, sitä voi seurata de . Sen jälkeen voidaan käyttää tunnettua, toimituksellisesti tarkistettua oletusaluekoodia. Pelkkä kaikkien alitunnisteiden (subtag) katkaiseminen ei kuitenkaan aina ole turvallista. Kielissä, joissa on useita kirjoitusjärjestelmiä tai hyvin erilaisia muunnelmia, tuote tarvitsee tietoisesti määritellyn kohdistuksen.

Vara-ratkaisu on tarkistettava erikseen kolmella tasolla: Onko chat-käyttöliittymä käännetty? Onko saatavilla sopivia tietolähteitä? Voiko ihmiagentti ottaa tämän kielen haltuunsa? Lokalisoitu painike ei vielä ole todiste siitä, että tietopohjalla on sama kattavuus. Miten lähteet erotellaan kielen, version ja käyttöoikeuksien mukaan, käsitellään artikkelissa RAG-metatietosuodattimet tekoäly-chatboteille.

Tarjoa automaatiota, pidä käyttäjän valinta näkyvissä

W3C:n kansainvälistämissuositus yhdistää automaattisen kielen välityksen helposti löydettäviin linkkeihin vaihtoehtoisiin kieliversioihin. Jos käyttäjä itse vaihtaa kieltä, tämän valinnan tulee ohittaa selaimen mieltymys ja säilyä haluttaessa seuraavilla sivuilla.

Chatbotille tämä tarkoittaa: aktiivinen kieli kuuluu näkyvästi chat-otsikkoon tai helposti saavutettavaan valikkoon. Vaihto ei saa lähettää keskeneräistä luonnosta huomaamatta. Sen sijaan syöte säilyy, botti selittää kielenvaihdon lyhyesti ja jatkaa keskustelua hallitusti. Jos aiemmat viestit ovat toisella kielellä, järjestelmän tulee säilyttää niiden merkitys kontekstille, mutta olla kääntämättä koko historiaa kysymättä.

Hyvä muotoilu on esimerkiksi: ”Suomi otettiin käyttöön tältä sivulta. Vaihda kieltä.” Vara-ratkaisun kohdalla ilmoitus voi olla tarkempi: ”Suomeksi ei ole saatavilla tarkistettuja tietoja tästä aiheesta. Voin käyttää englanninkielistä lähdettä tai siirtää asian tukeen.” Näin käyttäjä ymmärtää, miksi kieli tai vastaussyvyys vaihtuu.

Erota sivun kieli, chat-kieli ja sisällön aluekoodi

Kolme arvoa yhdistetään usein virheellisesti yhdeksi kentäksi:

• Sivun kieli: HTML-dokumentin ensisijainen kieli;
• Chat-kieli: kieli, jolla käyttöliittymä ja vastaukset esitetään;
• Sisällön aluekoodi: muunnelma, josta chatbot saa hakea vahvistettua tietoa.

Nämä arvot voivat olla samat, mutta niiden ei tarvitse olla. Suomenkielinen käyttäjä voi esittää suomenkielisen kysymyksen englanninkielisellä tuotesivulla. Botti saa vastata suomeksi ja silti läpinäkyvästi viitata englanninkieliseen alkuperäislähteeseen. Sen ei kuitenkaan pitäisi väittää käyttäneensä suomenkielistä lähdettä, jos vain vastaus käännettiin.

Saavutettavuuden vuoksi dokumentin ja sisällön kieli on merkittävä oikein. W3C-tekniikka H57 kuvaa lang-attribuutin käytön html-elementissä, jotta muun muassa ruudunlukijat voivat käsitellä ääntämyksen ja syntaksin asianmukaisesti. Jos yksittäisen osion kieli vaihtuu, myös tämä alue tarvitsee sopivan merkinnän. Lisätarkistuksia tarjoaa WCAG-tarkistuslista verkkosivustojen chatboteille.

Välimuistin ja URL-osoitteiden on kunnioitettava kielipäätöstä

Jos sisältö valitaan palvelimen puolella Accept-Language -otsakkeen mukaan, välimuististrategia on otettava huomioon. RFC 9110 selittää, että Vary: Accept-Language ilmoittaa välimuisteille otsakkeen vaikuttaneen esitystapaan. Jos tämä erottelu puuttuu, välimuisti voi toimittaa suomenkielisen muunnelman englanninkieliselle kävijälle.

Julkisen, indeksoitavan sisällön kohdalla pysyvät kielikohtaiset URL-osoitteet ovat usein helpommin tarkistettavissa ja jaettavissa. Automaattinen tunnistus voi tällöin ohjata sopivaan URL-osoitteeseen piilottamatta eri sisältöjä saman osoitteen alle. Chatin sisällä aluekoodin tulee olla osa istuntotilaa ja jokaista palvelinpyyntöä. Kielenvaihdon on päivitettävä samanaikaisesti välimuistiavaimet, tiedonhakusuodattimet ja vastauksen sukupolvi.

Myös muotoillut arvot kuuluvat tähän sopimukseen. Päivämäärä, luku, valuutta ja aikavyöhyke eivät seuraa automaattisesti oikein tekstin kielestä. Opas Chatbot-vastausten lokalisointi näyttää, kuinka näitä tietoja käsitellään erillisesti ja johdonmukaisesti.

Vara-ratkaisut eivät saa peittää sisältöaukkoja

Riskialttein virhe on tietopohjan hiljainen vaihtaminen. Jos suomenkieliseen kysymykseen ei ole suomenkielistä artikkelia, botti voi käyttää englanninkielistä lähdettä, mikäli tuote sallii tämän reitin. Sen on kuitenkin tarkistettava lähde, ajantasaisuus ja käyttöoikeudet samalla tavalla kuin suorassa osumassa.

Turvallinen vara-ratkaisumatriisi sisältää vähintään: pyydetty aluekoodi, saatavilla oleva käyttöliittymän aluekoodi, saatavilla oleva sisällön aluekoodi, sallittu korvaava aluekoodi, käännöstila ja siirtokohde. Tulos ei aina ole vastaus. Arat tai vahvasti kontekstisidonnaiset aihepiirit vaativat, että ”ei vahvistettua tietoa tällä kielellä” on parempi kuin sujuva, mutta ilman lähdeviitettä oleva käännös. Artikkelissa Vara-ratkaisut tietopuutteissa kuvaillaan, miten epävarmuus ja ihmiagentille siirto toimivat yhdessä.

Kielilogiikan testitapaukset

Pieni, järjestelmällinen testijoukko löytää enemmän virheitä kuin yksittäinen selaintarkistus. Sen tulisi kattaa vähintään seuraavat tapaukset:

• de-AT tarjotaan, mutta vain de;
• on tuettu; selaimen ensimmäinen kieli ei ole saatavilla, mutta toinen on;
• käyttäjän valinta on ristiriidassa sivun ja selaimen kielen kanssa;
• tallennettu mieltymys viittaa sittemmin poistettuun aluekoodiin;
• käyttöliittymä on olemassa, mutta tietopohja tai ihmiagentille siirto ei;
• kielenvaihto tapahtuu kesken keskustelun, kun tekstiä on lähettämättä;
• välimuisti toimittaa vaihdon jälkeen todella uuden aluekoodin;
• ruudunlukija tunnistaa sivun ja osion kielen oikein;
• analytiikka kerää valintalähteen ja vara-ratkaisun, mutta ei tarpeettoman yksityiskohtaista mieltymysluetteloa.

Jokaista yhdistelmää varten tiimien tulee kirjataan odotettu aluekoodi, päätöksen lähde, näkyvä ilmoitus ja sallittu sisältöalue. Lisäksi jokainen kieli vaatii ammatillisia pistokokeita. Kattavuutta ja vastauksen laatua ei voida päätellä pelkästään käännösrivin olemassaolosta.

Käytännön käyttöönottotarkistuslista

1. Inventoiti kaikki tuetut käyttöliittymä-, sisältö- ja siirtoaluekoodit erikseen.
2. Dokumentoi yksiselitteinen prioriteettiketju käyttäjän valinnalle, tallennetulle valinnalle, sivulle, selaimelle ja oletukselle.
3. Määritä BCP-47-täsmäytys sekä alueelliset ja kirjoitusjärjestelmään liittyvät poikkeukset.
4. Suunnittele kielenvaihto näkyväksi ja ilman syötteen menetystä.
5. Rajoita vara-ratkaisut lähteiden kattavuuteen, ajantasaisuuteen ja käyttöoikeuksiin.
6. langTarkista kielikohtaiset URL-osoitteet, kanoniset osoitteet ja välimuistin toiminta.
7. Tallenna vain tarvittavat analytiikkatiedot ja määritä säilytysaika.
8. Testaa työpöytä-, mobiili-, näppäimistö- ja ruudunlukijakäyttö realistisilla mieltymysluetteloilla.

Keskeinen tuotepäätös ei siten kuulu: ”Mikä kieli tällä kävijällä on?” Se kuuluu: ”Mitä kieltä toivottiin, mitä sisältöjä siitä on luotettavasti saatavilla ja miten selitämme tarvittavan korvaavan reitin?” Se, joka vastaa näihin kolmeen kysymykseen erikseen, saa chatbotin, joka aloittaa automaattisesti hyödyllisesti, mutta jättää hallinnan käyttäjälle.

Lähteet

• RFC 9110: Accept-Language, Vary ja tietosuoja
• MDN: Navigator.languages
• W3C Internationalization: Guiding users to translated pages
• W3C WAI: Dokumentin kielen merkitseminen lang-attribuutilla