Lue myös kaksiosaisen artikkelisarjan ensimmäinen osa: Kieli URL:ssä.
URL-osoitteiden hallinta on www-sivuston, julkaisujärjestelmän tai web-frameworkin avainkohtia. Joskus URL:ssä on tarve näyttää dokumentin kieli. Koska ja miksi?
Kieli URL:ssä on tarpeeton, jos sivusto ei tarjoa sisältöä kuin yhdellä kielellä. Sitä ei sinne kannata varmuuden vuoksi laittaa, vaikka sisältö joskus tulevaisuudessa saattaa laajentua. Kaikki ylimääräinen URL:ssä lisää osoitteiden monimutkaisuutta ja mitä monimutkaisempi URL, sen vaikeakäyttöisempi.
Sisältöneuvottelu
HTTP:n Content Negotiation, sisältöneuvottelu, on tekniikka, jolla voidaan vaikuttaa siihen, mikä versio sisällöstä tarjoillaan User-Agentille eli yleensä selaimelle ja sitä kautta käyttäjälle.
Tyypillisimpään tapaan, palvelinpäässä suoritettuna Content Negotiation mahdollistaa kielivalinnan tekemisen HTTP-pyynnön otsikkotiedon perusteella, niin että samasta URL:stä voi vastata monta eri käännöstä samasta dokumentista. Tällöin käyttäjä ei välttämättä voi tehdä kielivalintaa itsenäisesti, vaan näytettävä sisältö riippuu hänen selainasetuksistaan.
Toinen vaihtoehto on tarjota jokaiselle käännökselle oma URL. Etusivulla tarjotaan kielivalikko.
Kolmas vaihtoehto on yhdistää nämä kaksi. Jokaisella dokumentilla on yksi kanoninen URL. Kun tuota osoitetta pyydetään, tehdään palvelinpäässä valinta näytettävästä kielestä Accept-Language-headerin ja kielivalikoiman perusteella. Lisäksi näytetään dokumentissa linkkeinä kaikki sen käännökset.
Kolmas vaihtoehto kulostaa tietenkin järkevimmältä. Mutta ongelmia silti tulee, kun aletaan miettiä yksityiskohtia.
Toinen vaihtoehto automaattiseen sisältöneuvotteluun on IP-osoite.
Kielen ja maan tunnistaminen IP-osoitteesta
Google vaikuttaa todenneen, että se pääsee käyttäjien kieliasetuksia parempaan osumatarkkuuteen tunnistamalla käyttäjän maan valtakielen IP-osoitteen perusteella. Tämä lisäksi se tarjoaa etusivullaan monikielisen maan muita kieliä ja aina mahdollisuutta siirtyä englanninkieliselle sivustolleen.
Tämäkään lähestymistapa ei ole vailla ongelmia, koska ihmiset matkustavat. Osoite siis toimii paremmin maavalintana kuin kielivalintana. IP-osoitteista tarvitaan jatkuvasti päivittyvä tietokanta, jonka käyttäminen maksaa — jos ei muuten niin ohjelmointityönä ja prosessorisykleinä. IP-osoitteen mukaan vaihtelevaan sisältöön viittaaminen on ihan yhtä vaikeaa kuin HTTP-otsikkotiedon mukaan vaihteleva.
Kaikista sivuista ei ole käännöstä
Monikielinen verkkosivusto on harvoin täydellisesti käännetty kaikille kielilleen. Useimmiten toisiaan vastaavia sivuja on vain kourallinen. Tyypillisesti tällainen on etusivu, mutta sivuja voi olla muitakin. Tällaisella sivustolla sisältöneuvottelua voidaan käyttää vain sivuilla, joista on useampia käännöksiä.
Varsinkin, kun useimmista sivuista ei ole käännöstä, tuntuu kielikoodin kuljettaminen URL:ssä varsin raskaalta ratkaisulta. Toisaalta, jos käännettyjä sivuja on merkittävä osa, ei kielikoodin satunnainen näkyminen URL:ssä ole kovin käyttäjäystävällistä sekään. Voi olla aika vaikea määritellä rajoja, milloin sivuja on niin paljon, että kielikoodin kannattaisi olla pysyvästi näkyvissä.
Jos sivun osoitteessa näkyy kielikoodi, tarkoittaa se useimpien mielestä, että sivulle päästäkseen se on myös näpyteltävä, eli ei auta, että osoite toimii ilmankin kielikoodiakin. Mitä vaikeammin näpyteltävä osoite, sen turhautuneemmat käyttäjät.
Miten sivun kieliversioon linkitetään?
Semanttisin keino linkittää saman dokumentin toiseen kieliversioon löytyy HTML 5 -spesifikaatiosta:
If the alternate keyword is used with the hreflang attribute, and that attribute’s value differs from the root element’s language, it indicates that the referenced document is a translation.
Eli: <a href="/en" rel="alternate" hreflang="en">In English</a>. Näin linkitettynä voidaan helposti ohjelmallisesti päätellä dokumenttien välinen suhde.
Tällainen linkittäminen menee jo normaalin sisällöntuottajan osaamistason ulkopuolelle, joten käytettävän järjestelmän soisi mahdollistavan eri kieliversioiden assosioinnin ja sitä kautta linkityksen oikein tekemisen ilman oikeiden attribuuttien ulkoa opettelua.
Sisältöneuvoteltu sivu ei kerro normaalikäyttäjälle mitenkään, että sivu on sisältöneuvoteltu. Näin ollen hän ei voi tietää, että sisältö on riippuvainen osoitteen lisäksi myös selainasetuksista. Tehdessään linkkiä sivuun tavallinen käyttäjä voi hämääntyä, koska toisella koneella linkkiä klikkaaja saattaakin joutua ihan eri sivulle. Tämä on pieni, mutta selkeä käytettävyysongelma.
Yksi sisältö, yksi osoite
Nyt pääsemme sisältöneuvottelun kimuranteimpaan ongelmaan: Hakukoneoptimoinnin perusteita on, että yhdelle sisällölle tulisi olla vain yksi osoite. Miten voisimme kertoa googleille sisältöneuvottelevamme?
Content-Location
HTTP tarjoaa yhden tavan kertoa mikä on kanonisesta URL:stä palvellun sivun oma URL: Content-Location. Sillä on kuitenkin sivuvaikutus, koska jos sen asettaa, tulisi sisällön base URL:n muuttua kentän osoittaman URL:n mukaiseksi. Varsinkin, jos kieli on URL:n polun alussa tai muuten vain eri syvyydellä URL:n hierarkiassa, voivat sivun linkit rikkoutua riippuen mistä osoitteesta sitä näytetään. Useimmat selaimet eivät tätä sivuvaikutusta kuitenkaan tue, joten se on melko hyödytön.
Esimerkiksi klassinen Cool URIs don’t change -dokumentti asettaa kanonisessa muodossaan kutsuttuna Content-Location-kentän, oletettavasti Apachen vakio-ominaisuuden avulla.
Web-palveluiden rakentajain raamattu, RESTful Web Services sanoo, että Content-Location-kenttää tulee käyttää osoittamaan kanoninen URL, kun jotain tiettyä dokumentin versiota on pyydetty. Lähetin kirjoittajille palautetta, koska HTTP-spesifikaatio sanoo juuri päinvastoin ja Apachekin näyttäisi toimivan toisin. Se, että vähäinenkin tieto aiheesta on näinkin ristiriitaista ei puhu paljon kentän käyttämisen puolesta.
Jos julkaisujärjestelmä takaa, että polku on kullakin kieliversiolla samanmittainen, voi Content-Locationin turvallisesti asettaa. Muuten se vaikuttaisi olevan kokolailla turha. Koska koko kenttä on varsin harvinanen, olettaisin ettei Google sitä hyödynnä. Oikeaa tietoa asiasta olisi tietysti kiva olla.
Jos sisältöneuvottelu ei käytännössä toimi, mikä neuvoksi?
Koska mitään varmaa keinoa kertoa kertoa eri versioista ei ole ja koska jo pelkkä linkittäminen menee hankalaksi normaalikansalaiselle, en voi mitenkään olla sisältöneuvottelun kannalla. Miten monikielisen sivuston sitten pitäisi toimia? Tässä kaiken edellisen tietämyksen perusteella johdettu malli:
- Päätetään sivuston pääkieli.
- Etusivu (sivuston juuri) näytetään pääkielellä.
- URL:t pääkielellä eivät sisällä kielikoodia
- Kielikoodi on kaksimerkkinen, mikäli suinkin mahdollista
- Etusivu linkittää eri kieliversioihinsa, esimerkiksi /en, /sv, semanttisesti oikein.
- Alasivut linkittävät kieliversioihin niiltä osin kun vastaavuuksia on ja voi järjestelmällä ilmaista.
- For extra points: Jos User-Agent pyytää kielispesifistä osoitetta joka ei ole hänen primäärinen Accept-Language-kielensä, voidaan kielivaihtoehtoja tuoda käyttöliittymässä normaalia suuremmalla huomioarvolla näkyviin. Eräänlainen sisältöneuvottelu sekin.