Jämförelse av strategier för lokalisering av Contentful

Lokalisering handlar om att utforma hela upplevelsen för en specifik marknad, inte bara om att översätta text till ett annat språk. I Contentful märks den skillnaden i hur du strukturerar innehållstyper och poster.  

Contentful beskriver fyra huvudsakliga lokaliseringsmönster/strategier – på fältnivå, på postnivå, per innehållstyp och på rumsnivå – men ger inga råd om vilket man ska välja eller när man bör byta från ett mönster till ett annat. Om man väljer fel mönster i ett tidigt skede kan det leda till att teamen fastnar i bräckliga arbetsflöden, duplicerat innehåll och kostsamma ombyggnader när man expanderar till en tredje marknad eller en andra kanal.

Den här guiden går igenom varje strategi, hur språkinställningar och reservalternativ fungerar i API:et samt vilka avvägningar som är viktiga för just din publiceringsmodell. Vi visar dig också hur du kan kombinera Contentful med ett AI-baserat webbplatsöversättningsverktyg som Weglot ger dig en snabbare väg till en flerspråkig webbplats.

Viktiga slutsatser

• Bestäm först vilken Contentful-strategi du vill använda – varje strategi passar olika styrnings- och publiceringsmodeller.
  
• Bestäm tidigt om du vill ha en strikt marknadsuppdelning eller delat innehåll med reservalternativ; om du ändrar detta efter den tredje språkversionen innebär det oftast att du måste bygga om hela projektet.
  
• Betrakta fallback-kedjor som ett medvetet designval – de styr vilka marknader som ärver innehåll från andra och när detta sker.
  
• Var tydlig med var översättningarna ska placeras – i Contentful för återanvändning i flera kanaler, eller på webbplatsnivå om din prioritet är att snabbt lansera en flerspråkig webbplats.
  
• Ett AI-översättningsverktyg som Weglot ger dig automatisering, SEO och större flexibilitet genom att hantera allt det tekniska arbetet i molnet.

Hur Contentful strukturerar flerspråkigt innehåll

I Contentful utgår allt från språk- och regionsinställningar – varje inställning består av ett språk- och regionspar, till exempel en-US eller de-AT, och varje utrymme har en enda standardinställning som Content Delivery API (CDA) returnerar om du inte anger någon annan. Språk- och regionsinställningarna finns på miljönivå, och du kan ha upp till 500 stycken per miljö, beroende på vilket abonnemang du har.

Du styr lokaliseringen på fältnivå inom en innehållstyp. Alla fält som är markerade med localized: true lagrar separata värden för varje språkversion, medan fält som inte är lokaliserade har ett enda gemensamt värde för alla språk. Detta är perfekt för exempelvis SKU-nummer, ID-nummer eller globala datum. Du kan redigera och lägga till språkversioner via Content Management API, inklusive egna koder och namn, så du är inte bunden till en strikt ISO-lista så länge varje kod är unik.

När du konfigurerar en språkversion gör alternativet ”Tillåt tomma fält för denna språkversion” det möjligt för redaktörer att publicera även om vissa lokaliserade fält ännu inte har några värden, vilket är praktiskt när olika marknader utvecklas i olika takt. Saknade värden kan då hämtas från din anpassade språkversionshierarki, så att du själv bestämmer om de-CH ska ärva från de-DE, en-US eller ingenting alls.

Jämförelse mellan lokalisering på fältnivå, grundnivå, innehållstypnivå och rumsnivå

Contentful erbjuder fyra huvudstrategier för flerspråkig arkitektur: lokalisering på fältnivå, på postnivå, på innehållstypnivå och på rumsnivå. Var och en av dessa löser olika problem som rör styrning, publiceringsfrihet och hur strikt du vill separera marknaderna.

Här är en översiktlig jämförelse:

‍

Lokalisering på fältnivå samlar alla språk i en enda post. I lokaliserade fält lagras separata värden för varje språkversion, och du får fortfarande tillgång till språkversionsbaserad publicering, reservalternativ och rollbaserad styrning. För de flesta team är detta den bästa utgångspunkten, eftersom det håller modellen överskådlig samtidigt som du fortfarande kan publicera per språkversion när det behövs.

Vid grundläggande lokalisering används en ”global wrapper”-post som länkar till separata lokaliserade poster. Detta passar när regionala team behöver större självständighet, något annorlunda innehåll eller egna godkännandeprocesser. Du behåller fallback-beteendet för referensfältet, men får inte behörigheter som är strikt begränsade till en viss språkversion, eftersom översättarna redigerar olika poster istället för olika språkversioner av en och samma post.

Vid lokalisering på innehållstypnivå dupliceras innehållstyperna per språkversion inom samma utrymme, medan lokalisering på utrymmesnivå innebär att hela innehållsmodellen dupliceras till separata utrymmen för varje språkversion eller region.

Båda dessa alternativ ger dig tydlig åtskillnad och helt oberoende publicering, men du går miste om automatiska reservlösningar och får ta på dig ett kontinuerligt arbete med att synkronisera scheman och innehåll. Vi rekommenderar dessa alternativ endast för strikt efterlevnad eller för marknader där juridiskt innehåll, produktinformation eller varumärkesinnehåll måste skilja sig helt från din huvudwebbplats.

”Weglot undviker alla dessa kompromisser vid modellering genom att översätta det renderade frontendet via ett snippet eller på serversidan där det stöds), så att du snabbt kan lansera en flerspråkig Contentful-webbplats utan att först behöva omforma din innehållsmodell.”

– Christophe Garcia, supportchef på Weglot

{{quote-cta-banner}}

Konfigurera reservkedjor och fällan med tomma värden

Att lägga till en språkversion i Contentful sker i tre steg – skapa den, koppla in reservvärden och aktivera den sedan för fälten. Du lägger till språket via Content Management API (eller webbappen), ställer in dess fallbackCode för att skapa en kedja som de-CH → de-AT → de-DE, och markerar slutligen de fält du vill ha som localized: true så att de kan lagra värden per språk. Den kedjan definierar hur CDA går upp till ett överordnat språk när inget värde är definierat.

Det finstilta är hur Contentful avgör att ett värde saknas. CDA behandlar tre olika fältstatusar på olika sätt:

• Avsaknad: Inget värde har angetts för den lokaliseringen, så CDA följer den konfigurerade reservkedjan.
  
• Null (ställs in via CMA): CDA returnerar null för den lokaliseringen och försöker inte använda reservkedjan.
  
• Tom sträng "" (inställd via CMA): CDA returnerar "" för den lokaliseringen och försöker inte använda reservkedjan.

Du kan endast skapa dessa tomma eller ""-tillstånd programmatiskt via CMA – webbappen hindrar redigerare från att spara dem – vilket är anledningen till att detta fel ofta gömmer sig i migreringsskript och anpassade integrationer.

Kryssrutan ”Tillåt att obligatoriska fält lämnas tomma för denna lokal” handlar om validering. Den gör det möjligt för redaktörer att publicera poster där vissa lokaliserade fält faktiskt ännu inte har något värde, men CDA kommer ändå att följa samma reservregler när det stöter på dessa ofyllda lokalfält vid läsning.

Publicera språkversioner separat och hantera översättarnas åtkomst

För att rikta in dig på ett specifikt språk i din frontend använder du frågeparametern locale med Content Delivery API.

Exempel: locale=de-AT returnerar fält på österrikisk tyska med den fallback-kedja du har konfigurerat, medan locale=* returnerar alla lokaliserade varianter av varje fält i en enda datapaket.

Bakom kulisserna fungerar Sync API alltid som ett jokerteckenläge och inkluderar alla språkinställningar oavsett vilken språkinställning du begär, vilket innebär att efterföljande system måste hantera hela uppsättningen av språkinställningar.

Lokaliseringbaserad publicering är en inställning på miljö-nivå, som endast finns tillgänglig i vissa betalda abonnemang, och som gör det möjligt för redaktörer att publicera eller ta bort publiceringen av en eller flera lokaliseringar av ett inlägg separat. Funktionen gäller för manuell publicering i inläggsredigeraren, men schemalagd publicering och lanseringar sker fortfarande på inläggsnivå.

Med lokaliserade arbetsflöden kan arbetsflödessteg och uppgifter nu riktas mot enskilda språkversioner. När språkbaserad publicering är aktiverad hindrar därför inte längre ett spärrat tillstånd för språkversionen ”franska” att du publicerar språkversionen ”engelska” separat.

Översättarroller kan begränsas per språkversion vid lokalisering på fältnivå, men vid lokalisering på postnivå krävs ofta lösningar för innehållsbehörigheter, eftersom översättarna tekniskt sett redigerar olika poster snarare än olika språkversioner av samma post.

Publicering per språkversion påverkar inte API:ernas funktion, utan avgör vilket innehåll som kan levereras. När funktionen är aktiverad kan du se statusen utkast/publicerat/ändrat per språkversion i användargränssnittet, men CDA- och Sync-API:erna levererar fortfarande de lokaliserade versioner som för närvarande är publicerade för de språkversioner du begär.

Jämförelse av översättningsverktyg för Contentful

Contentful erbjuder två huvudsakliga alternativ för översättning:

1. Håll översättningarna inom Contentful genom att ansluta ett verktyg som synkroniserar översatt text tillbaka till dina lokaliserade fält (till exempel Lokalise, Crowdin, Phrase) och använda Contentfuls egna översättnings- och lokaliseringsfunktioner för att styra arbetsflödet.
2. Håll översättningarna utanför Contentful genom att använda ett verktyg för webbplatsöversättning som Weglot som fungerar på den renderade webbplatsen, lagrar översättningar i sitt eget moln-gränssnitt och inte behöver skriva in något i din innehållsmodell.

Här är en jämförelse av de viktigaste alternativen:

‍

Sammanfattningsvis:

• Lokalise, Crowdin och Phrase hämtar innehåll från Contentful, översätter det och lägger sedan tillbaka översättningarna i dina lokaliserade fält via sina appar. Contentful förblir den primära källan, och din frontend läser bara de lokaliserade fälten som vanligt.
• Weglot och översätter den renderade webbplatsen (HTML) och lagrar översättningarna i molnet, inte i Contentful-fält. Därefter publiceras de översatta versionerna på separata språk-URL:er, där SEO hanteras automatiskt.

Eftersom Contentful endast lagrar källspråket Weglot till snabbare lanseringar, mindre belastning på din innehållsmodell och enklare hantering överlag.

{{ai-banner}}

Att välja rätt lokaliseringsstrategi för ditt team

Välj en Contentful-strategi som passar hur era team faktiskt arbetar. Använd lokalisering på fältnivå för innehåll som i huvudsak delas gemensamt. Använd lokalisering på postnivå, innehållstypnivå eller till och med utrymmesnivå endast när regionerna behöver verklig redaktionell frihet, eller när efterlevnadskrav och mycket olika regionalt innehåll gör det svårt att upprätthålla en gemensam modell.

När det väl är klart är nästa beslut var översättningarna ska placeras. Om Contentful fungerar som din gemensamma plattform för mobilappar, API:er och flera olika frontend-gränssnitt kan du lagra alla språk direkt i dina poster.

Om du främst behöver en Contentful-baserad webbplats som är tillgänglig på flera språk är ett översättningslager på frontend-sidan oftast snabbare och betydligt mindre resurskrävande. Weglot särskilt bra Weglot detta tillvägagångssätt, eftersom det översätter din renderade webbplats, skapar språkspecifika webbadresser och hanterar flerspråkig SEO utan att ändra din befintliga innehållsmodell.

Är du redo att se hur det ser ut på din egen plattform? Starta en kostnadsfri 14-dagars Weglot redan idag och lansera en flerspråkig Contentful-webbplats på några minuter.