Contentful-versieconflicten moeten veilig opnieuw proberen

Contentful beschermt entries met optimistic locking. Elke update bevat de versie waarvan de client denkt dat deze wordt bewerkt. Als een andere wijziging eerst wordt doorgevoerd, wijst Contentful de verouderde update af in plaats van die nieuwer werk te laten overschrijven.

Dat conflict is een veiligheidsfunctie. Het mag geen doodlopend punt worden voor lokalisatie.

Waarom conflicten gebeuren in gezonde teams

Een vertaalverzoek kan tijd kosten. Terwijl het wordt gegenereerd of beoordeeld, kan een redacteur de bronentry corrigeren, kan een andere locale worden bijgewerkt, of kan een automatisering metadata wijzigen.

Tegen de tijd dat de gelokaliseerde waarde klaar is om te pushen, is de eerder vastgelegde entryversie verouderd.

Dit betekent niet dat iemand een fout heeft gemaakt. Het betekent dat meerdere onderdelen van het publicatiesysteem tegelijk werken.

Probeer nooit blind dezelfde verouderde payload opnieuw

De eenvoudigste retry herhaalt het afgewezen verzoek. Dat kan niet slagen omdat het dezelfde verouderde versie bevat.

Het gevaarlijke alternatief haalt het nieuwste versienummer op en verstuurt de volledige oude entry-payload opnieuw. Dat kan de versiecontrole passeren terwijl velden worden overschreven die sinds de start van de vertaling zijn gewijzigd.

Een veilige retry heeft een actuele status en een beperkte patch nodig.

Opnieuw lezen, samenvoegen en bijwerken

Wanneer Contentful een versieconflict meldt, moet de workflow:

1. de huidige entry ophalen uit dezelfde space en environment
2. de nieuwste velden en versie inspecteren
3. alleen de goedgekeurde waarden voor de target-locale uit het vertaalverzoek samenvoegen
4. niet-gerelateerde velden en locale-waarden behouden
5. de update indienen met de actuele versie

Dit houdt de retry afgestemd op de werkelijke intentie van de gebruiker. Het vertaalverzoek wilde specifieke gelokaliseerde velden wijzigen, niet een oude momentopname van de hele entry herstellen.

Bepaal wanneer je niet opnieuw moet proberen

Automatisch herstel van conflicten heeft grenzen nodig.

Als het exacte target-locale-veld is gewijzigd nadat de beoordeling begon, heeft het systeem een echte redactionele botsing gevonden. Automatisch opnieuw proberen kan nieuwer menselijk werk vervangen. In dat geval moet het proces stoppen en om beoordeling vragen.

Ook kunnen herhaalde conflicten wijzen op een drukke automatiseringslus of een integratie die de entry voortdurend schrijft. Een begrensd aantal retries voorkomt dat lokalisatie eindeloos in die lus terechtkomt.

De fout moet bruikbaar blijven: identificeer de entry, de betrokken locale en velden, en de fase waarin de botsing optrad.

Houd eigenaarschap van bron en doel duidelijk

Afhandeling van conflicten is eenvoudiger wanneer de workflow een strikte schrijfgrens heeft. Translation pushes mogen alleen goedgekeurde target locales wijzigen. Ze mogen geen bronvelden, contenttypemetadata, tags of niet-gerelateerde locale-waarden schrijven.

Die grens vermindert de complexiteit van het samenvoegen en maakt auditlogs betekenisvol. Wanneer een retry slaagt, kan het team precies zien welke gelokaliseerde velden zijn gewijzigd en waarom.

De kern

Versieconflicten zijn normaal in een collaboratieve CMS. Elk conflict behandelen als een mislukte vertaling laat de workflow fragiel aanvoelen; het conflict negeren maakt die onveilig.

Haal de nieuwste entry op, voeg de kleinste goedgekeurde wijziging samen en probeer opnieuw binnen duidelijke grenzen. Wanneer hetzelfde veld aan beide kanten is gewijzigd, stop dan voor menselijke beoordeling. Betrouwbaarheid komt voort uit het respecteren van gelijktijdig werk, niet uit doen alsof het niet gebeurt.