Mislukte vertalingen triëren zonder de release te verliezen

In een meertalige release is "mislukt" niet één toestand.

Het modelverzoek kan zijn mislukt. De vertaling kan gereed zijn maar niet naar Contentful kunnen worden gepusht. De gelokaliseerde invoer kan zijn bijgewerkt maar niet gepubliceerd. Alle drie onder één rode status groeperen maakt het dashboard eenvoudiger en het herstelwerk moeilijker.

Begin met de mislukte fase

Vertalen, pushen en publiceren zijn afzonderlijke bewerkingen met verschillende afhankelijkheden.

Een vertaalsfout kan komen door een time-out bij de provider, een ongeldig modelantwoord of validatie van beschermde content. Een pushfout kan te maken hebben met machtigingen, veldvalidatie of een Contentful-versieconflict. Een publicatiefout kan de status van de invoer, de omgevingsconfiguratie of de publicatiemodus weerspiegelen.

Het eerste triagefilter moet antwoord geven op: welke fase heeft aandacht nodig?

Dat beperkt onmiddellijk de verantwoordelijkheid en de volgende stappen.

Toon de omvang van de impact

Een mislukt verzoek heeft voldoende identificatie nodig om een beslissing te ondersteunen:

• naam en ID van de invoer
• bron- en doellocale
• batch
• mislukte fase
• meest recente fout
• aantal pogingen en tijdstip van de laatste poging
• of latere fasen ooit zijn gestart

Zonder die context openen operators elk verzoek afzonderlijk en reconstrueren ze de release met de hand.

De batchweergave moet ook gedeeltelijke mislukking onderscheiden van totale mislukking. Als 49 van de 50 locales zijn geslaagd, moet het team verder kunnen met het voltooide werk terwijl het één verzoek herstelt.

Probeer opnieuw vanaf de juiste grens

Een retry moet de mislukte fase hervatten, niet elke succesvolle fase ervoor herhalen.

Als vertaling is geslaagd en pushen is mislukt, behoud dan de beoordeelde vertaling en probeer de push opnieuw. Als Contentful is bijgewerkt en publiceren is mislukt, probeer dan opnieuw te publiceren tegen de huidige status van de invoer.

Opnieuw starten vanaf vertaling kan andere copy opleveren, beoordeling ongeldig maken, kosten verhogen en het oorspronkelijke probleem verbergen.

Retries die zich bewust zijn van fasen houden succesvol werk stabiel.

Scheid tijdelijke en permanente fouten

Sommige fouten zijn goede kandidaten voor automatische retry:

• time-outs bij providers
• rate limits
• korte netwerkonderbrekingen
• herstelbare versieconflicten

Andere hebben een persoon nodig:

• ongeldige contentconfiguratie
• ontbrekende locale-inschakeling
• weigering van machtigingen
• beschermde structuur die niet kan worden hersteld
• een doelveld dat na beoordeling is gewijzigd

Het retrybeleid moet begrensd en zichtbaar zijn. Nadat de automatische limiet is bereikt, hoort het verzoek thuis in een menselijke wachtrij met de laatste bruikbare fout intact.

Houd de foutenlijst lichtgewicht

Operations-schermen worden gebruikt wanneer er al iets misgaat. Ze moeten niet voor elke rij diepe CMS-hydratie triggeren of zo agressief pollen dat de pagina meer belasting veroorzaakt dan de workers die ze bewaakt.

Geef eerst stabiele verzoekmetadata terug. Haal volledige invoerdetails alleen op wanneer een operator het verzoek opent.

Snel filteren maakt deel uit van herstel.

De kern

Een rode badge is geen herstelsysteem.

Scheid fouten per fase, toon de getroffen omvang en probeer alleen de bewerking opnieuw die is mislukt. Automatiseer tijdelijk herstel binnen duidelijke grenzen en behoud bruikbare fouten voor al het overige. Teams kunnen individuele fouten verdragen wanneer de workflow de volgende beslissing duidelijk maakt.