Så översätter du en webbplats till tio språk: mitt system med WordPress, Polylang, egen plugin och massor av AI

Ett av de enklaste sätten att få mer organisk trafik är att översätta en webbplats.

Det är logiskt: fler URL:er, fler sökintentioner; om innehållet är bra ger det mer trafik.

Visst, att göra det med AI verkar enkelt. Och det är det, på små webbplatser.

På medelstora och stora webbplatser blir det mer komplicerat, åtminstone om du försöker göra det ordentligt.

För det handlar inte bara om att ta en artikel på spanska, klistra in den i ChatGPT och be om fem versioner. 

Det fungerar för ett test, men en riktig webbplats har kategorier, taggar, SEO, bilder, anpassade fält, interna länkar, menyer, arkivsidor, startsidor, slugs, datum, hreflang och redaktionell struktur. 

För att inte tala om att varje artikel innehåller fetstil, listor och kursiv stil som man helst vill behålla i översättningen.

Och allt måste vara översatt.

Det jag har gjort den här veckan på min webbplats är att bygga ett system för att gå från en spansk webbplats till en flerspråkig webbplats på tio språk: engelska, franska, portugisiska, italienska, tyska, nederländska, svenska, polska och norska, med pluginet Polylang, en egenutvecklad plugin och ett par anpassade GPTs.

Resultatet är att jag nu har webbplatsen på tio språk, med hela strukturen av kategorier och taggar och flera publicerade artiklar redan översatta.

Och med ett system som lägger till mellan 5 och 10 extra minuter på varje spansk artikel för att få den översatt till dessa tio språk, vilket jag tycker är mer än rimligt.

Jag berättar hela processen om du vill göra samma sak.

1. Det första problemet: att översätta artiklar räckte inte

När jag började analysera utvecklingen upptäckte jag att jag i mitt fall, utöver själva artiklarna, behövde översätta allt detta:

• Kategorier.
• Taggar.
• Slugs.
• Metabeskrivningar.
• SEO-titlar.
• Utvalda bilder.
• Alt-texter.
• ACF-fält.
• Interna block.
• Länkar mellan artiklar.
• Arkivsidor.
• Fasta texter i temat.
• Startsidemoduler.
• CTAs.
• Formulär.
• Innehållsförteckningar.
• Relaterade artiklar.
• Behålla datum och betyg.
• …

Många copies där och många språk för att göra det ett och ett.

Men det behövde översättas, eftersom om någon av dessa delar blir kvar på spanska är översättningen bara halvfärdig.

Därför var målet inte att “översätta innehåll”, utan att skapa en komplett och skalbar flerspråkig arkitektur, om jag i morgon vill lägga till fler språk.

Och det var faktiskt det som hände: jag började bara med fem språk (engelska, portugisiska, franska, tyska och italienska) och lade till de andra fyra längs vägen. Och samtidigt kunde jag bekräfta att systemet lät mig skala vad jag behövde.

2. Grunden: WordPress, Polylang och lokal kopia

Projektet utgår från en WordPress-webbplats med Genesis-tema, egen magasinliknande design och flera anpassade mallar.

Eftersom det var något av viss omfattning och skulle kräva många tester arbetade jag med en lokal kopia med LocalWP. Tanken var att kunna ha sönder saker utan rädsla, testa importer, granska taxonomier och validera att Polylang länkade varje översättning korrekt.

För övrigt använde jag detta plugin som bas eftersom det redan genererar allt som krävs för att ha en webbplats på flera språk. Utifrån det skapade jag mitt plugin genom att komplettera och anpassa det till det jag behövde: snabbt skapa webbstrukturen och artiklarna på flera språk.

Även i denna första fas optimerade jag LocalWP eftersom miljön i början var för långsam och jag behövde en plats där jag kunde exportera, importera, radera, upprepa och validera smidigt..

3. Systemet: egen plugin plus GPTs

Jag hade kunnat använda en standardlösning för automatisk översättning, men målet var ett annat.

Enkel översättning av varje post

Med översättningen av posterna var jag MYCKET ambitiös, eftersom jag ville ha ett system där GPTs skapade för detta översatte innehållet i varje post och behöll:

• Min stil personliga.
• Samma struktur som originalartikeln.
• Officiella titlar på filmer, serier eller böcker på varje språk (det vill säga att om verket är på spanska skulle översättningen använda titeln som det släpptes under i Italien, till exempel.
• Rena slugs.
• Bild-alt översatta.
• Yoast med fullständigt översatta fält, inklusive description.
• Anpassade ACF-fält, så att jag kunde välja om de exporteras eller inte, om de översätts eller om de förblir som de var (till exempel betyget jag ger varje verk i mina recensioner).
• HTML-fragment utan att förstöra dem: listor, fetstil, kodblock… så att de bevaras och nödvändiga delar lämnas oöversatta (som kodskript).
• Interna länkar i artiklarna: så att de pekar på URL:en för varje språk, inte alltid på originalet.
• Publiceringsdatum: originaldatumet för posten på spanska måste behållas.

Som du ser är logiken bakom detta inte “översätt och klart”. Det ligger många tester bakom och till och med vissa saker som valts bort, som schema som tills vidare bara finns på spanska.

Och dessutom ville jag att det skulle vara ett gratis system, med GPTs i stället för OpenAI:s eller Claudes API. Mer manuellt, men lägre kostnad.

Lösningen jag valde innehåller dessa steg:

1. Jag publicerar en artikel på spanska som vanligt.
2. Jag använder mitt plugin för att exportera en strukturerad JSON, som innehåller hela postens innehåll uppdelat för översättning.
3. En GPT översätter denna JSON till de nio språken och ger mig nio JSON tillbaka (en per språk).
4. Pluginet importerar de nio översatta JSON-filerna.
5. Polylang länkar varje översättning till originalet.
6. Artiklarna skapas som utkast.
7. Jag granskar och/eller publicerar.
8. Jag reparerar interna länkar (automatiskt) om det behövs.

Dessutom fanns det ett första steg: att skapa strukturen på flera språk. Detta görs bara första gången det finns nya språk, vilket i mitt fall var två gånger: först för de fem första språken och sedan för de andra fyra.

Om vi tar bort den första uppgiften engångs, lägger processen jag har designat till ungefär fem minuter extra till skapandet av varje post bara, samtidigt som jag multiplicerar det användbara innehållet på min webbplats med nio.

Inte illa.

Den flerspråkiga strukturen

Låt oss se:

• Webbplats anpassad till max.
• Med gränssnittscopy.
• En startsida som hade nästan all sin text i kod.
• 23 kategorier och underkategorier, med sina modulrubriker, många copies i skräddarsydda fält och sina SEO-variabler.
• 24 taggar med liknande egenskaper.
• Flera skräddarsydda moduler.
• Plugins som inte tillåter flerspråkighet som standard.

Och jag vet inte om jag glömmer något mer.

Allt detta behövde översättas en gång per språk. Och det hade tagit mig, jag vet inte, minst fyra timmar i varje fall. Och det förutsätter att jag kunde alla dessa språk, vilket jag inte gör.

Inte en chans.

Vad gjorde jag?

Jo, den här processen:

1. Anpassa alla copies till variabler, i kod och i ACF custom fields..
2. Skapa en funktion i pluginet som exporterar alla dessa variabler från varje kategori eller tagg i JSON.
3. Skapa en GPT som översätter denna JSON till det språk jag behöver.
4. Lägga till en importör i pluginet som hämtar den översatta JSON-filen och skapar hela taxonomistrukturen på det nya språket.
5. Upprepa processen med varje språk.
6. Ändra de texter som fortfarande saknades.

Det fanns flera punkter som ställde till det, som slugs i taxonomierna, eftersom grundversionen av Polylang inte tillåter att man skapar två likadana slugs (bara med Pro).

Det vill säga att taggen “comic” på spanska inte kunde skapas som “comic” på engelska, utan måste vara “comic-en” eller liknande.

Jag utvecklade pluginet så att det tillät detta, med dominio.com/comic på spanska och dominio.com/en/comic på engelska.

Yaarp (pluginet jag använde för relaterade artiklar) gav mig också problem, så jag inaktiverade det eftersom det rekommenderade artiklar på andra språk. Förmodligen skapar jag i framtiden en funktion som prioriterar språk över resten av variablerna i dess rekommendationer.

Den prenumerationen på listan på andra språk har jag också valt bort inför lanseringen. Kanske bestämmer jag mig i framtiden för att skicka mitt nyhetsbrev översatt, men just nu gör jag det inte, så jag skapade inga nya listor i Acumbamail.

4. Det redan skapade innehållet: lite i taget

Allt jag har berättat fungerar utmärkt för nya artiklar, men vad händer med de mer än tvåhundra som jag redan har publicerat?

Jag skulle gärna säga att jag har skapat en funktion som automatiserar deras översättning, men så är det inte.

Det längsta jag har kommit är att skapa en funktion som genererar JSON exporterade i batcher med flera artiklar, men när jag testade att översätta flera artiklar samtidigt till nio språk bearbetar GPT det sämre. Så tills vidare, en och en.

Med tanke på att det tar mig cirka tre minuter per artikel är det ganska enkelt att översätta tio per dag, vilket skulle göra att jag på mindre än en månad hade hela webbplatsen på de tio språken.

Det passar mig.

Jag har också funderat på att sätta upp en Hermes och testa om den gör det manuellt, men eftersom jag just nu inte har bråttom och detta inte ger mig pengar, föredrar jag att inte spendera fler tokens än nödvändigt.

Resultatet

För tillfället är jag nöjd. Jag har redan mer än tio artiklar översatta till tio språk. Det vill säga att min webbplats har vuxit med 33 % på en vecka.

För tillfället tvingar jag inte fram någon indexering. Jag vill vänta tills jag har minst 50 eller 60 artiklar. Men om de indexeras oroar det mig inte heller. Det här är långsiktigt.

Det jag kan säga är att jag är nöjd med resultatet. 

Jag tycker att systemet jag har byggt är ganska robust — med sina troliga förbättringar, förstås — men inte ens i mina bästa drömmar för ungefär ett år sedan kunde jag föreställa mig att jag skulle hantera en flerspråkig webbplats med denna mängd innehåll.

Nu, som jag alltid säger, får vi se vart allt detta leder mig.

Lärdomar från processen och slutsats

Den främsta slutsatsen — som jag redan anade — är att översätta en webbplats med AI inte handlar om att “översätta texter”, utan om att designa ett system.

AI är supernyttigt om den får rena indata och returnerar kontrollerade utdata. Men om du ger den ett enormt block, utan struktur och utan regler, returnerar den något snyggt som inte går att importera.

Tro mig, det hände mig många gånger i början.

Nyckeln har varit att bygga ett system där varje del gör det den ska göra:

• WordPress är hjärtat i allt.
• Polylang kopplar samman innehåll.
• Pluginet exporterar och importerar.
• GPT översätter.
• Jag fattar de redaktionella besluten.

Att vara tydlig med var varje del passar in och varför den gör just det och inget annat är det som har gjort det möjligt för mig att skapa ett verkligt system för att skala en webbplats med AI-översättning som hävstång.

Om du gillade mitt system och vill att jag förklarar någon punkt, skriv dina frågor i kommentarerna så svarar jag.