Tillbaka till bloggen

Reliability · 10 juni 2026

Contentful versionskonflikter bör kunna återförsökas säkert

Redaktörer och automation arbetar ofta med samma post. Ett tillförlitligt lokaliseringsflöde hanterar Contentful-versionskonflikter utan att någon av ändringarna går förlorad.

Contentful versionskonflikter bör kunna återförsökas säkert

Contentful skyddar poster med optimistisk låsning. Varje uppdatering innehåller den version som klienten tror att den redigerar. Om en annan ändring hinner ske först avvisar Contentful den inaktuella uppdateringen i stället för att låta den skriva över nyare arbete.

Den konflikten är en säkerhetsfunktion. Den bör inte bli en återvändsgränd för lokalisering.

Varför konflikter uppstår i välfungerande team

En översättningsbegäran kan ta tid. Medan den genereras eller granskas kan en redaktör korrigera källposten, ett annat språkområde kan uppdateras eller en automation kan ändra metadata.

När det lokaliserade värdet väl är klart att skickas upp är den postversion som tidigare fångades inaktuell.

Det betyder inte att någon har gjort ett misstag. Det betyder att flera delar av publiceringssystemet arbetar samtidigt.

Försök aldrig blint igen med samma inaktuella payload

Det enklaste återförsöket upprepar den avvisade begäran. Det kan inte lyckas eftersom den innehåller samma föråldrade version.

Det farliga alternativet hämtar det senaste versionsnumret och skickar hela den gamla postens payload igen. Det kan klara versionskontrollen samtidigt som det skriver över fält som ändrats sedan översättningen började.

Ett säkert återförsök kräver färskt tillstånd och en smal patch.

Läs om, slå samman och uppdatera

När Contentful rapporterar en versionskonflikt bör arbetsflödet:

  1. hämta den aktuella posten från samma space och environment
  2. granska de senaste fälten och versionen
  3. slå samman endast de godkända värdena för målspråket från översättningsbegäran
  4. bevara orelaterade fält och språkvärden
  5. skicka uppdateringen med den färska versionen

Detta håller återförsöket i linje med användarens faktiska avsikt. Översättningsbegäran ville ändra specifika lokaliserade fält, inte återställa en gammal ögonblicksbild av hela posten.

Avgör när man inte ska försöka igen

Automatisk konflikthantering behöver gränser.

Om det exakta målspråksfältet ändrades efter att granskningen började har systemet hittat en verklig redaktionell kollision. Att försöka igen automatiskt kan ersätta nyare mänskligt arbete. I det fallet bör processen stoppa och begära granskning.

På samma sätt kan upprepade konflikter tyda på en upptagen automationsloop eller en integration som skriver till posten kontinuerligt. Ett begränsat antal återförsök förhindrar att lokaliseringen ansluter sig till den loopen på obestämd tid.

Felet bör förbli åtgärdbart: identifiera posten, berört språkområde och fält samt det steg där kollisionen inträffade.

Håll ägarskapet för käll- och målinnehåll tydligt

Konflikthantering är enklare när arbetsflödet har en strikt skrivgräns. Översättningspushar bör bara ändra godkända målspråk. De bör inte skriva till källfält, metadata för innehållstyp, taggar eller orelaterade språkvärden.

Den gränsen minskar sammanslagningskomplexiteten och gör granskningsloggar meningsfulla. När ett återförsök lyckas kan teamet se exakt vilka lokaliserade fält som ändrades och varför.

Slutsats

Versionskonflikter är normala i ett samarbetsinriktat CMS. Att behandla varje konflikt som en misslyckad översättning får arbetsflödet att kännas skört; att ignorera konflikten gör det osäkert.

Hämta den senaste posten, slå samman den minsta godkända ändringen och försök igen inom tydliga gränser. När samma fält ändrades på båda sidor, stoppa för mänsklig granskning. Tillförlitlighet kommer av att respektera samtidigt arbete, inte av att låtsas som att det inte händer.