Kielimerkkaus: tekstin kielen ilmoittaminen merkkausjärjestelmissä

Tämä dokumentti käsittelee osittain kielikoodeja (kielten tunnuksia) yleisesti mutta erityisesti kielen merkkaamista (language markup) merkkausjärjestelmissä kuten HTML ja XML. Osittain mennään melko syvällekin yksityiskohtiin. Lyhyt käytännöllinen yleisohje aiheesta HTML:n osalta on Tieken Esteettömyysoppaan kohdassa ”Kielen merkkaaminen: lang”.

Kielimerkkauksen tarkoitus

Sisältö:

Mitä kielimerkkaus on

Kielimerkkauksella tarkoitetaan merkkauksessa, englanniksi markup, esitettyä tietoa tekstinosan kielestä. Esimerkiksi HTML-merkkauksessa tägi <p lang="sv"> ilmoittaa, että alkaa kappale, jonka teksti on ruotsia.

ATK-sanakirja määrittelee sanan "merkkaus" seuraavasti:

Dokumentin osien erottelu ja niiden ominaisuuksien osoittaminen käyttäen sovittuja merkintöjä, esimerkiksi muotoilua ohjaavia komentoja.

Olennaista on, että merkkauksessa siis käytetään sovittuja merkintöjä. Käytännössä sopimukset on suunniteltu sellaisiksi, että merkkaus on tietokoneohjelmilla helposti käsiteltävissä niin, että sillä on yksiselitteinen merkitys. Merkkaus erotetaan normaalitekstistä sopivien erikoismerkkien avulla tai muilla keinoin niin, että tekstiä lukeva ohjelma voi käsitellä merkkauksen erikseen. Kun ohjelma esittää merkkausta sisältävän dokumentin esimerkiksi kuvaruudulla tai paperilla, itse merkkaus ei yleensä näy, vaikka se voikin vaikuttaa siihen, millainen varsinaisen tekstin esitysmuoto on.

Kielimerkkaus on luonteeltaan loogista merkkausta, ominaisuuksien osoittamista, ei muotoilua ohjaava komento, joskin sillä saattaa olla vaikutusta myös muotoiluun. Merkkauksen ja ns. merkkauskielten ideaa sekä erityisen loogisen ja muotoilevan merkkauksen eroa selostaa laajahkosti dokumentti Merkkauskielten idea.

Kielimerkkauksen perustelut HTML 4:n määrittelyssä

HTML 4:n määrittelyn kohta Language information and text direction mainitsee seuraavat syyt käyttää kielimerkkausta (selitykset minun):

Kielimerkkauksen perustelut WAI-esteettömyyssuosituksissa

Esteettömyyden eli saavutettavuuden (englanniksi accessibility) yleisestä merkityksestä kertoo Esteettömyysesite. WAI-suosituksilla tarkoitetaan WWW-konsortion eli W3C:n esittämiä esteettömyyssuosituksia, erityisesti sivujen tekemistä koskevaa WCAG 1.0 -suositusta, josta esimerkiksi Euroopan parlamentin päätöslauselma toteaa, että sitä pidetään maailmanlaajuisena standardina.

WCAG 1.0:ssä ja siihen liittyvissä teknisissä ohjeissa kielimerkkausta käsittelevät seuraavat kohdat:

Näistä ensin mainittu viittaa (edellä jo kuvattujen syiden lisäksi) Braille-kirjoituksen tuottamiseen. Eri kielille käytetään erilaisia Braille-muunnelmia. Aiheesta kertoo laajemmin dokumentti Braille symbols in Swedish braille.

Teknisempi ohjeisto sisältää itse asiassa tarkemmat, havainnollisemmat perustelut kuin itse suositus. Seuraavassa on perustelujen suomennos, jossa on hakasulkeissa selventäviä lisäyksiä:

Kielen vaihtumisen ilmoittaminen on tärkeää useista syistä:

  1. Käyttäjät, jotka lukevat dokumenttia Braille-esityksenä, voivat käyttää sopivia ohjauskoodeja (merkkausta) siellä, missä kieli vaihtuu, taatakseen, että tekstiä Brailleksi muuntava ohjelma tuottaa oikeita merkkejä (esimerkiksi kirjaimia, joissa on tarkkeita). Nämä ohjauskoodit lisäksi estävät ohjelmaa tuottamasta Braille-lyhenteitä (contractions), jotka voisivat hämmentää käyttäjää. Braille-lyhenteet yhdistävät usein esiintyviä merkkiyhdistelmiä, jotka muuten vaatisivat useita Braille-soluja, yhdeksi soluksi. Esimerkiksi "ing", joka normaalisti vaatii kolme solua, yhden kullekin merkille, voidaan lyhentää yhdeksi soluksi [mutta tämä englannin kielessä hyödyllinen menettely voi hämätä muunkielisten tekstien esittämisessä].
  2. Samaan tapaan puhesyntetisaattorit, jotka "puhuvat" monia kieliä, voivat tuottaa tekstin käyttäen sopivaa aksenttia ja oikeaa ääntämystä. Jos kielen vaihtumisia ei ole merkattu, syntetisaattori tekee parhaansa lausuakseen sanat sillä kielellä, jota se ensisijaisesti käyttää. Täten syntetisaattori, joka käyttää englantia peruskielenä, voisi lausua ranskan autoa tarkoittavan sanan "voiture", englannin sanan "voter" [ja tämä hämäisi, jos sana esiintyy englanninkielisen tekstin joukossa].
  3. Käyttäjät, jotka eivät itse osaa kääntää kielestä toiseen, voivat käyttää automaattisia käännösohjelmia heille outojen kielen kääntämiseen.

Viimeksi mainittua kohtaa voisi selventää ja täydentää seuraavasti: Kielenkääntämisessä, tapahtuipa se automaattisesti tai ihmisen tekemänä, on tietysti olennaista tietää, mitä kieltä käännettävä teksti on. Ihminen toki näkee tekstistä, mitä kieltä se on, jos hän ylipäänsä pystyisi kääntämään sitä. Käännösohjelmien tilanne on toinen. Lisäksi kielen vaihtuminen kesken tekstin voi aiheuttaa vaikeuksia ihmisellekin, varsinkin, jos kääntäjä ei tunne sitaatin tai vieraskielisen termin kieltä; tietokoneohjelma menee sekaisin vielä paljon helpommin. Jos esimerkiksi suomeksi käännettävässä englanninkielisessä tekstissä on ranskankielinen sitaatti, riippuu tilanteesta, olisiko se käännettävä vai säilytettävä alkukielisenä. Joka tapauksessa kielimerkkaus voi auttaa välttämään pahimman vaihtoehdon automaattisessa kielenkääntämisessä: ohjelma kääntää ranskaa kuten se olisi englantia, ja tulos on luultavasti aivan sotkua. Kielimerkkauksen ja muun merkkauksen merkitystä kielenkääntämiselle eräiltä kannoilta käsittelee tarkemmin dokumentti Translation-friendly authoring.

Voi tuntua oudolta, että WAI-suosituksissa koko dokumentin kielen merkkaaminen on alemmalla prioriteetilla (3) kuin kielen vaihtumisen merkkaaminen (joka on prioriteettitasolla 1). Onhan koko dokumentin kielen merkkaaminen hoidettavissa yhdellä ainoalla määritteellä, kun taas kaikkien vaihtumisten merkkaaminen voi olla hyvin työlästä ja vaatia pohdintaa ja hankalia ratkaisuja. Taustalla lienee se seikka, että esimerkiksi puhesyntetisaattoria voi käyttäjä yleensä helposti käskeä lukemaan teksti halutun kielen sääntöjen mukaan, jos se ylipäänsä sitä kieltä tukee. Sen sijaan olisi lähinnä mahdotonta se, että käyttäjä kesken lukemisen ohjailisi syntetisaattoria vaihtamaan kieltä.

Muita perusteluja

Word tunnistaa HTML-sivun kielimerkkauksen

Jos Word-ohjelmalla avataan HTML-sivu oikolukua varten, niin tarpeeksi uudet Wordin versiot osaavat ottaa huomioon HTML-merkkauksen lang-määritteet. Jos näitä määritteitä on käytetty järjestelmällisesti, niin Word osaa soveltaa tekstin eri osiin kunkin kielen sanastoja ja oikolukusääntöjä. Tämä toki edellyttää, että Wordiin on asennettu käytettyjen kielten tuki.

Word sopii hyvin oikolukuun silloin, kun tekstissä on vain vähän virheitä. Havaitut virheet voi tällöin korjata muulla ohjelmalla HTML-dokumenttiin. Yleensä ei kannata muokata HTML-sivua Word-ohjelmalla, koska se tekee haitallisia muutoksia merkkaukseen.

Pelkkä tieto kielestä voi auttaa

Selain tai muu ohjelma voisi ilmaista, mitä kieltä teksti on. Tällainen tieto voi olla hyödyksi esimerkiksi auttaessaan käyttäjää näkemään, että mitä kieltä jokin lause on. Tieto auttaisi häntä etsimään sanojen ja lauseiden merkityksiä ja käännösapua oikeilta tahoilta. Esimerkiksi Mozilla 1.0:n käyttäjä voi viedä kursorin sanan päälle ja hiiren oikeaa nappia käyttämällä ja vaihtoehdon "Properties" valitsemalla saada esiin pienen tietoikkunan, josta ilmenee ainakin kieli, jos se on dokumentissa ilmaistu kielimerkkauksella.

Erikielisten osien näyttäminen erilaisina

Käyttäjä voi jo nyt ohjata CSS:ää tarpeeksi hyvin tukevan selaimen (esimerkiksi Opera 6:n) näyttämään erikielisiä tekstejä eri tavoin, jos sivulla on käytetty kielimerkkausta. Esimerkiksi CSS-sääntö
*[lang="en"] { font-family: fantasy; }
käyttäjän tyylisäännöstössä aiheuttaisi englanninkielisten osien esittämisen eri fontilla. Tämä oli tietysti vain esimerkki; käytännössä kannattaisi valita jokin muu fontti, mutta yksityiskohdat riippuvat siitä, millainen käyttäjän tyylisäännöstö on kokonaisuudessaan.

Tällainen asetus muuten on sivuntekijälle usein hyödyllinen, koska se auttaa tarkistamaan, että sivulla on käytetty kielimerkkausta oikein.

Periaatteessa voitaisiin CSS:ssä käyttää myös pseudoluokkaa :lang, mutta tuki sille on vielä suppeampi kuin esimerkissä käytetylle tavalle, joka perustuu ns. määriteselektoreihin.

Selaimen aputoimintojen auttaminen

Ohjelman käyttöliittymä voi sisältää piirteitä, joiden toteutuksessa olisi eduksi, jos ohjelma tietäisi tekstin eri osien kielen. Esimerkiksi Opera-selaimessa käyttäjä voi maalata sanan hiirellä ja sitten hiiren oikealla napilla valita jonkin haku- ja käännöstoiminnon. Tämä on vielä suhteellisen alkeellisesti toteutettu, mutta ideana erinomainen. Ja se toimisi paremmin, jos selain "tietäisi", mitä kieltä sana on, ja suoraan kääntäisi sen käyttäjän kielelle, jonka hän on ilmoittanut selaimen asetuksissa. Nykyisin käyttäjä joutuu aina erikseen valitsemaan lähtökielen (ja kohdekielen), jolloin toimintaa ei voi toteuttaa sujuvasti pelkällä napsauksella.

Kielen kertominen tekstissä voi silti olla tarpeen

On tilanteita, joissa olisi aiheellista itse tekstissä kertoa, että seuraa muunkielistä tekstiä. Kielimerkkaukseen ei ylipäänsäkään kannata paljoa luottaa; se on toistaiseksi parhaimmillaankin vain lisäinformaatiota, josta voi olla hyötyä.

Jos tekstissä on esimerkiksi pitkähkö ranskankielinen lainaus, on yleensä syytä kielimerkkauksen lisäksi mainita sopivalla tavalla ennen lainausta, mitä on tulossa. Maininta voidaan yleensä liittää johdantolauseeseen, joka ylipäänsä kertoo, että on tulossa lainaus, siis tyyliin "Ranskankielisessä alkuteoksessa tämä kohta on seuraava:". Tästä voi olla käyttäjälle apua osittain edellä kuvatuista syistä, ja tällöin tieto on kaikkien saatavilla eikä vain niiden, jotka käyttävät sopivaa selainta sopivalla tavalla.

Eikö kielen päätteleminen riitä?

Mutta vaikka tarvitaan tieto tekstin kielestä, tarvitaanko merkkausta? Eikö riitä, että käyttäjä voi valikosta valita kielen ja ohjelma sitten toimii sen mukaan? Tai eikö ohjelma voi päätellä kieltä?

Eräät Internetin hakukoneet, kuten Google ja AltaVista, ilmeisestikin päättelevät dokumentin kielen sen sisällöstä. Päättely ei ole virheetöntä mutta yleensä osuu oikeaan. Itse asiassa melko pitkästä tekstistä voi aika alkeellisin menetelmin, vaikkapa vain tarkastellen tavallisimpia pikkusanoja, arvata kielen useimmiten oikein.

Mutta jos kieli vaihtuu kesken esityksen, mainitunlaiset menetelmät toimivat yleensä huonosti, sitä huonommin, mitä lyhyempi katkelma on kyseessä. Esimerkiksi puhesyntetisaattori voi toimia paljon paremmin, jos dokumentin pääkielestä poikkeavat tekstijaksot kuten vieraskieliset nimet ja lainaukset on merkattu niin, että niistä ilmenee kieli. Erityinen ongelma on automaattisessa kielentarkistuksessa. Monille on tuttua, miten esimerkiksi MS Word näyttää vieraat sanat virheinä. Jos ohjelma tukisi kielimerkkausta ja dokumentin kirjoittaja käyttäisi sitä hyväkseen, voisi ohjelma tarkistaa esimerkiksi suomenkielisessä tekstissä olevien englanninkielisten lainausten asun asianmukaisesti.

Koko dokumentin kielen merkkaaminen taas on hyvin helppoa, jos vain merkkausjärjestelmässä on menettely sitä varten. Esimerkiksi suomenkieliseen HTML-dokumenttiin riittää kirjoittaa tägin <html> asemesta <html lang="fi">. Tällöin tieto kielestä on helpolla tavalla kaikkien sellaisten ohjelmien käytettävissä, joilla dokumenttia käsitellään. Ei tarvita mitään arvaamista.

Lisäksi kielimerkkauksella voidaan ilmaista sellaisia eroja, joita olisi vaikea ohjelmien päättelemällä havaita. Jos esimerkiksi tehdään kielentarkistus englanninkieliselle tekstille, jossa osa sanoista on brittienglannin ja osa amerikanenglannin mukaisessa asussa, kuten usein on, mistä ohjelma voi tietää, kummat se ilmoittaa virheiksi ja tarjoutuu korjaamaan? Kielimerkkauksessa voidaan nämä englannin muodot erottaa toisistaan.

Kielimerkkauksen toteutus HTML:ssä ja XML:ssä (ja muissa järjestelmissä)

Sisältö:

HTML:ssä lang-määrite

HTML:ssä voidaan elementin sisällön kieli ilmaista lang-määritteellä, jonka arvo on jokin seuraavassa kohdassa kuvattava kielikoodi. Esimerkiksi
<html lang="fi">
ilmoittaa, että dokumentti kokonaisuutena on suomenkielinen.

Useimpiin HTML-elementteihin voidaan liittää lang-määrite. Poikkeukset ovat: applet, base, basefont, br, frame, frameset, iframe, param ja script. Osa poikkeuksista on outoja, sillä esimerkiksi iframe-elementissä kielen ilmoittaminen voisi olla tarpeen, esimerkiksi kun sillä liitetään dokumenttiin tekstitiedosto, joka on eri kieltä kuin ympäröivä teksti. Tämä ongelma voidaan periaatteessa kiertää panemalla iframe-elementti span-elementin sisään.

Kaikkien elementtien kieltä ei suinkaan tarvitse merkata erikseen, vaan vain niissä tapauksissa, joissa kieli poikkeaa ympäröivän tekstin eli ylemmän tason elementin kielestä. Jos suomenkielisessä dokumentissa on vaikkapa pitkä ruotsinkielinen lainaus, se on syytä merkata näin:
<blockquote lang="sv">...</blockquote>
Ja jos sen sisällä taas on tekstiä, joka ei ole ruotsia, sille on syytä olla oma lang-määritteensä.

Lainausten (sitaattien) lisäksi etenkin kirjojen ja muiden teosten nimet ovat tekstejä, joiden kieli on hyvä merkitä. Sopiva elementti teoksen nimelle on cite, joten merkkaus voi olla esimerkiksi seuraavanlaista:
Monet tuntevat nimeltä teoksen <cite lang="en">Origin of Species</cite>.

Jos jokin teksti on eri kieltä kuin ympäröivä teksti mutta ei ole omana elementtinään, sille voidaan ottaa käyttöön oma merkkaus, oma elementti, vain lang-määritteen liittämiseksi siihen. Jos kyse on yksittäisestä sanasta tai muutamista peräkkäisistä sanoista, käytetään span-elementtiä, esimerkiksi
Teoksen kirjoitti <span lang="en">Charles Darwin</span>.
Jos taas kyse on laajemmasta kokonaisuudesta, kuten peräkkäisistä kappaleista, kirjoitetaan sen ympärille div-merkkaus.

Esimerkiksi FrontPage 2003 -ohjelmassa voi tekstin sanoja merkata muunkielisiksi seuraavasti: Maalataan sanat hiirellä, ja valitaan Työkalut-valikosta kohta "Määritä kieli", jonka jälkeen voidaan valita pudotusvalikosta oikean kielen nimi. Valitettavasti tarjolla ei ole pelkkiä kieliä vaan esimerkiksi englannin kieltä valittaessa on valittava myös maa. Valinnan jälkeen ohjelma osaa käyttää kyseisen kielen oikolukua, jos se on ohjelmassa ylipäänsä käytettävissä.

Taulukoissa lang-määrite voi olla myös sarakekohtainen, esimerkiksi <col lang="en">. Tämä on hyödyllistä silloin, kun taulukko esimerkiksi sisältää sanaston, jossa erikieliset vastineet ovat eri sarakkeissa. Ei siis tarvitse kirjoittaa lang-määritettä kuhunkin soluun erikseen. Jos esimerkiksi taulukon ensimmäinen sarake on suomea, toinen saksaa, riittää kirjoittaa <table>-tägin jälkeen, ennen taulukon rivejä, vain
<col lang="fi">
<col lang="de">

Asia on selitetty HTML-spesifikaatiossa melko oudossa kohdassa, Inheritance of alignment specifications.

Huomautuksia kielimerkkauksesta HTML:ssä

Kielimerkkauksen käyttö on siis varsin yksinkertaista ja vaivatonta, kun kyse on koko dokumentista tai sen isohkoista osista. Kun mennään yhä pienempiin osiin, sanoihin ja jopa sananosiin, sitä hankalammaksi kielimerkkaus tulee. Näitä ongelmia käsitellään jäljempänä omissa luvuissaan. Tässä luetellaan vain muutamia yleisiä huomautuksia:

Englanniksi kielimerkkausta käsittelee HTML-määrittelyn luku Language information and text direction.

HTML:ssä on myös language-määrite, jota voi käyttää script-elementissä ilmoittamaan käytetty skriptikieli. Sillä ei siis ole mitään tekemistä luonnollisten kielten kanssa. Paradoksaalista on, että tähän tekniseen tarkoitukseen käytettävän määritteen nimeksi on otettu englannin sana sellaisenaan kun taas luonnollisen kielen (tai yleisemmin: ihmisten kielen) ilmoittamiseen käytetään typistesanaa!

XML:ssä xml:lang-määrite

XML:n määrittelyn kohta Language Identification esittää, että XML:ssä käytetään xml:lang-määritettä kielen ilmaisemiseen. Se vastaa hyvin pitkälle HTML:n lang-määritettä.

XHTML 1.0 -spesifikaation liite HTML Compatibility Guidelines suosittelee käytettäväksi molempia määritteitä. Toisaalta XHTML 1.1 -määrittelystä on, kuten sen kohdassa Changes from XHTML 1.0 Strict sanotaan, kokonaan poistettu lang-määrite.

Kielimerkkaus muissa järjestelmissä

XSL

XSL (eXtensible Stylesheet Language) sisältää language ominaisuuden, jonka tarkoitettua käyttöä kuvastaa seuraava: "Specifies the language to be used by the formatter in language-/locale-coupled services, such as line-justification strategy, line-breaking, and hyphenation.".

SVG ja SMIL

SVG (Scaleable Vector Graphics) ja SMIL (Synchronized Multimedia Integration Language) ovat dataformaatteja, joihin voi sisältyä tekstiä ja informaatiota tekstin kielestä. Kieli ilmoitetaan systemLanguage-määritteellä. Se on tarkoitettu mahdollistamaan kielivalinta samaan tapaan kuin HTTP:n kielivalintamekanismissa mutta yhden dokumentin sisällä.

RTF

RTF-tiedostomuoto on eräänlainen merkkauskieli, joka useilla tavoilla muistuttaa HTML:ää. Siinä on käytössä kolme kieleen liittyvää merkkausta:

\deflangnnnn
Asettaa oletuskielen, default language.
\deflangfennnn
Asettaa oletuskielen Word-ohjelman aasialaisia versioita varten.
{langnnnn tekstiä}
Asettaa kyseisen tekstinosan kielen.

Tässä nnnn on luku, joka ilmaisee kielen. RTF:ssä ovat käytössä erityiset numeeriset kielikoodit.

DocBook

DocBook on SGML-pohjainen järjestelmä dokumenttien kirjoittamiseen. Siinä on lang-määrite, mutta sen merkitys ja muotokin on hiukan epäselvä. DocBook: The Definitive Guide sanoo siitä, kohdassa Common Attribute Parameter Entities:

Lang should be a language code drawn from ISO 639 (perhaps extended with a country code drawn from ISO 3166, as en_US). Use it when you need to signal your application to change hyphenation and other display characteristics.

Kuten seuraavassa kohdassa selostetaan, Internetissä käytetyssä kielikoodien järjestelmässä peruskielikoodin ja maakoodin välinen erotin on yhdysmerkki (-), ei alaviiva (_). Toisaalta poikkeamista tästä ei ehkä koeta ongelmaksi, koska DocBook-muotoisia dokumentteja ei juuri ole tarkoitus sellaisenaan levittää esimerkiksi Internetissä, vaan niistä tuotetaan ohjelmilla erilaisia esitysmuotoja.

Kielikoodit (kielten tunnukset)

Tämä osa käsittelee koodeja (tunnuksia), joita voidaan käyttää asiakirjan tai sen osan kielen ilmoittamiseen. Tämä on suhteellisen riippumaton aineiston varsinaisesta teemasta, kielimerkkauksesta, ja koskee kielikoodien käyttöä hyvinkin monenlaisissa yhteyksissä.

Sisältö:

Kielikoodit: johdanto

Eri yhteyksissä on välttämätöntä tai ainakin hyödyllistä voida viitata eri kieliin yksikäsitteisillä koodeilla. Erityisen tarpeellista tämä on teknisissä yhteyksissä, joissa tietokoneohjelmat on saatava käsittelemään tekstiä eri tavoilla sen mukaan, mikä sen kieli on. Erityisesti kirjastoalalla on usein välttämätöntä tallentaa koodattu tieto julkaisun kielestä, jotta esimerkiksi voidaan etsiä määrätynkielisiä julkaisuja.

Seuraavassa on muutamien kielten kaksikirjaimisia koodeja (ISO 639:n mukaan):

Esimerkiksi viittomakielille ja muille saamen kielille kuin pohjoissaamelle on vain kolmikirjaimiset koodit. Tosin SFS-ISO 639:n mukaan koodin se merkitys olisi yleisesti 'saame', mutta ISO 639-2:n mukaan se = sme = Northern Sami = sami du Nord.

Tässä on käytetty ilmaisua "kielikoodi", joka on suora käännös englannin ilmaisusta "language code". Kuitenkin sanan "koodi" monimerkityksisyyden vuoksi voisi esimerkiksi "kielitunnus" olla parempi sana.

Sivu Kielten nimiä ja koodeja sisältää luettelon seuraavassa kuvattavan ISO 639 -standardin mukaisista kielikoodeista sekä kielten nimistä englanniksi, ranskaksi ja suomeksi.

Standardi ISO 639

Kansainvälinen standardi kielikoodeille on ISO 639, Codes for the representation of names of languages. Tarkemmin sanoen kyseessä on kaksi standardia, ISO 639-1, joka määrittelee kaksikirjaimiset koodit, englanniksi alpha-2 code (esimerkiksi sv = ruotsi), ja ISO 639-2, joka määrittelee kolmikirjaimiset koodit, englanniksi alpha-3 code (esimerkiksi swe = ruotsi). Jälkimmäisessä on joillekin kielille kaksi vaihtoehtoista koodia, bibliografinen ja terminologinen. Standardit ISO 639-1 ja ISO 639-2 eivät ole siinä mielessä yhteensopivia, että kolmikirjaimisen koodin kaksi ensimmäistä kirjainta olisivat aina samat kuin kyseisen kielen kaksikirjaiminen koodi. Toisaalta samassa yhteydessä voidaan käyttää molempia, koska koodin pituus ilmaisee, kumman standardin mukaan se pitää tulkita.

Alun perin (vuonna 1988) tehtiin vain ISO 639, joka määritteli kaksimerkkiset koodit; sitä oli edeltänyt vuonna 1967 tehty ISO/R 639, Symbols for languages, countries and authorities . Myöhemmin, vuonna 1998, tehtiin ISO 639-2. Vasta 2002-07-18 vahvistettiin vanhan ISO 639:n korvaava ISO 639-1, joskin se oli ollut luonnoksena (viime vaiheessa ns. DIS-tasoisena) olemassa jo huomattavasti aiemmin. Se ilmoittaa koodien lisäksi kielten nimet englanniksi, ranskaksi ja kielellä itsellään. Webissä on (PDF-muodossa) sen lopullinen luonnos ISO/FDIS 639-1.

ISO 639-1:n pohjalta on SFS laatinut vuonna 1993 Suomen kansallisen standardin, SFS-ISO 639, Kielten nimien tunnukset. Se mainitsee myös kolmikirjaimisia koodeja, mutta itse standardiin kuulumattomana. Siihen on otettu kaksikirjaimiset tunnukset muutamalle kielelle, joilla sellaisia tunnuksia ei kansainvälisessä standardissa ollut: kirjanorja (nb), uusnorja (nn) ja saame (se). Näistä kaksi ensin mainittua kuuluvat nykyisin myös ISO 639-1:een, ja se on siinä nimenomaan pohjoissaamen koodi. Mainittakoon, että kyseisessä standardissa on myös laaja kooste kielten nimistä suomeksi ja muilla kielillä.

Tilastokeskuksen kuvauksessa kielikoodeissa on lyhyesti kuvattu kielikoodijärjestelmiä. Siinä on myös suomenkielisiä nimiä eräille kielille, joita SFS-ISO 639 ei sisällä.

ISO 639:n kolmikirjainkoodien virallinen sivusto sisältää myös kaksikirjainkoodit: ISO 639-2 Registration Authority. Tavallisimmin tarvittava osa siitä lienee kooste kielikoodeista kielen englanninkielisen nimen mukaan järjestettyinä. Kyseisessä sivustossa on myös itse ISO 639-2 -standardi.

ISO 639-2 määrittelee kaksi koodia erikoistarkoituksiin mul, joka tarkoittaa monikielisyyttä, ja und, joka tarkoittaa epämääräistä kieltä. Niiden käyttö on aika ongelmallista. Aihetta käsitellään jäljempänä kohdassa Miten ilmaistaan, ettei kieltä voida ilmaista?

Kaksikirjaimisten koodien järjestelmä ei ole riittävä, koska vain varsin pienelle osalle maailman tuhansista kielistä on määritelty ISO 639-1-koodi eikä kahden kirjaimen mahdollisia yhdistelmiä edes ole tarpeeksi. Toisaalta kaksikirjaimiset koodit ovat toistaiseksi yleisemmin käytettyjä ja usein myös tietokoneohjelmien yleisemmin tunnistamia kuin kolmikirjaimiset. Lisäksi Internetin kielikoodikäytäntöjen tulee aina käyttää kaksikirjaimista koodia, jos kielellä sellainen on. (Tällöin ei myöskään synny kysymystä siitä, käytetäänkö bibliografista vai terminologista kolmikirjainkoodia, sillä niillä kielillä, joiden osalta ne poikkeavat toisistaan, on myös kaksikirjainkoodit.)

Peter Constable on kirjoittanut laajan analyysin Toward a Model for Language Identification and An Analysis of ISO 639, joka käsittelee kielikoodijärjestelmien ongelmia ja jonka Unicode-konsortio on julkaissut sarjassa Unicode Technical Notes.

Erikoista on, että ISO ja eräät muut standardointiorganisaatiot itse käyttävät yksikirjaimisia kielikoodeja joissakin yhteyksissä. Esimerkiksi jonkin standardin erityisen kieliversion koodi voi olla seuraavantapainen: "EN 1828:2002 (E)", missä "EN" ilmaisee standardien luokan (tässä 'CENin vahvistama eurooppalainen standardi'), "1828" on numero luokan sisällä, "2002" on vahvistamisvuosi, jonka avulla voidaan erottaa sisällöltään erilaiset versiot toisistaan, ja "(E)" ilmoittaa kieliversion (tässä englannin). Selitys tälle lienee, että koodit on haluttu pitää lyhyinä ja kyseisissä yhteyksissä tulevat kyseeseen vain muutamat kielet eli yksi kirjain riittää. Mutta tämä on outo poikkeus.

Muita kielikoodijärjestelmiä

Monissa yhteyksissä käytetään myös muita kielikoodijärjestelmiä kuin ISO 639:n mukaisia. Osaa niistä on käytetty melko vakiintuneestikin eri aloilla, joskin ehkä enemmänkin kokonaisten dokumenttien kielen ilmoittamiseen kuin kielimerkkauksessa.

Erityisesti laaja Ethnologue-tietokanta käyttää ns. SIL-koodia, joka on kolmikirjaiminen mutta poikkeaa ISO 639-2:sta joissakin suhteissa ja ennen muuta sisältää paljon suuremman määrän koodeja, yli 7 000.

Toinen laaja (yli 21 000 kieltä ja murretta) kielikoodien järjestelmä on Linguasphere. Ison-Britannian standardointijärjestö on ehdottanut kansainvälisen standardin laatimista sen pohjalle.

Kirjastoalalla on paljon käytetty MARC-kielikoodeja. Se on sovitettu yhteen ISO 639-2:n kanssa.

Käyttöjärjestelmissä ja muissa tietokoneohjelmissa on usein erilaisia omia kielikoodijärjestelmiä. Esimerkiksi Windowsissa on sisäisesti käytössä sekä kirjain- että numerokoodeja. Eräs sellainen järjestelmä sisältää koodinimiä kuten LANG_FINNISH ja koodinumeroita, jotka esitetään heksadesimaalisina, esim. suomen koodi on 0x0b eli desimaalisena 11. Näitä sekä Mac-järjestelmien kielikoodeja kuvailee dokumentti Language Codes: ISO 639, Microsoft and Macintosh. Toisaalta Microsoftin omassa dokumentaatiossa on kuvattu useita muita kielikoodijärjestelmiä. Ks. esim. List of Windows XP's Three Letter Acronyms for Languages, jossa pohjana ovat ISO 639:n kaksikirjainkoodit, joihin on lisätty kolmas kirjain, joka osoittaa maakohtaisen tai muun muunnelman.

RTF-tiedostomuodon dokumentaatio (erityisesti RTF:n version 1.5 spesifikaatio) puolestaan käyttää ilmaisua "the standard languages used by Microsoft" ja esittää taulukon, jossa esimerkiksi suomen kielen koodi on 0x040b. Tämän mukaisesti näyttää toimivan ainakin Word 95: kun siinä esimerkiksi asettaa dokumentin yleiskieleksi jonkin muun kielen kuin suomen ja sitten maalaa osan tekstistä ja asettaa sen kieleksi suomen, niin RTF-muotoon tallennuksessa tiedostoon menee
{\lang 1035 merkitty tekstinosa}
ja heksadesimaaliluku 0x040b on desimaalisena 1035.

Runsaasti tietoja erilaisista kielikoodijärjestelmistä on edellä mainitussa dokumentissa Language Identifiers in the Markup Context. Se on laaja ja informatiivinen, joskin osittain vaikealukuinen muun muassa siksi, että siinä on eri aikoina kirjoitettuja osia. Lisäksi lopussa olevat otteet eri lähteistä ovat käänteisessä aikajärjestyksessä, vaikka ne olisi luultavasti parempi lukea vanhimmista uusimpiin.

Kielikoodit Dublin Coressa

Metadataa koskevan Dublin Core -suosituksen (Dublin Core Metadata Element Set, Versio 1.1, Tallenteiden kuvailuformaatti, kohta 12 Kieli) mukaan käytetään kaksikirjaimisia koodeja, esimerkiksi (HTML:ssä metadataa esitettäessä)
<meta name="DC.Language" content="en">
Kyseisessä määrittelyssä on tältä osin kummallisuuksia: siinä väitetään virheellisesti RFC 1766:ta "Internet standardiksi" (ks. Mitä RFC:t ovat), puhutaan ISO 639:stä nimenomaan ja vain kaksimerkkiset koodit määrittelevänä mutta silti viitataan linkillä ISO 639-2:een ja lisäksi annetaan virheellinen esimerkki en-uk; Ison-Britannian ja Pohjois-Irlannin Yhdistyneen kuningaskunnan maakoodi on GB, ei UK. Nämä kummallisuudet ovat mukana myös 2001-04-12 päivätyssä suosituksessa Using Dublin Core (kohta 4.15 Language), paitsi että se ei viittaa ISO 639-2:een vaan Oasis-dokumenttiin Code for the Representation of the Names of Languages. From ISO 639, revised 1989, joka käsittelee kaksikirjaimisia koodeja mutta viittaa uudempaankin informaatioon, erityisesti (edellä jo mainitsemaamme) katsaukseen Language Identifiers in the Markup Context.

Dokumentti Dublin Core Qualifiers määrittelee merkintäjärjestelmän (encoding scheme) käsitteen. Lyhyesti sanottuna sillä tarkoitetaan sitä menetelmää (järjestelmää), jonka mukaan dokumentin jonkin ominaisuuden arvot esitetään koodatulla tavalla. Kielikoodien yhteydessä se tarkoittaa jotakin erityistä kielikoodien järjestelmää, kuten RFC 1766. Itse merkintäjärjestelmilläkin on Dublin Coressa koodit, kuten rfc1766 ja ISO639-2. Ilmeisestikin ajatuksena on, että niistä ensin mainittu olisi ensisijainen eli sitä olisi käytettävä, jos mahdollista.

Suomalaisen Julkisen hallinnon suosituksen JHS 143, Asiakirjojen kuvailuformaatti, mukaisessa metadatassa on kaksikirjaiminen koodi ainoa sallittu vaihtoehto. Toisaalta vuonna 2001 vahvistettu kansallinen standardi SFS 5895, Dublin Core -metadataformaatin suomalainen versio, ilmoittaa, että language-kentän merkintäjärjestelmiä ovat ISO 639-2 ja RFC 1766 sekä kansallinen merkintäjärjestelmä SFS-ISO 639. Nämä on lueteltu tässä järjestyksessä mutta esittämättä erityistä suositusta siitä, miten valinta niiden välillä tehdään. Standardi viittaa yhdysvaltalaiseen standardiin ANSI/NISO Z39.85 Dublin Core Metadata Element Set, jossa sanotaan:

Comment: Recommended best practice is to use RFC 3066 [RFC3066], which, in conjunction with ISO 639 [ISO639], defines two-and three-letter primary language tags with optional subtags. Examples include "en" or "eng" English, "akk" for Akkadian, and "en-GB" for English used in the United Kingdom.

Maakoodit ja kielikoodit

Kielikoodit on erotettava maakoodeista. Sekaannukset ovat tavallisia muun muassa siksi, että joskus maakoodi on sama kuin maan pääkielen koodi; esimerkiksi fi on sekä suomen kielen koodi että Suomen maakoodi. Maakoodeja käsittelee dokumentti Maailman maat - nimet, koodit, kuvauksia.

Suositus on, että maakoodi kirjoitetaan isoin kirjaimin, kielikoodi pienin kirjaimin. Tämä ei kuitenkaan ratkaise ilmaisun merkitystä. Kieli- ja maakoodeissa isojen ja pienten kirjainten välisellä erolla ei ole vaikutusta koodin merkitykseen. Se, tulkitaanko kirjainjono maakoodiksi, kielikoodiksi vai joksikin muuksi, riippuu käyttöyhteydestä eli siitä, mitä jossakin tekstin tai lomakkeen kohdassa, tietokannan kentässä tms. jonkin sopimuksen tai muun määrittelyn mukaan on.

Useissa yhteyksissä voidaan kielikoodin perään liittää maakoodi. Tällöin ilmaisu tarkoittaa kielen kyseisessä maassa puhuttua muotoa. Valitettavasti on erilaisia käytäntöjä sen suhteen, miten tällainen ilmaisu tarkkaan ottaen kirjoitetaan eli mikä on välissä käytettävä erotinmerkki. SFS/ISO 639:n mukaan käytetään välilyöntiä (esim. sv FI 'suomenruotsi'), aiemmin mainitussa DocBookissa alaviivaa (esim. sv_FI) ja seuraavassa kuvattavien Internet-sääntöjen mukaan yhdysmerkkiä (esim. sv-FI).

Internetin kielikoodikäytännöt

Internetissä on pyritty siihen, että kielimuodon voisi ilmoittaa tarkemminkin. Vuonna 1995 laadittu RFC 1766, Tags for the Identification of Languages, kuvasi järjestelmän, jossa kielikoodi (language tag) koostuu peruskoodista (primary tag) ja sitä mahdollisesti seuraavasta yhdysmerkistä ja lisäkoodista (subtag). Sen mukaan peruskoodi on normaalisti ISO 639-1:n mukainen kaksikirjainkoodi. Lisäksi on kaksi erityiskoodia: i-kirjain, jonka alaisiksi lisäkoodeiksi voidaan erikseen rekisteröidä koodeja eri kielille, ja x-kirjain, joka on varattu ns. yksityiseen käyttöön eli viestinnän osapuolten keskenään sopimaa käyttöä varten. Jos lisäkoodi on kaksikirjaiminen, se tulkitaan maakoodiksi ISO 3166-1:n mukaan. Esimerkiksi en-US tarkoittaa amerikanenglantia (Yhdysvalloissa puhuttua englantia) ja en-GB brittienglantia. Muunlaisia, tarkemmin sanoen 3 - 8 merkin mittaisia lisäkoodeja voi rekisteröidä IANA:n ylläpitämään rekisteriin, josta on olemassa luetteloversio ja lista viittauksia varsinaisiin rekisteröintitietoihin. Ehdotukset lisäyksiksi rekisteriin käsitellään listalla ietf-languages. Hyödyllinen tiivistelmätaulukko on dokumentissa RFC 3066 Language code assignments.

Useat Internet-protokollat viittaavat RFC 1766:een. Käytännössä tällaiset viittaukset on usein tulkittava niin, että niissä viitataan yleisemmin kielikoodeja käsitteleviin, kulloinkin voimassa oleviin RFC:ihin. Esimerkiksi HTML 4.01:n määrittely sanoo: "[RFC1766] defines and explains the language codes that must be used in HTML documents." Toisaalta sen References-osa viittaa RFC 1766:n uusimistyöhön, ja XML:n määrittelyn kohta Language Identification jo selvästi sanoo xml:lang-määritteestä: "The values of the attribute are language identifiers as defined by [IETF RFC 1766], Tags for the Identification of Languages, or its successor on the IETF Standards Track.". - RFC:t ovat numeroitu sarja Internetiin liittyviä spesifikaatioita ja muita dokumentteja. Aiheesta kertoo lisää dokumentti Mitä RFC:t ovat.

Sittemmin laadittiin kaksi uutta RFC:tä, jotka korvaavat RFC 1766:n, nimittäin Tags for the Identification of Languages (RFC 3066) ja Content Language Headers (RFC 3282). Niistä ensin mainittu määrittelee itse kielikoodien järjestelmän. Keskeiset periaatteet ovat samat kuin RFC 1766:ssa, mutta kolmikirjaimiset koodit on varattu käytettäviksi ISO 639-2:n mukaan. Kielistä, joille on kaksikirjaiminen koodi, tulee käyttää sitä eikä kolmikirjaimista, siis esimerkiksi suomesta koodia fi eikä fin. Toistaiseksi käytetään Internetissä lähes yksinomaan kaksikirjaimisia koodeja.

Syyskuussa 2006 mainitut RFC:t korvattiin määrittelyillä Tags for Identifying Languages (RFC 4646) ja Matching of Language Tags (RFC 4647). Niihin on sopivinta viitata tunnuksilla BCP 46 ja BCP 47, koska BCP-numero (BCP = Best Current Practice) ei muutu, toisin kuin RFC-numero, jos määrittelystä myöhemmin tehdään uusi versio.

Kielikoodit viestien otsaketiedoissa ja mediatyypeissä

Edellä mainittu RFC 3282 käsittelee kielen ilmoittamista niin sanotuissa otsakkeissa (headers) esimerkiksi Webin tiedonsiirtoprotokollassa HTTP:ssä. Otsakkeet eivät yleensä näy käyttäjille, eivätkä useimmat ehkä edes tiedä, miten ne saa näkyville, mutta ne voisivat ohjata ohjelmia, joilla dokumentteja tai viestejä käsitellään, esimerkiksi hakukoneita ja puhesyntetisaattoreita.

Tämä on kuitenkin toistaiseksi aika puhtaasti vain teoriaa. Lisäksi teoriassakin tämän otsakkeen merkitys on epäselvä.

Esimerkiksi otsake
Content-Language: fi
kertoo RFC 2616:n mukaan, että dokumentti on tarkoitettu suomen kieltä osaaville; käytännössä tämä merkitsee yleensä sitä, että dokumentin pääkieli on suomi. Jos kyseisessä otsakkeessa luetellaan useita kieliä, se tarkoittaa, että dokumentti on tarkoitettu ihmisille, jotka osaavat ainakin yhtä luetelluista kielistä. Esimerkiksi Content-Language: fi,sv sopisi siis dokumentille, joka sisältää saman tekstin sekä suomeksi että ruotsiksi. RFC 3282:n mukaan tämä otsake ilmoittaa dokumentin kielen tai kielet, mikä on tietysti varsin pitkälle sama asia. Mutta se voitaisiin tulkita myös niin, että Content-Language: fi,sv sopisi myös dokumentille, joka sisältää suuren määrän ruotsinkielisiä paikannimiä ja lyhyet suomenkieliset selostukset.

Vaikka esimerkiksi HTTP-otsake Content-Language: fi ja HTML-merkkaus <html lang="fi"> voivat vaikuttaa samaa tarkoittavilta, kyse on kuitenkin periaatteessa erillisistä asioista. Esimerkiksi jos HTML-dokumentissa on vain joukko esineiden kuvia ja suomenkielisiä nimiä, on epäilemättä oikein merkata sen kieleksi <html lang="fi">. Mutta Content-Language: fi ei välttämättä olisi oikein, jos se tulkitaan määrittelyjen mukaan eli niin, että dokumentin kohdeyleisön kieli on suomi. Voisihan dokumentti olla tarkoitettu opiskelutarkoituksiin ihmisille, jotka eivät ennestään lainkaan osaa suomea!

Otsakkeet koskevat dokumenttia kokonaisuutena. Niillä ei siis voida ilmoittaa dokumentin osien kieltä. Toisaalta otsakkeita voidaan käyttää silloinkin, kun dokumentin muoto ei salli kielen ilmoittamista kielimerkkauksella, esimerkiksi kun dokumentti on pelkkää tekstiä (eikä esimerkiksi HTML-muotoinen) tai äänite tai video.

Koko dokumentin kielellä on keskeinen merkitys muun muassa niin sanotussa kielivalintamekanismissa. Tällöin kieltä ei kuitenkaan ilmaista HTTP-otsakkeessa vaan palvelimen sisäisessä määrittelyiedostossa. Aihetta käsittelee dokumentti Tekniikoita monikielisiä Web-sivustoja varten.

Dokumentin kieli voidaan ilmoittaa myös mediatyypin language-parametrilla. Esimerkiksi
text/plain; language=fi
ilmoittaa, että kyseessä on pelkkää tekstiä oleva dokumentti, jonka kieli on suomi. Kyseinen parametri on kuvattu dokumentissa RFC 2987.

Suositus JHS 143 sanoo metadatan kielikentästä, että se ilmoittaa "asiakirjan kielen". Ja se lisää: "Jos asiakirjassa on käytetty useita kieliä voidaan tätä kenttää toistaa." Epäselvää on, onko järjestyksellä tällöin merkitystä ja voidaanko kenttää käyttää, jos jotakin kieltä on vain vähän (esimerkiksi vain yksi sana).

Riittääkö kielikoodi?

Kielikoodi ei useinkaan anna riittävää tietoa tekstin kielestä eri tarkoituksia varten, varsinkaan kehittynyttä tekstien ohjelmallista käsittelyä varten, ei vaikka kielikoodien järjestelmässä mentäisiin murteiden tasolle. Asiakirjan kieltä tarkemmin kuvaavien tietojen esittäminen yhtenäisten koodijärjestelmien on kuitenkin vasta kehitteillä.

Ilmeisin tarve on käytetyn kirjoitusjärjestelmän tietäminen. Tätä käsitellään jäljempänä kohdassa Kirjoitusjärjestelmien vaikutus. Käytännössä nykyisin ohjelmat tehdään yleensä olettaen, että kutakin kieltä kirjoitetaan vain yhtä kirjoitusjärjestelmää käyttäen, mikä ei pidä paikkaansa.

Kirjoitusjärjestelmistä onkin laadittu standardi ISO 15924, Code for the Representation of Names of Scripts. Se määrittelee nelikirjaimiset koodit, ks. sivustoa ISO 15924 Registration Authority. Koodaus on melko karkea; esimerkiksi Latn tarkoittaa yleisesti latinalaista (latinalaisperäistä) kirjoitusjärjestelmää, vaikka sitä käyttävien kielten kuten latinan, saksan ja suomen järjestelmissä on paljon eroja. Erityisesti tämä koodi ei tee eroa vaikkapa kyrillisen kirjoituksen erilaisten translitterointien (latinisointien) välillä. Huomattakoon, että esimerkiksi HTML:ssä ei ole mitään elementtiä eikä määritettä, jolla tekstin osan kirjoitusjärjestelmän voisi ilmaista. Sen sijaan standardi esittää esimerkkinä, että HTML:ssä voisi ilmoittaa koko dokumentin kirjoitusjärjestelmän meta-elementillä tyyliin
<meta name="Content-Script" content="Latn">
On kuitenkin huomattava, että meta-elementtien järjestelmä on varsin säätelemätön ja epämääräinen. Jossain määrin hämäävää on, että kirjoitusjärjestelmästä käytetään englannissa nimitystä script, joka tarkoittaa toisaalta myös eräänlaisia tietokoneohjelmia, "skriptejä".

Automaattisessa kielenkääntämisessä, varsinkin sen kehittyneissä muodoissa, olisi olennaista tietää myös kielilaji ja -tyyli, esimerkiksi erottaen arkikieli ylevästä tyylistä. Joissakin kielissä on suuri ero oppineiston ja vähemmän kouluja käyneiden kielenkäytön välillä. Kielentutkijakin voisi olla kiinnostunut selvittämään suuresta tekstimassasta, miten usein siinä esiintyy vaikkapa asiatyylisessä tekstissä jokin sana, jonka oletetaan olevan siirtymässä slangista asiatyyliinkin. Silloin olisi hyvin olennaista, että kielilajit on jollain tapaa eroteltu helposti käsiteltävillä koodeilla, jotta voidaan tehokkaasti etsiä sellaisia esiintymiä.

Myös kielenkäytön tilanne voi olla olennainen esimerkiksi puhesynteesissä. Näytelmien yms. käsikirjoituksissa on usein sulkeissa huomautuksia tyyliin "(Kiivaasti)" tai "(Hiljaisella äänellä)". Nämä ovat eräänlaista merkkausta, mutta sellaista, jota on varsin hankala hyödyntää tekstien automaattisessa käsittelyssä, ellei päästä yhtenäiseen, koodattuun käytäntöön.

Erästä hanketta, jossa pyritään kieliasua kuvaavien koodien kehittämiseen, selostavat artikkeli Standards Bodies Face Growing Demand for Enhanced Language Identifier Systems ja ISO / TC 37 / SC 2 / WG 1:n piirissä laadittu (Word-muotoinen) dokumentti Additional language coding.

Ongelmia kielimerkkauksen käytössä

Kielimerkkauksen käyttöön liittyy monenlaisia ongelmia. Seuraavassa tarkastellaan niitä melko yksityiskohtaisesti. Tässä on kuitenkin hyvä muistaa, että vaikka yksityiskohdissa joudutaankin moniin vaikeuksiin, kielimerkkaus on käytännössä varsin helppo tehdä. Sitä ei ole pakko viedä yksittäisten sanojen tasolle, jos ongelmat siellä tuntuvat liian suurilta.

Sisältö:

Miten yksityiskohtaisesti eri osien kieli kannattaa merkata?

Muutoin yksikielisessä tekstissä voi esiintyä lyhyitä tai pitkiä lainauksia muilla kielillä, vieraskielisiä nimiä tai vieraista kielistä peräisin olevia ns. sitaattilainoja. Miten yksityiskohtaisesti dokumentin eri osien kieli kannattaa merkata?

Ensimmäisenä varmaankin tulee mieleen se käytännön seikka, että yksityiskohtainen merkkaaminen voi olla varsin työlästä. Tämän lisäksi on useita jäljempänä kuvattavia seikkoja, joiden takia merkkausta ei aina kannata viedä ihan sanojen ja jopa sananosien tasolle. Nyrkkisäännöksi esitänkin:

Merkkaa koko dokumentin kieli ja muunkielisten lainausten, kirjojen nimien ja yleensä pitkähköjen muunkielisten tekstien kieli. Lisäksi voit merkata yksittäisten sanojenkin kielen, jos on selvää, että ne on syytä tulkita kaikin tavoin vieraskielisiksi. Epäselvissä tapauksissa on parempi jättää kielimerkkaus pois: when in doubt, leave it out.

Mitä kieltä?

Usein on tulkinnanvaraista, mitä kieltä jokin ilmaisu on. Selvimmän esimerkin muodostavat sanat, jotka on lainattu kielestä toiseen ja jotka ovat osittain mukautuneet lainaajakieleen. Onko esimerkiksi ranskasta englantiin lainautunut sana "fiancé" ranskaa vai englantia? Se kirjoitetaan täysin ranskan mukaisesti; ääntämys taas jäljittelee ranskan ääntämystä mutta ei kokonaan vastaa sitä. Suomen kielessäkin tällaista esiintyy erittäin paljon. Vaikka usein sanotaan, että sitaattilainat tulisi kirjoittaa ja ääntää täysin alkukielen mukaan, niin käytännössä esiintyy varsin paljon eriasteisia mukautumia, ja nykyisin ne kielenoppaissakin jo usein tunnustetaan.

Miten pitäisi merkata esimerkiksi sana "Windows", kun se esiintyy käyttöjärjestelmän nimenä suomenkielisessä tekstissä? Alkujaan sana on tietysti englantia, mutta suomen kielessä se ei yleensä äänny täysin englannin mukaisesti, esimerkiksi loppukonsonantti ei äänny soinnillisena. Toisaalta sana ei ole kirjoitusasultaan mukautunut suomeen. Oikeastaan tarvittaisiin tapa merkata, että sana on "siirtymässä" kielestä toiseen.

Voidaan jopa kysyä, onko "Helsinki" suomea vai englantia, kun se esiintyy englanninkielisessä tekstissä. Englannissahan se tavallisimmin ääntynee niin, että paino on toisella tavulla. Missä vaiheessa tällainen "väärä" ääntämys muuttuu osaksi kielen todellisuutta, joka on syytä tunnustaa? Esimerkiksi suomen sana "sauna" ääntyy englannissa tavallisesti niin, että "au" ääntyy pitkänä vokaalina "oo" ja loppu-a epämääräisenä vokaalina. Eikö tällöin voi sanoa, että sana on lainautunut englantiin ja muuttunut osaksi englannin kieltä? Tilanne on toinen, jos englanninkielisessä tekstissä esiintyy sellaisia suomen sanoja, jotka eivät ole mitenkään yleisesti tunnettuja. Ne on syytä merkata suomenkielisiksi.

Erityisiä ongelmia voi periaatteellisesti ehkä oikea kielimerkkaus aiheuttaa silloin, kun teksti on translitteroitua tai transkriboitua eli se on tavalla tai toisella siirretty toiseen kirjoitusjärjestelmään, esimerkiksi japanin sana kirjoitettu latinalaisin kirjaimin, esimerkiksi "kimono". Käsittelemme näitä ongelmia jäljempänä kohdassa Kirjoitusjärjestelmien vaikutus.

Käytännöllinen ratkaisu on ehkä se, että rajatapauksessa tulkitaan sanan olevan sitä kieltä, jota ympäröivä teksti on. Näin vältetään esimerkiksi puhesynteesissä häiritsevät lainanantajakielen mukaiset ääntämykset sanoissa, joissa sitä ei ole tapana käyttää. Lisäksi tämä on helppo ratkaisu, koska se vähentää merkkauksen määrää: sanan kieltä ei erikseen merkata vaan se määräytyy ympäröivän elementin kielestä. Puhesynteesissä ja yleensä puheessa pätee, että vieraista kielistä peräisin olevien sanojen "liian tarkka" ääntäminen häiritsee, kun ne esiintyvät tekstin seassa. Sen sijaan erillisissä lainauksissa tilanne on toinen; niissä mahdollisimman hyvä alkukielen mukainen ääntämys aiheellisesti korostaa eroa oman tekstin ja sitaatin välillä.

Sekakielisyyksiä syntyy myös tietämättömyyden ja tahallisen vääntelyn kautta. Miten pitäisi tulkita esimerkiksi hevosennimi "Kiikku's Vera", joka luetaan suomalaisittain "Kiikkus Veera" mutta jossa on selvästikin tarkoitettu käyttää englannin genetiiviä?

Myös eläinten, kasvien ja muiden eliöiden ja eliöryhmien tieteelliset ("latinalaiset") nimet ovat ongelmallisia. Ne noudattavat pääosin latinan kielen kirjoitussääntöjä ja muutamia latinan kielioppisääntöjäkin, ja niiden ääntämys on lähinnä latinan mukainen, mutta niihin sisältyy runsaasti kreikan sanoja latinisoidussa asussa ja muistakin kielistä otettuja sanoja. Kaiken kaikkiaan lienee parasta merkata kieleksi latina mutta tietoisena siitä, että tästä voi seurata ongelmia. Esimerkki:
<i lang="la">Anas platyrhynchos</i>

Entä lyhenteen kieli? Mitä kieltä on "IPA" tai "USA"? Ne luetaan suomessa yleensä joko käyttäen suomenkielisiä kirjainten nimiä (ii pee aa, uu es aa) taikka ikäänkuin ne olisivat suomen sanoja (ipa, usa). Käytännöllinen menettelytapa on, että niiden tulkitaan olevan sitä kieltä, jossa niitä kulloinkin käytetään, paitsi jos ne on tarkoitus todella lukea alkukielen mukaisesti. Tämä siis merkitsee, että mitään erillistä merkkausta ei käytetä. Poikkeuksena olisi esimerkiksi lyhenne BBC, koska se on tapana suomessa lukea lausumalla kirjainten englanninkieliset nimet, siis suunnilleen "bii bii sii". Silloin sopiva merkkaus olisi
<abbr lang="en">BBC</abbr>
Periaatteessa eräiden suositusten mukaan pitäisi ilmoittaa title-määritteellä lyhenteen "lavennus" ainakin, kun lyhenne esiintyy ensi kerran, siis esimerkiksi
<abbr lang="en" title="British Broadcasting Company">BBC</abbr>
Tähän liittyy kuitenkin monia ongelmia, joista yksi on se, että puhesyntetisaattori saattaisi tulkita tilanteen niin, että sen pitää lukea lyhenne "avattuna".

Ihmisten kielet ja tekniset notaatiot

Sanaa "kieli" käytetään yleisesti myös puhuttaessa erilaisista merkintätavoista kuten "matematiikan kielestä" tai "ohjelmointikielistä" tai "merkkauskielistä". Tämä aiheuttaa paljon sekaannuksia, kuten olen kuvannut dokumentissa Datatekniikan "kielet" - ehdotus käsitteiden selvennykseksi ja luokitteluksi.

Tässä tarkastellun kielimerkkauksen yhteydessä on kyse aina "oikeista" kielistä, sellaisista, joita ihmiset käyttävät puheessa ja kirjoituksessa, tai ainakin niitä vastaavista kielistä kuten kuvitteellisista kielistä, joita käytetään ihmiskielten tapaan, vaikkapa Keski-Maan haltiakieli tai klingonien kieli. Kyse ei välttämättä ole elävästä kielestä vaan myös esimerkiksi muinaisegypti, jonka suoranaisesti tunnemme vain kirjoitettuna, on ilman muuta kieli. Myös niin sanotut keinotekoiset kielet eli suunnitelmakielet (artificial languages, constructed languages) kuten volapük tai esperanto kuuluvat ilman muuta joukkoon, ainakin jos ne on suunniteltu samanlaiseen käyttöön kuin luonnolliset kielet. Tosin suunnitelmakieliä on tehty hyvin monenlaisia, ja jotkin niistä voitaisiin ehkä luokitella koodijärjestelmän ja ihmisten kieleksi tarkoitetun rakennelman välimaastoon.

Mutta ulkopuolelle siis jäävät monet "kieliksi" kutsutut merkintätavat, kuten esimerkiksi merkkauskieli HTML, tyylisääntökieli CSS tai ohjelmointikieli C. Kielikoodijärjestelmien määrittelyissä usein erikseen sanotaan, että ne on tarkoitettu ihmisten kieliä (human languages), ei tietokonekieliä varten. Miten sitten olisi meneteltävä, jos dokumentissa esitetään sellaisilla "kielillä" kirjoitettuja ilmaisuja eli jos vaikkapa haluaisimme puhua CSS:n font-family-ominaisuudesta nimeltä? Missään tapauksessa ei pidä ruveta antamaan vaikkapa CSS:lle kielikoodia ja käyttämään sitä. Eri asia on, että voisi olla hyvä, jos käytetyn koodin, merkintätavan, voisi ilmaista merkkauksella. Mutta tämä on pidettävä erossa kielimerkkauksesta.

Epäselvää on, tulisiko "tietokonekielten" ilmaisujen yhteydessä aina käyttää code-merkkausta HTML:ssä. Usein kyseistä merkkausta käytetään ulkoasun takia, tasalevyisen fontin aikaansaamiseksi. Mutta voisiko sillä olla myös looginen merkitys? Mielestäni voisi, koska code-elementin määrittely sanoo: "Designates a fragment of computer code." Esimerkiksi kielenkäännösohjelma (tai ihmiskääntäjä) voisi siitä päätellä, että ilmaisu on käännöksessä jätettävä sellaisekseen, vaikka se näyttäisi osittain olevan englantia. Valitettavasti nykyiset käännösohjelmat eivät näytä niin tekevän.

Mutta olisiko mainitunlaisten "kielten" yhteydessä kuitenkin käytettävä kielimerkkausta silloin, kun niissä esiintyvät merkkijonot on otettu jostain luonnollisesta kielestä? On selvää, että esimerkiksi merkkijonoa "function" ei pidä kääntää, kun se viittaa ohjelmointikielen varattuun sanaan. Mutta toisaalta se pitäisi lausua englannin mukaan, ainakin suunnilleen. Tämä on hankala kysymys etenkin, jos dokumentissa esiintyy paljon koodia. Puhe-esityksen kannalta ongelmana on, että esimerkiksi HTML-koodissa tai lähdekielisessä tietokoneohjelmassa on sekaisin englannista otettuja varattuja sanoja, välimerkkejä ja eri kielistä otettuja sanoja tai sanantapaisia ilmaisuja. Miten esimerkiksi seuraava pitäisi lukea ääneen?
<table class="tilasto">

Esimerkki osoittaa pieneltä osaltaan, että on mielekästä liittää koodinpätkään kielimäärite, joka on loogisesti riippumaton siitä, mikä on käytetty koodijärjestelmä, kuten tietokonekieli. Esimerkissämme merkkijono tilasto on yhtäältä osa HTML-merkkausta, toisaalta suomen kieltä siinä mielessä, että ääneen luettaessa se pitäisi lausua suomen sääntöken mukaan.

Ehkäpä voimme ainakin toistaiseksi lähteä siitä, että jos esimerkiksi HTML-, CSS- tai C-koodia kuunnellaan, kuulija ymmärtää englannista peräisin otetut sanat lausuttuina sen kielen mukaan, jolla dokumentti muutoin on kirjoitettu. Lausutaanhan sellaiset sanat muutenkin usein "kirjaimellisesti", esimerkiksi suomen mukaan luettuina. Se, että koodin eri osille kirjoitettaisiin erikseen kielimerkkaus, olisi huomattavan työlästä eikä tuottaisi mitään selvää käytännön etua.

"Tietokonekieliin" otetut englannin sanat on usein typistetty, esimerkiksi "lang", tai sanoja on sekä katkottu että yhdistelty, esimerkiksi "charset". Onpa niitä myös kirjoitettu väärin. Esimerkiksi HTTP-protokollan erään otsakkeen nimi on "Referer", koska joku alun perin kirjoitti englannin sanan "referrer" väärin. Kun se on kerran otettu protokollaan, sitä ei enää haluta muuttaa. Monia virheellisiä kirjoitusasuja sisältyy myös eliöiden tieteellisiin nimiin. Valitettavasti ei kielimerkkaukseen sisälly mitään tapaa ilmoittaa, että jokin sana on tiettyä kieltä mutta väärin kirjoitettu.

Tavallaan kielten ja notaatioiden välimaastoon kuuluvat sellaiset teksti-ilmaisut kuin SI-mittajärjestelmän mukaiset suureiden arvojen merkinnät, vaikkapa "40 km/h". Ne ovat osa yleismaailmallista järjestelmää ja ne tulisi aina kirjoittaa samalla tavoin, ympäröivästä kielestä riippumatta. Sen sijaan ne luetaan ympäröivän kielen mukaan, esimerkiksi "neljäkymmentä kilometriä tunnissa" tai "fourty kilometers per hour". Jälkimmäinen hoituu sillä, että ilmaisulle itselleen ei ole kielimerkkausta vaan sen kieli määräytyy tekstin rakenteen ylemmällä tasolla olevasta merkkauksesta. Sen sijaan kirjoitusasun osoittaminen kieliriippumattomaksi, niin että se esimerkiksi käännettäessä tulee pitää samana, vaatisi periaatteessa erityisen merkkauksen; käytännössä ei sopivaa merkkausta ole nykyisin käytettävissä.

Miten ilmaistaan, ettei kieltä voida ilmaista?

Edellä mainittiin ISO 639:n kuvauksessa erikoiskoodit mul ja und. Niiden määritelmät standardissa ovat:

The language code mul (for multiple languages) should be applied when several languages are used and it is not practical to specify all the appropriate language codes.

The language code und (for undetermined) is provided for those situations in which a language or languages must be indicated but the language cannot be identified.

Koodia und on voisi ajatella käytettävän useissa tilanteissa, jotka ovat itse asiassa varsin erilaisia: kieltä ei tunneta; kieli on tunnettu mutta sille ei ole koodia ISO 639-2:ssa; tekstille on ilmoitettava kieli, mutta se ei ole mitään ihmisten kieltä vaan esimerkiksi tietokonekoodia tai salasana. Toisaalta ISO 639 FAQ mainitsee mahdollisuuden käyttää kolmea välilyöntiä, jos "a language code is not applicable because there is no sung, spoken, or written textual content".

Yleisesti kielikoodijärjestelmissä on varsin epätyydyttävästi ratkaistu se, miten menetellään, kun mitään kielikoodia ei voi käyttää.

Mahdollisia tapauksia on useita erilaisia:

Kuitenkin Internetin kielikoodikäytäntöjen perustan määrittelevä RFC 3066 sanoo (kohdassa 2.3), että und-koodia ei saa käyttää, ellei protokolla pakota ilmaisemaan kielikoodin silloinkin, kun kieli on tuntematon:

You SHOULD NOT use the UND (Undetermined) code unless the protocol in use forces you to give a value for the language tag, even if the language is unknown. Omitting the tag is preferred.

Tämä merkitsee, että esimerkiksi HTML:ssä ei oikeastaan pitäisi käyttää määritettä lang="und" koskaan, koska lang-määrite ei ole pakollinen! Mutta tällöin jäisi ilmaisematta se olennainen ero, mikä on niiden tilanteiden välillä, että kieltä ei ole viitsitty yrittääkään kertoa, ja että kielimerkkausta käytetään järjestelmällisesti ja osa tekstistä on tuntematonta kieltä.

Koodia mul ei liene koskaan syytä käyttää kielimerkkauksessa eikä juuri muulloinkaan. Kielimerkkauksessahan voidaan ylimmän tason elementti merkata pääkielen mukaan ja alimman tason elementit kukin oman kielensä mukaan, tarvittaessa lisäten merkkauselementtejä vain tätä varten. Lisäksi edellä mainittu RFC௺ erikseen sanoo, että mul-koodia ei tulisi käyttää silloin, kun protokolla mahdollistaa useiden kielten ilmaisemisen, kuten Content-Language-otsakkeessa (josta kerrotaan kielivalintamekanismin kuvauksessa).

Kirjoitusjärjestelmien vaikutus

Mikä on kirjoitusjärjestelmä?

Kirjoitusjärjestelmä, englanniksi script, tarkoittaa ihmiskielen kirjoittamisen perusmenetelmää. Se voi olla aakkoskirjoitusta, tavukirjoitusta, sanakirjoitusta tms. Käytännössä erotetaan toisistaan joukko suuria kirjoitusjärjestelmiä, kuten latinalainen, kyrillinen, kreikkalainen, kiinalainen, hieroglyfit ym. Samasta kirjoitusjärjestelmästä on erilaisia muunnelmia ainakin merkistön tasolla. Esimerkiksi suomi ja ranska käyttävät latinalaista kirjoitusjärjestelmää, mutta erilaisia lisämerkkejä käyttäen.

Periaatteessa kirjoitusjärjestelmä on erotettava kielestä. Jos esimerkiksi venäjää kirjoitetaan latinalaisin kirjaimin, se on edelleen venäjää. Itse asiassahan monet kielet ovat vaihtaneet kirjoitusjärjestelmää aikojen kuluessa, eikä tähän sisälly, että itse kieli silloin muuttuisi toiseksi.

Toistaiseksi ei ole määritelty mitään tapaa merkkauksessa ilmoittaa, mikä on käytetty kirjoitusjärjestelmä. Käytännössä sen oletetaan olevan se, mitä kullekin kielelle yleisimmin käytetään. Vertaa kohtaan Riittääkö kielikoodi?

Loogista olisi, että kieli ja kirjoitusjärjestelmä ilmaistaan toisistaan riippumatta. Täten on erikoista, että IANAn rekisteriin on otettu koodeja, joissa kirjoitusjärjestelmä ilmaistaan kielikoodin nelikirjaimisella alakoodilla, esimerkiksi siten, että az-Cyrl tarkoittaa kyrillisin kirjaimin kirjoitettua azeria ja az-Latn latinalaisin kirjaimin kirjoitettua azeria.

Ääntämisohjeet

Ääntämisohjeet ovat tavallaan kielen ja muun notaation välimaastossa oleva asia. Jos kirjoitan, että englannin sana "people" ääntyy suunnilleen "piipl", niin mitä kieltä "piipl" on? Periaatteessa voisimme sanoa, että se on englantia mutta kirjoitettuna englannin normaalista kirjoitusjärjestelmästä poikkeavasti. Parasta lienee käytännössä jättää kielimerkkaus pois, koska puhesynteesissä tulos voisi olla absurdi, kun ohjelma yrittää lukea ilmaisun "piipl" englannin sääntöjen mukaan. Oikeastaan tarvitsisimme tavan kertoa kirjoitusjärjestelmä. Sen ei tarvitsisi olla muuta kuin tapa kertoa, että jokin ilmaisu luetaan vaikkapa suomen kielen sääntöjen mukaan mutta sitä ei muutoin käsitellä suomenkielisenä. - Tässä käytettiin yksinkertaisuuden vuoksi esimerkkinä suomen kielen sääntöjen mukaan kirjoitettua ääntämisohjetta. Usein käytetään järjestelmiä, joissa on erilaisia lisämerkkejä ehkä hyvinkin paljon ja jotka on usein pyritty tekemään hyvinkin täsmällisiksi, esimerkiksi IPA-kirjoitus. Koska IPA-kirjoituksen lukemisen oikea tapa kielestä riippumatonta, niin IPA:lla esitetyn ääntämisohjeen voi merkata tekstin kielen mukaiseksi.

Entä mitä pitäisi ajatella sellaisista ilmaisuista kuin "tuu tii to tööti tuu", jonka on tarkoitus parodioida huonoa englannin taitoa, tarkemmin sanoen esittää ilmaisun "two tea to thirty-two" kehnoa ääntämystä? Niihin voi suhtautua kuten yksinkertaisiin ääntämisohjeisiin, joissa ääntämys esitetään suomen kirjoitusjärjestelmän mukaan. Käytännössä siis on parasta jättää kielimerkkaus pois.

Translitterointi ja transkriptio

Se, että kirjoitusjärjestelmää ei voi ilmoittaa, aiheuttaa ongelmia myös silloin, kun teksti esitetään käyttäen jotakin translitteraatiota tai transkriptiota. Silloin teksti kirjoitetaan eri kirjoitusjärjestelmällä kuin sillä, jolla kyseistä kieltä normaalisti esitetään. Jos esimerkiksi halutaan kirjoittaa kreikkalainen nimi latinalaisin kirjaimin, niin tulisiko käyttää sentapaista merkkausta <span lang="el">Stephanos Piperoglou</span>? Ainakaan puhesyntetisaattori ei voi tuottaa kovin hyvää tulosta, koska se ei tiedä, mitä translitterointimenetelmää on käytetty. Käytössä on useita erilaisia kreikan translitteroinnin ja transkription menetelmiä.

Ongelma on vielä suurempi esimerkiksi venäläisten nimien osalta, koska niille käytetään hyvin monenlaisia translitterointeja. Esimerkiksi merkkauksesta <i lang="ru">chas</i> ei ohjelma voi edes periaatteessa tietää, tarkoitetaanko venäjän sanaa час 'tunti', kuten tarkoitetaan, jos translitterointi on tulkittava englannissa vallitsevan käytännön mukaan, vaiko ehkä шас ranskalaisen translitteraation mukaan tai хас saksalaisen translitteraation mukaan tai kenties цхас kansainvälisen standardin (ISO 9) mukaan. Ohjelman voi tuskin olettaa tarkistavan sanakirjoista, mitkä tulkinnoista vastaavat todellisia sanoja, varsinkaan, kun kieli muuttuu ja tekstissä voidaan toki käyttää myös keksittyjä ja kuvitteellisia sanoja. (Näitä vastaavat suomen kielen mukaiset translitteroinnit ovat tšas, šas, has ja tshas. Ks. sivua Venäjän translitterointi.)

On kaksi isohkoa käytännön ongelmaa, joiden takia on ehkä parempi välttää kielimerkkausta silloin, kun teksti on translitteroitu tai transkriboitu eli siirretty toiseen kirjoitusjärjestelmään:

(Edellä mainitut tekstit siten, että sanat Dostojevski ja
manga ovat eri fontilla kuin muu teksti.)

Mozillassa on erityiset asetukset, joissa voi valita, mitä fontteja selain käyttää erikielisten tekstien esittämiseen. Oletusarvot ovat sellaiset, että esimerkiksi japaninkielisen tekstin fontti on myös latinalaisten merkkien osalta erilainen kuin "länsieurooppalaisen", mistä seuraa yllä kuvattu ilmiö. Aiheesta kertoo lisää Alan Flavellin sivu I18n - Browsers and fonts kohdassa Mozilla.

Ongelma voi ilmetä myös silloin, kun suomenkielisellä sivulla on esimerkiksi puolankielisiä sanoja, joille on käytetty kielimerkkausta. Jos sivulla ei aseteta tekstin fonttia, Mozilla tällöin käyttää kyseisille sanoille sitä fonttia, joka on Mozillan asetuksissa liitetty keskieurooppalaiseen merkistöön. Tällöin tekstin ulkoasu voi ikävästikin poiketa muun tekstin asusta. Käytännössä ongelma on pieni, koska Mozillan oletusasetukset keskieurooppalaisen merkistön fonteille ovat samat kuin länsieurooppalaisen merkistön fonteille.

Edellä kuvatut fonttiongelmat voidaan välttää asettamalla tekstin fontti erikseen, esimerkiksi CSS-säännöllä
body { font-family: Arial, sans-serif; }
sillä Mozillan fontinvalintasäännöt koskevat vain tilannetta, jossa sivu jättää fonttien valinnan selainten tehtäväksi.

Vaikutus CJK-merkkien esitykseen

Kielimerkkaus voi vaikuttaa siihen, millä tavoin selain esittää ns. kiinalais-japanilais-korealaiset kirjoitusmerkit (CJK-merkit). Unicodessa ne on yhtenäistetty niin, että kielieroa ei oteta huomioon merkkien (koodien) tasolla, vaikka merkeistä käytetään eri kielissä osittain erilaisia muotoja. Selain saattaa kuitenkin ottaa kielieron huomioon, jos kieli on ilmoitettu merkkauksessa.

Seuraava taulukko esittää erään CJK-merkin (U+9FA5) ensin ilman kielimerkkausta, sitten kolmea eri kielimerkkausta käyttäen. Esimerkiksi Mozilla (ja Firefox) esittää oletusarvoisesti merkin eri tavoilla kielimerkkauksen mukaan siten, että se käyttää japanin mukaista esitystä, jos kieltä ei ole ilmoitettu (tai jos ilmoitettu kieli ei ole sellainen, jossa käytetään CJK-merkkejä). Jotta erot olisi helpompi havaita, on merkki esitetty tässä hyvin isokokoisena.

merkkaus merkki kieli
&#40869; ei ilmoitettu
<span lang="zh">&#40869;</span> kiina (yksinkertaistettu kirjoitusjärjestelmä)
<span lang="zh-Hant">&#40869;</span> kiina (perinteinen kirjoitusjärjestelmä)
<span lang="ja">&#40869;</span> japani

Kiinan kieltä kirjoitetaan sekä ns. perinteisellä (traditional) että ns. yksinkertaistetulla (simplified) kirjoitusjärjestelmällä. Näitä ei kuitenkaan aiemman käytännön mukaan erotettu toisistaan loogisella koodauksella vaan maakoodeilla siten, että zh-CN (missä CN on Kiinan maakoodi) tai pelkkä zh tarkoittavat yksinkertaistettua ja zh-TW (missä TW on maakoodi, joka on annettu Taiwanille) tarkoittaa perinteistä kirjoitusjärjestelmää. Maakoodien käyttö perustuu siihen, että Kiinassa käytetään enimmäkseen yksinkertaistettua järjestelmää mutta Taiwanin maakunnassa perinteistä. Jotkin ohjelmat saattavat edelleenkin tukea vain sellaista menetelmää. Loogisempi ratkaisu on käyttää alakoodeja, jotka on erikseen rekisteröity tähän tarkoitukseen: zh-Hans tarkoittaa yksinkertaistettua, zh-Hant perinteistä kirjoitusjärjestelmää. Käytännössä pelkkä zh tarkoittaa yleensä samaa kuin zh-Hans.

Voivatko sanan osat olla eri kieltä?

Kielissä, joissa sanoja taivutetaan, saattaa käydä niin, että vieraskieliseen vartaloon liitetään omakielinen pääte. Tällöin tarkin kielimerkkaus osoittaisi sanan eri osat erikielisiksi, esimerkiksi
Kävin <span lang="fr">Marseille</span>ssa.

Mutta kannattaneeko sanan osille olla kielimerkkaus? Periaatteessa se on oikein, mutta se saattaa käytännössä aiheuttaa ikävän katkoksen puhesynteesissä, jopa sen, että syntetisaattori yrittää lausua pääteaineksen kuten "-ssa" erikseen. Lisäksi syntyy usein hankalia tilanteita:

Hakukoneiden kannalta ongelmana on se, että jotkin hakukoneet (mm. AltaVista) käsittelevät sellaista ilmaisua kuin <span lang="fr">Voltaire</span>n yhtenä sanana (Voltairen), jotkin (mm. Google) kahtena (Voltaire n).

Käytännön neuvo: Vältä vieraiden sanojen taivutusta, sitä enemmän, mitä oudommasta sanasta on kyse. Näin vältetään edellä kuvatut ongelmat. Mihinkään kielenvastaisuuteen ei tietenkään pidä mennä, mutta usein on helppoa muotoilla lauseet niin, että hankala sana saadaan asemaan, jossa se on kieliopin mukaan perusmuodossa. Neuvoon on usein muitakin syitä, kuten se, että taivutetusta muodosta ei lukija aina osaa päätellä, mikä on perusmuoto, ja se, että päätteen merkitseminen on osittain vakiintumatonta. Pitääkö sanoa "Netscapella" vaiko ääntämyksessä käytetyn päätteen mukaisesti "Netscapellä", joka taas oudoksuttaa joitakuita (vaikka onkin ääntämyksen mukainen)? Ongelma vältetään kirjoittamalla "Netscape-ohjelmalla" tai "Netscape-selaimella", jolloin myös kielimerkkaus on helppo kirjoittaa.

Kielitieteessä ja muutoin kieltä kuvattaessa saattaa sananosa esiintyä irrallisenakin, esimerkiksi ilmaisuissa "latinassa esiintyy liitepartikkeli '-que'" ja "the suffix of the inessive case in Finnish is '-ssa' or '-ssä'". Periaatteessa tällöin on oikein merkata niiden kieli erikseen, jos se poikkeaa ympäröivän tekstin kielestä, siis esimerkiksi latinassa esiintyy liitepartikkeli '<span lang="la">-que</span>'.

Teknisiä ongelmia: sisältöä määritteissä

Eräät HTML-merkkaukseen sisältyvät tekstit ovat määritteiden (attribuuttien) arvoja tai muuten sellaisia, että niiden tulee olla pelkkää tekstiä, niin että niiden sisällä ei voi olla merkkausta. Elementtiin saattaisi liittyä esimerkiksi määrite
title="Presidentti Richard Nixon"
Miten voitaisiin ilmoittaa, että määritteen arvon eri osat ovat eri kieltä? Eipä mitenkään. Sama koskee esimerkiksi option-elementin sisältöä, jonka tulee HTML:n määritelmän mukaan olla pelkkää tekstiä. Voimme kyllä kirjoittaa
<option>New York</option>
mutta entäpä jos elementin tekstissä pitäisikin olla kahta kieltä?

Tähän ei siis ole mitään yleistä käytännöllistä ratkaisua. Joskus kyllä ongelma voidaan kiertää käyttämällä HTML:ssä sellaista rakennetta, jossa merkkaus on sallittu; esimerkiksi select- ja option-elementeillä tehty valikko voidaan korvata joukolla input-elementtejä ja niihin liittyviä tekstejä.

Ongelma havainnollistaa sitä, että määritteissä ei pitäisi olla dokumentin sisältöön kuuluvaa asiaa. Teoreettiselta kannalta olen hiukan käsitellyt tätä HTML:n suunnitteluvirhettä kirjoituksessani Empty elements in SGML, HTML, XML, and XHTML, kohdassa Data hidden in attributes.

Eräs tähän liittyvä ongelma on kuitenkin osittain ratkaistavissa, joskin kömpelösti. Joskus määritteen kieli on toinen kuin elementin sisällön. Huomattakoon, että lang-määrite on määritelty niin, että se ilmoittaa elementin sisällön ja määritteiden kielen. Tämä täytynee tulkita niin, että se vaikuttaa myös taaksepäin määritteiden listassa. Esimerkiksi
<a title="HTML 4.01 specification" lang="en">
on tulkittava niin, että lang-määrite vaikuttaa myös sitä edeltävään title-määritteeseen. (Tosin käytännössä kannattaa varmaankin kirjoittaa määritteet toiseen järjestykseen.) Mutta miten menetellään, jos esimerkiksi linkin teksti suomea mutta title-määrite englantia, kuten luonnollista on, jos linkin kohde on englanninkielinen. Tällöin lienee ainoa tapa saada kielimerkkaus täysin oikeaksi se, että elementin sisällä käytetään ylimääräistä merkkausta, jolla sinne saadaan erilainen kielimäärite:
<a lang="en" title="HTML 4.01 specification"><span lang="fi">HTML-spesifikaatio</span></a>

Lisää teknisiä ongelmia: entä kun määritteissä ja sisällössä on eri kieltä?

HTML-spesikaation lang-määritettä koskeva kohta sanoo, että tämä määrite ilmoittaa elementin sisällön ja määritteiden kielen. XML-spesifikaation kuvaus xml:lang-määritteestä esittää samanlaisen periaatteen hiukan toisin sanoin.

Tätä lienee tulkittava niin, että se vaikuttaa myös määritelistassa taaksepäin, joten esimerkiksi
<a href="foo.html" title="Hello world" lang="en">
ilmoittaa, että myös teksti "Hello world" on englantia. Aika näyttää, tulevatko selaimet ja muut ohjelmat toimimaan tämän mukaan. Ei ole vaikeaa kuvitella, että huolimattoman ohjelmoinnin takia tapahtuu toisin.

Tästä seuraa ongelma: Entäs jos meillä on esimerkiksi linkki, jonka linkkiteksti on suomea mutta title-määrite englantia, koska linkki viittaa englanninkieliseen dokumenttiin? Tilanne ei ole mitenkään keinotekoinen, vaan usein on hyödyllistä antaa title-määritteellä vihje siitä, mihin linkki viittaa, ja vihjeen englanninkielisyys on lisävihje. Mutta jos kirjoitamme suomenkieliseen dokumenttiin esimerkiksi
<a href="http://www.faqs.org/rfcs/rfc3066.html" lang="en" title="Tags for the Identification of Languages">RFC 3066</a>
niin silloin kyllä ohjelmille kerrotaan oikein, mikä on title-määritteen kieli (ja tämän ansiosta puhesyntetisaattori voisi lukea sen oikein) mutta samalla väitetään, että merkkijono RFC 3066 on englantia. Tästä taas seuraisi, että puhesyntetisaattori tekisi merkkauksen pohjalta tulkittuna oikein lukiessaan linkin nimen englanniksi, siis suunnilleen "aar ef sii thrii ou siks siks", ja tämä olisi aika häiritsevää.

Jos riski tuntuu todelliselta, niin sen voisi periaatteessa välttää käyttämällä lisämerkkausta, jossa elementin sisällä kerrotaan sisällön kieli:
<a href="http://www.faqs.org/rfcs/rfc3066.html" lang="en" title="Tags for the Identification of Languages"><span lang="fi">RFC 3066</span></a>
Eri asia sitten on, moniko jaksaa niin tehdä. Helpointa tällaisessa tilanteessa on jättää lang-määrite kokonaan pois.

Voiko muu kuin teksti olla jotain kieltä?

Mitä merkitystä voisi olla esimerkiksi HTML:n img-tai object-elementin kielellä?

Aluksi on huomattava, että niille kuville ja muille objekteille, jotka liitetään mukaan kyseisten elementtien avulla, voi olla tekstivaihtoehto, ja yleensä pitäisikin olla. Koska object-elementin tapauksessa vaihtoehto ilmoitetaan elementin sisällössä, jossa merkkaus on sallittu, voidaan kieli ilmoittaa elementin sisällä. Mutta img-elementin tapauksessa tekstivaihto ilmoitetaan alt-määritteellä, joten sen kieli pitää ilmoittaa joko img-tägissä tai sitten sen ulkopuolella.

Lisäksi itse kuva tai objekti voi sisältää tekstiä. Tämä on hyvin ilmeistä, jos objekti on ääni- tai videotiedosto, mutta kuvassakin voi näkyä tekstejä - tai itse kuva voi olla logo tai muu kuvana esitetty teksti. Jos kyse on esimerkiksi äänitiedostosta, ei kielimerkkauksella tietenkään ole merkitystä puhesynteesille, mutta ei toisaalta ole mitään syytä olla ilmoittamatta kieltä. Se on kuitenkin olennaista informaatiota, jolle voi joskus tulla käyttöä.

Kuvalle tai objektille ei tietenkään tarvitse erikseen ilmoittaa kieltä, jos kieli on sama kuin ympäröivän elementin kieli. Mutta jos suomenkielisellä sivulla on vaikkapa sana Google logokuvana, on hyvä käyttää tämäntapaista merkkausta:
<img lang="en" alt="Google" src="google.gif">

Muita erityiskysymyksiä

Sisältö:

Linkin kohteen kieli: hreflang

Edellä mainittiin lyhyesti, että linkkien osalta lang-määrite ilmaisee vain itse linkin kielen ja linkin kohteen kieli voidaan ilmoittaa hreflang-määritteellä. Yleensä on parasta, että linkkiteksti on samalla kielellä kuin dokumentti, johon linkki viittaa, koska tämä antaa lukijalle tai kuulijalle oikean ennakko-odotuksen. Mutta välttämätöntä se ei ole.

HTML:n määrittelyssä ei ole sanottu mitään hreflang-määritteen oletusarvosta, siis ei esimerkiksi sellaista aika luonnollisentuntuista sääntöä, että oletusarvo olisi itse linkin kieli. Käytännössä voisi ehkä lähteä siitä, että ainakaan yksikielisessä dokumentissa ei linkin kohteen kieltä tarvitse ilmoittaa, jos se on sama kuin dokumentin kieli.

Jostakin syystä hreflang-määrite on sallittu vain a-elementeissä eli normaaleissa linkeissä ja link-elementeissä, ei siis area-elementeissä, vaikka nekin ovat luonteeltaan eräänlaisia linkkejä. Määritteen merkitys on hiukan epämääräinen: se ilmoittaa linkin kohteen peruskielen, base language. Käytännössä tämä epämääräisyys ei yleensä haittaa.

MS Word ja kielimerkkaus

MS Word sisältää monenlaista tukea eri kielille. Tosin tuen laajuus riippuu Wordin versiosta ja asennustavasta.

Kun esimerkiksi kirjoitetaan lainausmerkit tavallisen näppäimistön lainausmerkkinäppäintä käyttäen, Word pyrkii korvaamaan lainausmerkin oikealla kielikohtaisella lainausmerkillä. Usein tämä on hyvin hyödyllistä, joskus Word taas on arvannut kielen väärin tai muusta syystä tekee vääriä "korjauksia".

Word sisältää jonkinlaisen automaattisen kielentunnistuksen eli pyrkii kirjoitettaessa tunnistamaan, mitä kieltä teksti on. Tämä piirre voidaan poistaa käytöstä, mutta yleensä se on hyödyllinen. Jos Word on tunnistanut kielen väärin, voidaan "käsin" korjata tieto kielestä, maalaamalla teksti ja valitsemalla Työkalut-valikon Kieli-kohdan kautta haluttu kieli.

Tieto kielestä ilmeisesti tallentuu jossakin Wordin sisäisessä muodossa. Mutta jos leikataan ja liimataan selaimessa näkyvästä HTML-dokumentista tekstiä Wordiin, niin Word tunnistaa sen kielen HTML:ssä olevan kielimerkkauksen mukaiseksi. Siis jos sivulla on esimerkiksi <html lang="fi">, niin Word pitää kielenä suomea, jos taas <html lang="ru">, niin venäjää, jne. Näin riippumatta siitä, mitä kieltä teksti todellisuudessa on, eli Word "uskoo" tekstin venäjäksi vaikka se on latinalaisin kirjaimin ja selvää suomea.

Sama toimii toisinkin päin. Ja se toimii, tavallaan. Riippumatta siitä, onko Word itse tunnistanut kielen vai onko käyttäjä sen kertonut, Word "HTML-muotoon" tallentaessaan kirjoittaa mukaan lang-määritteet tyyliin
<p class=MsoNormal><span lang=FI>Tämä on testi.</span></p>
Vahinko vain, että Wordin tuottama "HTML-muoto" on kokonaisuutena erittäin sekavaa ja sisältää piirteitä, jotka tekevät sen Webiin huonosti sopivaksi. Ja valitettavasti HTML-Kit-ohjelma (tai sen sisältämä Tidy), joka muuten tekee hyvän työn peratessaan sitä moskaa, heittää lang-määritteet menemään pesuveden mukana.

Edellä (kohdassa Muita kielikoodijärjestelmiä) jo mainittiin, että RTF-muotoon tallentaessaan Word tallentaa myös kielitiedon, mutta Microsoftin omia koodeja käyttäen.

Unicoden "kielimerkkaus"

Unicode-merkistö sisältää myös eräänlaisen "kielimerkkauksen". Tämä tarkoittaa, että merkkien tasolla, siis myös esimerkiksi pelkkää tekstiä sisältävässä asiakirjassa, voisi erityisillä ohjausmerkeillä ilmoittaa kielen. Periaatteet on kuvattu UAX #27:ssä, kohdassa 13.7, Tag Characters.

Tämän suhdetta merkkauskielten kielimerkkaukseen käsittelee dokumentin Unicode in XML and other Markup Languages kohta Language Tag Characters, U+E0000 .. U+E007F. Kyseisiä merkkejä käytetään melko vähän, eikä Unicode-standardikaan suosittele niiden käyttöä.

Eräs väärinkäsitys: kielikoodi DOCTYPE-määrittelyssä

Monet Web-sivujen tekijät ovat arvanneet väärin, mitä EN tarkoittaa niin sanotuissa dokumenttityypin määrittelyssä eli HTML-dokumentin alussa olevassa ilmaisussa kuten
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Monet ovat arvanneet, että EN on kielikoodi ja tarkoittaa englantia. Niin se onkin, mutta se ei ilmoita HTML-dokumentissa käytettyä kieltä eikä sitä pidä mennä vaihtamaan toiseksi. Se ilmoittaa, mitä kieltä on käytetty HTML:n (tai yleisemmin: merkkausjärjestelmän) muodollisen kuvauksen yhteydessä, siis itse HTML:n määrittelyssä. Aiheesta kertoo syvällisemmin katsauksen Language Identifiers in the Markup Context kohta SGML.

English summary: language markup in markup systems

The document Kielimerkkaus: tekstin kielen ilmoittaminen merkkausjärjestelmissä (in Finnish) discusses language codes (including ISO 639 codes) in general but especially language markup in markup systems such as HTML and XML, partly in a fairly detailed manner, and emphasizing the accessibility aspect, explaining the related WAI guidelines. Although the principles are simple, there are complicated problems in selecting appropriate markup especially at the phrase and word level, not to mention parts of words. For example, the abbreviation "USA" is clearly of English-language origin; but e.g. in Finnish, it is read using either Finnish letter names or as if it were a Finnish word. Moreover, it is possible that a word in one language takes a suffix from another language. The author recommends that at word level, markup be used to indicate language changes in unproblematic cases only; "if in doubt, leave it out". - As regards documents on language markup in English, the author especially recommends the nice introduction Dan's Web Tips: Languages and more detailed Language Identifiers in the Markup Context. For a deeper discussion, see the W3C working draft Authoring Techniques for XHTML & HTML Internationalization: Specifying the language of content.


Kirjoittamisen ajankohta: 2002-06-23. Päivitetty viimeksi 2007-12-03. Teknisiä korjauksia 2017-12-11.
Tämä sivu kuuluu Jukka "Yucca" Korpelan avoimeen tietosivustoon Datatekniikka ja viestintä.