Tilbage til bloggen

Reliability · 10. jun. 2026

Contentful versionskonflikter bør genforsøges sikkert

Redaktører og automatisering arbejder ofte på den samme post. Et pålideligt lokaliseringsworkflow håndterer versionskonflikter i Contentful uden at miste nogen af ændringerne.

Contentful versionskonflikter bør genforsøges sikkert

Contentful beskytter poster med optimistisk låsning. Hver opdatering indeholder den version, som klienten mener, den redigerer. Hvis en anden ændring lander først, afviser Contentful den forældede opdatering i stedet for at lade den overskrive nyere arbejde.

Den konflikt er en sikkerhedsfunktion. Den bør ikke blive en blindgyde for lokalisering.

Hvorfor konflikter opstår i velfungerende teams

En oversættelsesanmodning kan tage tid. Mens den bliver genereret eller gennemgået, kan en redaktør rette kildeposten, et andet sprog kan blive opdateret, eller en automatisering kan ændre metadata.

Når den lokaliserede værdi er klar til at blive sendt, er den postversion, der blev registreret tidligere, forældet.

Det betyder ikke, at nogen har begået en fejl. Det betyder, at flere dele af publiceringssystemet arbejder samtidig.

Genforsøg aldrig blindt med den samme forældede payload

Det enkleste genforsøg gentager den afviste anmodning. Det kan ikke lykkes, fordi den indeholder den samme forældede version.

Det farlige alternativ henter det nyeste versionsnummer og gensender hele den gamle payload for posten. Det kan bestå versionskontrollen, mens det overskriver felter, der er blevet ændret, siden oversættelsen begyndte.

Et sikkert genforsøg kræver frisk tilstand og en snæver patch.

Genlæs, flet, og opdater

Når Contentful rapporterer en versionskonflikt, bør workflowet:

  1. hente den aktuelle post fra det samme space og environment
  2. inspicere de nyeste felter og versionen
  3. kun flette de godkendte værdier for målsproget fra oversættelsesanmodningen
  4. bevare ikke-relaterede felter og sprogversioner
  5. sende opdateringen med den nye version

Dette holder genforsøget i tråd med brugerens faktiske hensigt. Oversættelsesanmodningen ønskede at ændre specifikke lokaliserede felter, ikke at gendanne et gammelt øjebliksbillede af hele posten.

Beslut, hvornår der ikke skal genforsøges

Automatisk konflikthåndtering kræver grænser.

Hvis det præcise felt for målsproget blev ændret, efter at gennemgangen begyndte, har systemet fundet en reel redaktionel kollision. Et automatisk genforsøg kunne erstatte nyere menneskeligt arbejde. I det tilfælde bør processen stoppe og bede om gennemgang.

På samme måde kan gentagne konflikter indikere et travlt automatiseringsloop eller en integration, der skriver til posten kontinuerligt. Et begrænset antal genforsøg forhindrer lokalisering i at blive en del af det loop uden ende.

Fejlen bør forblive handlingsrettet: identificér posten, det berørte sprog og de berørte felter samt det trin, hvor kollisionen opstod.

Hold ejerskabet af kilde og mål tydeligt adskilt

Konflikthåndtering er lettere, når workflowet har en streng skrivegrænse. Oversættelses-pushes bør kun ændre godkendte målsprog. De bør ikke skrive til kildefelter, indholdstypemetadata, tags eller ikke-relaterede sprogversioner.

Den grænse reducerer kompleksiteten ved fletning og gør revisionslogge meningsfulde. Når et genforsøg lykkes, kan teamet se præcis, hvilke lokaliserede felter der blev ændret, og hvorfor.

Konklusionen

Versionskonflikter er normale i et samarbejdsorienteret CMS. At behandle hver konflikt som en mislykket oversættelse får workflowet til at virke skrøbeligt; at ignorere konflikten gør det usikkert.

Hent den nyeste post, flet den mindste godkendte ændring, og genforsøg inden for tydelige grænser. Når det samme felt er blevet ændret på begge sider, så stop for menneskelig gennemgang. Pålidelighed kommer af at respektere samtidige ændringer, ikke af at lade som om de ikke sker.