Share
Å tilby innhold på flere språk kan legge til mange nye lag av kompleksitet til webdesign. Oversette artikler er bare den første hindringen; strukturere en flerspråklig nettside kan være ganske vanskelig. For å hjelpe deg med å få det riktig, skal jeg tilby noen tips, og dele noen av våre erfaringer på Tuts + for å gå flerspråklig.
Det første tipset er ikke veldig relatert til webdesign, men det er viktig likevel. Når du tilbyr innhold på flere språk, er det best å ikke stole på oversettelsessoftware. Gjør meg ikke feil, verktøy som Google Translate er enkle å bruke og stadig forbedrer, men nøyaktigheten av den oversatte teksten varierer (vi har til og med falt av dette på Tuts + til og med!)
Initiativer som Google Translate-fellesskapet forfiner hvordan oversettelser gjøresAv denne grunn er det en god ide å få en menneskelig oversetter. Enten velge en betalt tjeneste som Fliplingo, eller (avhengig av prosjektet ditt) bruker community-driven oversettelse plattformer som Native. Mennesker har bedre kunnskap om lokalt ordforråd og de subtile nyanser av språk. På tidspunktet for skriving har automatisert programvare ikke nådd det punktet.
På Tuts + har vi våre lesere å takke for å oversette våre opplæringsprogrammer.
Et flerspråklig nettsted er ubrukelig uten muligheten til å endre språk. Ofte vil du finne flerspråklige nettsteder bruke en rullegardin, plassert øverst til høyre på siden (for venstre til høyre innhold øverst til venstre er mer egnet). Du kan også finne svitsjere i footer (tilnærmingen som IBM.com velger). Uansett hvilket mønster du går for, sørg for at rullegardinmenyen er lett å se og få tilgang til.
På Tuts + bruker vi en å velge element i post-meta-detaljene, pluss en liste i sidefeltet for å sikre at basene er dekket:
Hvis du velger å bruke et valgelement, anbefaler W3C noen nyttige retningslinjer.
Flagg brukes ofte til å angi et språk. Jeg er imidlertid enig med Gunnar Bittersmann, fordi jeg ikke er en stor fan av å bruke flagg for språkbrukerne. Vurder følgende grunner:
For eksempel:
https://www.duolingo.comDuolingo forsvarer bruken av det brasilianske flagget fordi de lærer brasiliansk portugisisk. Men deres variant av spansk er nærmere latinamerikansk spansk enn Castellano (tradisjonell spansk), så bruken av flagg her er inkonsekvent og forvirrende.
Det er best å referere til et språk på sitt eget språk, for eksempel "Deutsch" i stedet for "Tysk". Å bestille språk alfabetisk vil også hjelpe, slik at brukerne enkelt kan finne den riktige versjonen. Ta en titt på sidenavnet til Wikipedia for inspirasjon.
Enkelte nettsteder omdirigerer brukerne til hjemmesiden når de bytter språk. Dette kan være forvirrende fordi brukere må finne siden igjen. For å holde dine besøkende lykkelige, sørg for at de presenteres med samme side som oversatt når de bytter språk.
Vil du angi et standard språk for første gangs besøkende? Det er mulig å oppdage brukerens språk og automatisk vise siden på brukerens foretrukne språk. Ikke skjul de andre alternativene, hvis brukeren ønsker å bytte.
Les mer på Smashing Magazine: Skal du spørre brukeren eller deres nettleser?
Innholdet ditt må være lesbart, så sørg for at tegnkodingen i hodet på siden er riktig angitt:
Fra W3C:
"En Unicode-basert koding som UTF-8 kan støtte mange språk og kan huse sider og skjemaer i hvilken som helst blanding av disse språkene."
Tenk så på de faktiske skriftene: Din web skrifttype må være kompatibel med alle språkene du støtter, spesielt for ikke-latinske baserte språk. Dette betyr at skrifttypen som brukes må inneholde alle tegnene og glyphene du vanligvis trenger. Noen språk består av hundrevis av tegn, noe som gjør skrifttypefilene selv svært tunge. Vurder derfor å raffinere tegngruppene du inkluderer i filene.
Det finnes flere nettsteder som tilbyr ikke-latinske tegnbaserte fonter, for eksempel typebank.co.jp, og et raskt Google-søk vil hjelpe deg med å finne flere alternativer.
https://www.typebank.co.jpDet er også andre typografiske hensyn. Ikke glem at enkelte språk er mer "wordy" og derfor ta opp mer plass. En knapp 'legg i handlekurven' kan bli oversatt til nederlandsk til 'aan winkelwagen add'. Den engelske versjonen består av 11 tegn, den nederlandske versjonen 25, og tar opp dobbelt så mye plass. Når plassen er liten, kan du prøve en annen, mindre bokstavelig oversettelse, eller endre skriftstørrelsen basert på språket.
Andre ikke-latinske skrifter kan trenge en annen linjehøyde, eller tegnstørrelse, til din latinske standard. Kinesiske tegn, for eksempel, er visuelt mer komplekse enn latinske tegn, noe som betyr at de må være store nok til tydelig forskjell. Disse faktorene kan i stor grad endre utseendet på siden, så hold dem i tankene.
Her er noe du kanskje ikke er oppmerksom på: språk har ikke retning, men manus de er skrevet i gjør. For eksempel kan Azeri (talt av Aserbajdsjan) skrives ved hjelp av latinske eller kyrilliske skript, i så fall er det skrevet LTR (venstre til høyre). Alternativt kan det skrives i arabisk skript, i så fall er det skrevet RTL (høyre til venstre).
De fleste språk bruker skript som er skrevet og leset fra venstre til høyre, men hvor det ikke er tilfelle, er det nyttig å speile oppsettet på hele nettsiden. Ja, hele oppsettet. Tekst, bilder, navigasjon, sidebars, knapper, dropdowns, rullefelt ... skal alle bli speilet.
Tom Maslen forklarer hvordan BBC-teamet bruker Sass til å hjelpe dem med toveisformater:
For innhold, angi retningen av teksten via dir = "RTL" Egenskap. Dette attributtet støttes av alle de store nettleserne. Her er et HTML-eksempel:
Eller bruk CSS:
.innhold retning: rtl; /* Høyre til venstre */
En gotcha vi oppdaget på Tuts +, var å legge inn inline kodebiter innenfor RTL-tekst (som på arabisk, persisk og hebraisk oversettelse). Teksten leser RTL, men inline-koden må forbli LTR. I dette eksemplet må inline-koden alltid leses html, kropp bredde: 100%; :
Etter den engelske originalen kan du se hva som skjer med inline-koden i det andre eksemplet. Eksempel 3 prøver å overstyre det ved å spesifisere:
.arabisk kode retning: ltr;
men som du ser, har den liten eller ingen effekt. Det er her unicode-bidi Eiendommen kommer inn. Paret med embed verdi, hjelper dette oss med å overstyre nettleserens beregnede retning for innebygde elementer. Eksempel 4 demonstrerer at dette har arbeidet:
.arabisk kode retning: ltr; Unicode-Bidi: Embed;
Det er flere måter å strukturere nettadressene til flerspråklige nettsteder på. Hvert alternativ har fordeler og ulemper.
Et landskoder på toppnivå domene (ccTLD) er knyttet til et bestemt land, for eksempel .fr for Frankrike og .es for Spania.
ccTLDs er et klart signal for søkemotorer at et nettsted er rettet mot brukere i det landet. Serverplasseringen er irrelevant, og det er enkelt å skille nettsteder. De største ulempene er tilgjengeligheten av domener og ekstra kostnader.
Enkelte domenekort er ikke knyttet til et land eller en region. Den mest populære er .com, men det finnes andre ofte brukte generiske toppnivådomene, som .net og .org.
Disse gTLDene kan brukes i kombinasjon med et underdomene, for eksempel fr.website.com. Det er enkelt å sette opp og de fleste søkemotorer forstår denne typen geografisk målretning. Brukerne kan imidlertid ikke alltid gjenkjenne språket til innholdet basert på nettadressen.
Underkataloger er underdomenes motstykke. De brukes ofte til å strukturere innhold (for eksempel website.com/blog eller website.com/tshirts), men kan også brukes til geografiske mål. I dette tilfellet bruker vi website.com/fr til å strukturere webadressene våre.
Med denne teknikken kan alt være vert på samme server. Oppsett er veldig enkelt, og du kan bruke Google Search Console til å identifisere de forskjellige språkene. En ulempe er at brukere kanskje ikke gjenkjenner geotargeting fra nettadressen alene (for eksempel er webshop.com/de/ på tysk eller ikke?)
Endelig er det nettadresseparametere, for eksempel website.com?country=it. Nettadresseparametere anbefales ikke, fordi de er vanskelige for søkemotorer å tolke.
Personlig liker jeg å bruke underkataloger i kombinasjon med en gTLD. Underdomene brukes mest for å skille ut innhold som er helt annerledes. Fordi flerspråklige nettsteder i utgangspunktet er oversettelser av det samme innholdet (mesteparten av tiden), er underkataloger en åpenbar løsning.
Du kan bruke språket i nettadressen, for eksempel:
Eller kombinere språk og plassering:
For å unngå dupliserte innholdsproblemer, er det best å identifisere en foretrukket versjon for hvert språk / sted. Vi kan bruke et enkelt HTML-linkelement for dette, nemlig rel = "alternate" hreflang = "x". multiple hreflang Tagger skal brukes på en side; en som refererer til seg selv og en link til hvert alternativ.
På en nettside kan denne koden se slik ut:
Denne koden forteller søkemotorer som example.com er rettet mot engelsktalende i Storbritannia. Det står også at det er to variasjoner av samme innhold, nemlig en for USA og en for Australia.
Når du designer flerspråklige nettsteder, er det flere andre ting å vurdere, for eksempel:
Ikke alle land bruker samme datoformat. Noen ganger må du konvertere datoer fra den gregorianske kalenderen til for eksempel den persiske kalenderen.
Land har forskjellige etiske synspunkter. Det er en kulturspesifikk karakter av seksualitet, humor, symbolikk, etc. som lett overses når man oversetter et nettsted. For eksempel: i enkelte land er det helt akseptabelt å vise et bilde av homofil, mens andre land kan finne denne støtende.
Bruker du en captcha på nettstedet ditt? Pass på at det er på samme språk som sidens innhold. Som en britisk besøkende er det usannsynlig at du vil løse en russisk captcha.
Fordi de ikke er vanskelige nok allerede ... Hjelp de besøkende med telefonnumre på nettstedet ditt ved å inkludere landskoden. Du finner en liste over alle landskoder på denne siden.
Det er mange flere hensyn når du utarbeider et nettsted for fullstendig internasjonalisering, men disse pekene skal ha gitt deg et godt utgangspunkt for å jobbe fra. Gi oss beskjed i kommentarene til hvilke andre tips du har for flerspråklig webdesign, og registrer deg for nyhetsbrevet Tuts + Translation Project hvis du er interessert i å høre hva vi skal gjøre!
Accentsconagua