[ALG] Meertalig website: welke setup?

[Verwijderd]

Als je een meertalige website wilt hebben, kun je de URI op meerdere manieren indelen:

• www.website.<land>, bijvoorbeeld www.website.nl, www.website.de
• <land>.website.com, bv. nl.website.com, de.website.com
• www.website.com/<land>, bv. www.website.com/nl, www.website.com/de

Kan iemand iets zeggen (of verwijzen naar een goed artikel) over de meest gebruikte manier indeze? Of zijn er nog andere opties?

Een vriend van mij heeft een stijldans-website, en vroeg of de site (onder Wordpress) ook meertalig kon. Natuurlijk kan dat, maar ik vraag me dus af welke conventie voor de hand ligt.

Als ik de eerste methode even buiten beschouwing laat (niet iedereen wil / kan voor elke taal een apart domein aanschaffen, vaak ook al geregistreerd door anderen), dan is voor beide laatste methoden iets te zeggen:

• als je iemand een link stuurt, bv. http://nl.website.com/producten/fruit/peren.htm dan kun je Apache laten checken of de huidige client als default taal ook nl-nl ingelsteld heeft staan. Is dat niet het geval, maar bv. de-de, dan kun je redirecten naar de.website.com/producten/fruit/peren.htm
• aan de andere kan kan dat natuurlijk ook met website.com/nl/producten/fruit/peren.htm en waarschijnlijk moet de URL toch ook vertaald worden: website.com/de/produkten/frucht/peer.htm

Kan iemand hier nog iets aan toevoegen? Wat wordt het meest gebruikt en waarom?

[Lourini]

Een nieuw .xx domein gaat geld kosten...
Een subdomein of een map in het reeds bestaande domein is gratis
Zou zelf bij goed niet weten wat het beste/meest gebruikte is.

Enige voordeel van een heel nieuw domein is waarschijnlijk het dataverkeer, je hebt dan zeg maar niet 2/3 sites op 1 domein draaien

[SinergyX]

?lang=nl ?laat=nl zie ik ook nog gebruikt worden, het maakt allemaal niet zo uit. Je kan elke variatie van de URL's laten opbreken en checken of het de juiste taal is, desnoods dan doorsturen. (zoals dit forum ook gebruikt, de parameters naar /<etc>/<etc> urls zetten).

Voordeel van de <land>domein.com en www.domein.<land> dat je dus ook je email wat makkelijker per taal kan laten gaan, wat in geval van domein.com/<land> niet zo gemakkelijk gaat.

Lourini schreef op woensdag 25 november 2009 @ 18:58:
Een nieuw .xx domein gaat geld kosten...
Een subdomein of een map in het reeds bestaande domein is gratis

Er zijn helaas nog steeds hostingbedrijven die doodleuk geld vragen voor subdomeinen.

Maar, om hoeveel talen gaat het? Beetje 'internationale' site is meestal al klaar met engels, duits, frans en nederlands, mischien links en rechts nog spaans ofzo erbij, qua domeinen valt dan wel mee per jaar. Zelf vind ik de <land>domein.com de fijnste om mee te werken.

•als je iemand een link stuurt, bv. http://nl.website.com/producten/fruit/peren.htm dan kun je Apache laten checken of de huidige client als default taal ook nl-nl ingelsteld heeft staan. Is dat niet het geval, maar bv. de-de, dan kun je redirecten naar de.website.com/producten/fruit/peren.htm

Ga aub geen 'client language' check doen, dit gaat vaak mis en is mi overbodig. (maw laat de gebruiker gewoon kiezen).

[ Voor 72% gewijzigd door SinergyX op 25-11-2009 19:02 ]

[!GN!T!ON]

www.website.<land>, bijvoorbeeld www.website.nl, www.website.de

dit lijkt me een beetje een dure oplossing, omdat je kan voor elke taal een nieuwe TLD moet huren/kopen,

zelf zou ik gaan voor de nl.website.com en dan op www.website.com gewoon een lijstje met talen/landen en of internationaal (dus www.website.com/int ofzo)

[Stoffel]

Verwijderd schreef op woensdag 25 november 2009 @ 18:54:

• als je iemand een link stuurt, bv. http://nl.website.com/producten/fruit/peren.htm dan kun je Apache laten checken of de huidige client als default taal ook nl-nl ingelsteld heeft staan. Is dat niet het geval, maar bv. de-de, dan kun je redirecten naar de.website.com/producten/fruit/peren.htm

Waarom zou je de taal überhaupt in de url zetten? Laat ofwel de gebruiker ofwel het systeem gewoon bepalen welke taal het meest relevant is, per gebruiker. Wie weet wil ik een Engelstalige kennis wel een link sturen naar een artikel dat ik in het Nederlands lees, moet ik dan gaan gokken welke url ik ga sturen?

[sanzut]

Over de kosten, het lijkt me niet dat wij daar wat zinnigs over kunnen zeggen, je weet immers niet over wat voor project je het hebt, en een domain an-sich is in verhouding waarschijnlijk een peule schil als je het kan veroorloven om je posts etc professioneel wil laten vertalen naar het engels/duits/whatsoever.

Mocht je van plan zijn om het zelf te gaan vertalen, zet het idee dan aub snel in de ijskast, want de buitenlandse bezoekers lachen zich waarschijnlijk een breuk...

edit: eerste zin aangepast naar je = wij.

[ Voor 5% gewijzigd door sanzut op 25-11-2009 19:06 ]

[Matis]

Alle grote websites hebben gewoon een .com domein. Waar middels de argumenten in de url de keuze per land bepaald wordt

http://www.microsoft.com/en/us/default.aspx
http://www.google.com/webhp?hl=nl

etc.

[Jrz]

Stoffel schreef op woensdag 25 november 2009 @ 19:01:
[...]


Waarom zou je de taal überhaupt in de url zetten? Laat ofwel de gebruiker ofwel het systeem gewoon bepalen welke taal het meest relevant is, per gebruiker. Wie weet wil ik een Engelstalige kennis wel een link sturen naar een artikel dat ik in het Nederlands lees, moet ik dan gaan gokken welke url ik ga sturen?

caching?
seo?

[ameesters]

ik zou voor de "onzichtbare" optie, bij deze hou je gewoon je www.website.tld aan, maar als een bezoeker op een vlaggetje klikt(wat meestal gebruikelijk is) wordt dit in een cookie opgeslagen, dus als die gene terug komt is de taal automatisch geladen...
zo hoef je geen rare trucks met urls te doen....

dat kan je dan op meerdere delen van de site ook hergebruiken zodat als er van een artikel een nederlandse en een engelse versie is er 2 vlaggetjes staan....

zo kan een nederlander dus een linkje naar een engelsman sturen en dan kan de buitenlander op het vlaggetje klikken...

daar zou ik voor gaan...

[Stoffel]

Jrz schreef op woensdag 25 november 2009 @ 19:09:
[...]

caching?
seo?

SEO is wel een punt, al denk ik dat Google aan de hand van de tekst ook wel kan bepalen welke taal het is.

Waarom zou caching niet mogelijk zijn zonder een taal in de URL volgens jou?

[Sebazzz]

Tip: Je zegt wordpress. Wordpress heeft ook taalplugins, zoiets heb ik ook gebruikt op mijn eigen website.

[mocean]

Stoffel schreef op woensdag 25 november 2009 @ 19:14:
[...]


SEO is wel een punt, al denk ik dat Google aan de hand van de tekst ook wel kan bepalen welke taal het is.

Waarom zou caching niet mogelijk zijn zonder een taal in de URL volgens jou?

Ik doe de taalswitch ook met cookies/sessions. Maar vraag me af of Google dat snapt. Op elke pagina staat dan de link naar de Engelse taal. Maar als de bot verder spidert springt ie weer naar Nederlands (als de bot geen cookies accepteert, misschien is dat wel zo). Maar goed, ik target niet op visits via Google, weet niet of dat voor de TS van belang is.

[Verwijderd]

mocean schreef op woensdag 25 november 2009 @ 20:17:
[...]
Maar goed, ik target niet op visits via Google, weet niet of dat voor de TS van belang is.

Misschien wel zo handig om even te vermelden: ik houd voor een aantal organisaties (2 scholen, een danswebsite, een studievereniging) een websiteje bij. Telkens als er een vraag van de gebruikers komt, update ik de codebase (met standaard modules of eigen werk). Nu komt er dus een vraag voor multilingual sites. Ik kijk nu hoe ik dat zou kunnen implementeren; ik kijk dus niet naar wat getarget moet worden

Matis schreef op woensdag 25 november 2009 @ 19:04:
Alle grote websites hebben gewoon een .com domein. Waar middels de argumenten in de url de keuze per land bepaald wordt

http://www.microsoft.com/en/us/default.aspx
http://www.google.com/webhp?hl=nl
etc.

Google klopt niet helemaal, want zij hebben ook voor nagenoeg elk land een eigen tld. Het klopt inderdaad wel dat er grote bedrijven zijn die met website.com/<taal> werken. Apple is hier een goed voorbeeld: http://www.apple.com/choose-your-country/

SinergyX schreef op woensdag 25 november 2009 @ 18:59:
[...]
Ga aub geen 'client language' check doen, dit gaat vaak mis en is mi overbodig. (maw laat de gebruiker gewoon kiezen).

Dat is een goede opmerking. Bij deze aangenomen

leipepo schreef op woensdag 25 november 2009 @ 19:11:
ik zou voor de "onzichtbare" optie [..] zo kan een nederlander dus een linkje naar een engelsman sturen en dan kan de buitenlander op het vlaggetje klikken...

Maar dan weer, hoe vaak komt dat nou voor? Ik neem aan dat de meeste mensen die je kent dezelfde taal als jezelf spreken?

mocean schreef op woensdag 25 november 2009 @ 20:17:
Ik doe de taalswitch ook met cookies/sessions. Maar vraag me af of Google dat snapt.
[...]
(als de bot geen cookies accepteert, misschien is dat wel zo). Maar goed, ik target niet op visits via Google,

Voor zover ik weet accepteert de bot geen cookies.

Ik twijfel nu tussen website.com/<taal> en de cookie oplossing. Hoewel het een goed argument is dat je wel <taal>.website.com email adressen aan kunt maken, kun je die ook algemeen ([e-mail]) houden.

Ik moet eens uitzoeken hoe het met de SEO van <taal> in de URL zit en hoe het opnemen van <taal> past is de hele filisofie van goede URLs (onder andere http://www.w3.org/Provider/Style/URI).

[Soultaker]

Persoonlijk zou ik er voor kiezen om per taal (of eventueel regio/taal) een aparte url-prefix te reserveren bij het hoofddomein. Dus b.v. http://www.example.com/en/ voor Engels en http://www.example.com/nl/ voor Nederlands. Op het hoofddomein kun je dan de gebruiker doorsturen naar de juiste taal op basis van de browsersettings, of by default naar Engels, of de gebruiker expliciet laten kiezen, afhankelijk van wat je het mooist vind.

Taalvoorkeur in een cookie (of sessie) zetten lijkt me een slecht idee omdat je dan verschillende content onder dezelfde url aanbiedt, terwijl die pagina's eigenlijk helemaal niet dynamisch (hoeven te) zijn. Zoals al aangegeven is dat niet handig voor search engines, maar ook niet voor andere zaken als bookmarks (die immers langer leven dan cookies) of als mensen links willen uitwisselen (als ik de url copy/paste in een e-mail of im-bericht, dan is de taalvoorkeur verdwenen). Vandaar dat de taalvoorkeur onderdeel van de URL maken beter is.

Tenslotte denk ik dat een serieus groot bedrijf er niet aan ontkomt om ook extra domeinen in landen waar het bedrijf actief is te registreren. Voor een kleinere website is dat wellicht wat teveel moeite, maar gebruikers denken niet in tld's. Als een Nederlander iets van Microsoft wil weten is de kans groot dat 'ie naar microsoft.nl surft. (En die redirect dan weer naar http://www.microsoft.com/nl/nl/, het hoofddomein, met taalvoorkeur in de url.)

[Macros]

Ik ben het met niemand eens. Je hoeft de taal helemaal niet in de url, cookie, session of domein te zetten. Er is namelijk gewoon een locale http header die je browser altijd meestuurt. (Firefox: Extra -> Opties -> Inhoud -> Talen (Kiezen)) Daar kan je een lijstje met talen opgeven. Die allemaal mee worden gestuurd, en de webapplicatie kan die gewoon uitlezen en bepalen welke taal hij moet tonen. Wordt een taal niet ondersteund, dan kiest hij de volgende. Worden ze allemaal niet ondersteund, dan neemt hij de default taal. Dit werkt allemaal out of the box in Java web applicaties.
Alleen als een gebruiker een andere taal wilt kiezen dan staat ingesteld in zijn browser moet je dat ergens opslaan, dan zou ik dat in een cookie doen, of gekoppeld aan de gebruikers informatie als dat wordt opgeslagen (in een database). Maar dat lijkt me 95 van de 100 keren niet nodig. Ook heb je natuurlijk (zoals Google doet), de optie om iets tijdelijk te doen in een andere taal. Maar lijkt me niet dat dat een permanent opgeslagen instelling moet zijn.

Dat veel websites het in de url zetten of je expliciet laten kiezen komt 9 van de 10 keer omdat ze niet beter weten.

[Simon Verhoeven]

Ik zou eerder zeggen dat dat eerder is omdat het vaak misloopt dan omdat ze niet beter weten.
Zelf ben ik ook eerder voor een vlagje om de taal te kiezen.
Of je nu voor www.naam.nl/en/ of www.en.naam.nl gaat is wat je eigen keuze.
Zelf ben ik eerder voor www.naam.nl/en/ omdat het simpeler te onthouden is.
Als ze www.naam.nl/english/ ingeven kan je nog zelf bepalen waar ze belanden, doen ze www.englishnaam.nl dan belanden ze ergens anders.

[McVirusS]

Macros schreef op woensdag 25 november 2009 @ 20:47:
Dat veel websites het in de url zetten of je expliciet laten kiezen komt 9 van de 10 keer omdat ze niet beter weten.

Onzin, een URL moet gewoon een unieke identifier zijn voor een pagina. Dus moet niet zo zijn dat als je met een andere client naar dezelfde URL gaat je dan een andere pagina te zien krijgt. Je moet die gegevens natuurlijk wel gebruiken bij het automatisch uitkiezen van welke variant van de website je te zien krijgt.

Ik zou sowieso alle land TLD's registreren en die doorsturen naar de hoofd taal variant van dat land (als er geen hoofdtaal is zoals bijvoorbeeld in Canada zou ik een keuzescherm tonen of inderdaad de taal uitlezen van browser). Voor de website kan je dan gewoon www.domein.com/locale gebruiken, zoals bijvoorbeeld www.domein.com/nl-us/ voor Nederlandse bezoekers met Engelse taal variant.

Er is namelijk een verschil tussen land en taal. Je kan prima de Nederlandse variant van een site hebben maar wel in het Engels (bijvoorbeeld met alleen assortiment wat in Nederland te krijgen is voor mensen die in NL wonen maar geen NL spreken/lezen). Dus je kan meerdere taalvarianten per land(versie) hebben. Vandaar de keuze voor locale.

Dat lijkt mij officieel gezien de meest nette oplossing.

Als er alleen taalvarianten zijn en geen landvarianten dan zou ik alleen de taal gebruiken. Dus www.domein.com/en/ voor Engels. Dan voorkom je ook duplicated content (voor Google, krijg je strafpunten voor).

[ Voor 5% gewijzigd door McVirusS op 25-11-2009 21:03 ]

[Cartman!]

Moet er niet aan denken dat voor gebruiker A de pagina nederlands is en voor gebruiker B de pagina engels bij een gelijke url, wat een slecht idee.

Ik ga mee met Macros, checken of er in de url een taal verstopt zit en zo ja, gebruik die. Is die taal er niet in de url? Dan kun je kiezen om de gebruiker dit te laten kiezen of door de http_accept_language te checken, als je die beschikbaar hebt pak je die en zoniet dan de default

En zoals mn bovenbuurman zegt, het netst is eigenlijk om taal en locale mee te geven ipv. alleen taal maar niet elke site heeft dat ook daadwerkelijk nodig. Overigens is het kiezen van taal adhv. een vlaggetje van en land een heel slecht idee, daar is laatst al uitgebreid over gediscussieerd (kan t ff niet vinden alleen).

De kosten voor een domeinnaam vind ik echt een non-argument, de kosten van en domeinnaam zijn echt een fractie van de kosten van de totale website (in een normale situatie). Als die paar tientjes per jaar het probleem al zijn dan hoef ik voor iemand al geen website meer te maken

[TeeDee]

Hieronder zoals wij onze site hebben ingericht. Voldoet een stap: stop met doorneuzelen en biedt de content aan.

1. Kijk in de url of er een 'taal' parameter is. (domain.tld/index.html?lang=nl of domain.tld/nl/ bijvoorbeeld)
2. Is er een cookie (expliciet geset door de gebruiker bij een vorig bezoek)
3. Kijk naar de http accept language
4. Default naar de taal van je doelgroep

Bij alle 4 de opties sturen we de bezoeker naar domain.tld/taal/index.html. Bijvoorbeeld links doorsturen (domain.tld/taal/gerse-pagina.html) gaat op dezelfde manier waarbij je automatisch weer bij stap 1 aankomt.

Wat betreft ook de locales doorsturen/controleren is inderdaad een goede optie, mits het in je doelgroep past. Heb je bijvoorbeeld veel belgische bezoekers, kan ik me voorstellen om duidelijk te wezen en nl-be en fr-be te verwerken in je url's.

Het 'vlaggetje' gebruiken om een taal te kiezen is nog steeds één van de meest duidelijke opties om meerdere talen aan te bieden, maar zoals Cartman! zegt is er een initiatief om dit met 1 enkel icon te doen. Punt is wel dat dit gedragen moet worden. Hell, veel mensen weten nog niet eens wat een RSS icon inhoudt.