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
”.
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.
HTML 4:n määrittelyn kohta Language information and text direction mainitsee seuraavat syyt käyttää kielimerkkausta (selitykset minun):
q
-elementtiin, joka
on toistaiseksi sangen huonosti toteutettu. Lisäksi sillä ei oikeastaan
saavuteta mitään, koska voihan sivuntekijä itse valita kielenmukaiset
lainausmerkit kuten muutkin välimerkit.
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ä:
- 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ä].
- 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].
- 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ä.
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.
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.
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.
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.
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.
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.
lang
-määritexml:lang
-määritelang
-määriteHTML: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.
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:
hreflang
-määritteellä, jota käsitellään
tarkemmin myöhemmin.
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:lang
-määriteXML: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.
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
(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-tiedostomuoto on eräänlainen merkkauskieli, joka useilla tavoilla muistuttaa HTML:ää. Siinä on käytössä kolme kieleen liittyvää merkkausta:
\deflangnnnn
\deflangfennnn
{langnnnn tekstiä}
Tässä nnnn on luku, joka ilmaisee kielen. RTF:ssä ovat käytössä erityiset numeeriset kielikoodit.
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.
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ä.
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):
ar
en
es
nl
it
ja
zh
el
la
se
pt
fr
sv
de
fi
ru
et
.
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.
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.
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.
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.
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
).
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.
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).
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.
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.
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.
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".
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ä.
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:
x-
-alkuista koodia.
Toisaalta voidaan käyttää kielikoodia mis
, joka
on tarkoitettu kielille, joilla ei ole omaa koodia ja joita
ei voida ilmaista myöskään kieliryhmäkohtaisilla koodeilla
(kuten fiu
, joka tarkoittaa niitä suomalais-ugrilaisia
kieliä, joilla ei ole omaa koodia).
lang
-määritteen oletusarvo
on "unknown". Toinen tapa tulkita määrittelyä
on, että oletusarvona olisi, että sisältö on tuntematonta kieltä
edellä kuvatussa merkityksessä.
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ä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 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.
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:
<p>Mielikirjailijani
on <span lang="ru">Dostojevski</span>.</p>
<p>Luen mielelläni <span lang="ja">manga</span>-sarjakuvia.</p>
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.
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 |
---|---|---|
龥 | 龥 | ei ilmoitettu |
<span lang="zh">龥</span> | 龥 | kiina (yksinkertaistettu kirjoitusjärjestelmä) |
<span lang="zh-Hant">龥</span> | 龥 | kiina (perinteinen kirjoitusjärjestelmä) |
<span lang="ja">龥</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
.
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:
<span lang="fr">Voltaire</span>n
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>'
.
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>
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.
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">
hreflang
DOCTYPE
-määrittelyssä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 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.
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öä.
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.
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.