Oversæt hele din hjemmeside med få klik

En kunde mailede os sidste forår med et problem, vi hører hele tiden. De solgte industriarmaturer, for det meste til Danmark og Tyskland, og omkring en femtedel af deres trafik kom stille og roligt fra Frankrig og Holland. Ikke nok til at retfærdiggøre ansættelse af oversættere. Alt for meget til at blive ved med at ignorere. Hjemmesiden havde omkring 4.000 produktsider. Hvert citat, de fik tilbage for at oversætte det, startede med et komma på et ubehageligt sted.

Det er den situationsfornemmelse, der er skabt til – og for at være fair, den situation, hvor det virkelig er det rigtige værktøj snarere end en genvej. Lad os gennemgå, hvordan det virker, så de dele, ingen nævner, indtil du allerede har tændt den.

Den gamle måde, og hvorfor det gør ondt

Traditionel lokalisering sker på applikationslaget. Dit CMS lærer om hvert sprog, gemmer en kopi af hver side og gengiver den rigtige pr. anmodning. WPML og Polylang gør det godt, og hvis hvert ord på dit websted er marketingkopi, der skal underskrives, er det det rigtige svar, og du bør stoppe med at læse her.

Omkostningerne vises på tre steder. Din database fordobles pr. sprog. Din admin bliver langsommere, nogle gange dramatisk. Og du får et fast job: Intet kan gå live, før det er blevet oversat, så dit engelske websted og dit franske websted glider fra hinanden i det øjeblik nogen får travlt.

Edge oversættelse gør det modsatte handel. Du får automatisk dækning af alt, hvad du har, herunder sider, du ikke har skrevet endnu, i bytte for maskinfrasering i stedet for en menneskelig redaktørs. For et 4.000 siders fittingskatalog er det ikke et kompromis – det er forskellen mellem at have en fransk byggeplads og ikke at have en.

Hvad sker der egentlig med en ansøgning

Din oprindelse bliver ved med at tjene præcis én version af dit websted: den, du allerede har. Når en besøgende beder om den franske version, lander anmodningen på den nærmeste kantserver, som kontrollerer sin cache for en fransk kopi. Hvis det har en, er det et normalt cache-hit, og det kommer tilbage i et cifret millisekunder. Hvis ikke, henter kanten siden fra din oprindelse på originalsproget, oversætter den synlige tekst, omskriver interne links, så klik på videre holder den besøgende på fransk, gemmer resultatet og returnerer det.

Det vigtige ord er efter. Oversættelsen sker, efter at siden er fuldt bygget, på færdig HTML, hvilket er grunden til det behøver ingen plugins, ingen skema ændringer og intet samarbejde fra dit tema. Det er også derfor, det ikke kan se noget dit tema ikke satte i HTML hvilket bringer os til den første ting, der vil bide dig.

Tre ting, der vil bide dig

1. JavaScript-gengivet indhold ankommer uoversat

Kanten oversætter den HTML, den modtager. Hvis dit produktgitter gengives på klientsiden fra en API, efter at siden er indlæst, er indholdet ikke i HTML, så det forbliver på originalsproget. Siden vil se overbevisende oversat navigation, overskrifter, sidefod, alle franske og derefter vil produktnavnene være på dansk.

Tjek en JavaScript-tung side på dag et, ikke efter lanceringen. Hvis din ramme kan server-render disse ruter, gør det. Hvis det ikke kan, udelukke disse stier og være ærlig om det i stedet for at sende en halvoversat side.

2. Tekst inde i billeder forbliver i originalsproget for evigt

En tekstoversætter ser tekstnoder. Det kan ikke se de ord, der er bagt ind i din helt banner, din infographic, eller at PNG af en prissætning tabel nogen lavet i 2019, og ingen kan finde kildefilen til. Hvert flersproget websted opdager i sidste ende en af disse, normalt fordi en kunde påpeger det.

3. Dine brands skal beskyttes

Uden en do-not-oversætte liste, produktnavne bliver oversat inkonsekvent "Site Accelerator" bliver en ting på hjemmesiden og noget andet på prissætning side, og din support team tilbringer et år fielding Forvirrede mails. To minutter brugt notering dit brand vilkår, produktnavne og enhver form for kunst forhindrer det hele.

Sætte det op

SEO-delen, hvor folk går galt

Et oversat websted, Google ikke kan se, er et fancy legetøj. Tre ting bestemmer, om det virker.

Hvert sprog har brug for en ægte URL. Crawlere klikker ikke på sprogskiftere og bærer ikke cookies. Hvis fransk kun eksisterer bag en JavaScript-skift, eksisterer fransk ikke så vidt det er relevant for søgning.

Hreflang skal være gensidig. Hver sprogversion viser alle andre, herunder sig selv, og hver af disse sider viser tilbage. Envejs hreflang er den mest almindelige implementeringsfejl, der er, og Google ignorerer lydløst anmærkninger, det ikke kan bekræfte fra begge ender - så det fejler stille, hvilket er den værste måde for noget at fejle. Tilføj en x-default For besøgende, der ikke matcher noget.

Maskinoversættelse er fint. Google droppede sin tæppe advarsel mod det år siden; hvad det handler på nu er indhold uden værdi for læseren, på ethvert sprog. Et maskinoversat katalog, der hjælper en spansk shopper med at købe den rigtige montering, er nyttigt. 40 autogenererede sprog, du ikke har til hensigt at støtte, er ikke. Forskellen er, om siden var værd at læse, før du oversatte den.

Hvad koster det i fart

Næsten ingenting, når cachen er varm. Det første hit per sprog betaler oversættelsesomkostningerne; hvert hit efter det er et normalt cachelagret svar fra kanten nærmest den besøgende.

Den reelle omkostning er cache fodaftryk, ikke latency. Tre sprog betyder omtrent tre gange de cachede objekter for de samme sider, og en udrensning rydder dem alle. Hvis du kører et stort katalog, kan du forvente, at dit cache-hitforhold falder i en dag eller to efter at have tændt sprog, mens de nye kopier bliver bygget. Det er normalt, og det kommer sig af sig selv.

Fittings-kunden, for hvad det er værd, tændte det for fransk og hollandsk, brugte en eftermiddag på deres gør-ikke-oversætte liste og lod det være alene. Deres franske trafik eksploderede ikke natten over - det er ikke sådan organisk søgning virker - men ni måneder senere var det deres tredje største marked. Siderne havde siddet der hele tiden. De var simpelthen ikke læselige.