Triage epäonnistuneet käännökset menettämättä julkaisua

Monikielisessä julkaisussa "epäonnistunut" ei ole yksi tila.

Mallipyyntö on voinut epäonnistua. Käännös voi olla valmis, mutta sitä ei voida puskea Contentfuliin. Lokalisoitu entry voi olla päivitetty, mutta sitä ei ole julkaistu. Kaikkien kolmen ryhmittely yhden punaisen tilan alle tekee hallintapaneelista yksinkertaisemman ja palautustyöstä vaikeamman.

Aloita epäonnistuneesta vaiheesta

Kääntäminen, push ja julkaisu ovat erillisiä toimintoja, joilla on eri riippuvuudet.

Käännöksen epäonnistuminen voi johtua palveluntarjoajan aikakatkaisusta, virheellisestä mallivastauksesta tai suojatun sisällön validoinnista. Push-epäonnistuminen voi liittyä käyttöoikeuksiin, kenttävalidointiin tai Contentfulin versiokonfliktiin. Julkaisun epäonnistuminen voi heijastaa entryn tilaa, ympäristökonfiguraatiota tai julkaisutilaa.

Ensimmäisen triage-suodattimen pitäisi vastata: mikä vaihe tarvitsee huomiota?

Se rajaa heti omistajuuden ja seuraavat askeleet.

Näytä vaikutuksen laajuus

Epäonnistunut pyyntö tarvitsee riittävästi tunnistetietoja päätöksen tueksi:

• entryn nimi ja ID
• lähde- ja kohdekieli
• erä
• epäonnistunut vaihe
• viimeisin virhe
• yrityskertojen määrä ja viimeisimmän yrityksen aika
• alkoivatko myöhemmät vaiheet koskaan

Ilman tätä kontekstia operaattorit avaavat jokaisen pyynnön erikseen ja rakentavat julkaisun käsin uudelleen.

Eränäkymän pitäisi myös erottaa osittainen epäonnistuminen täydellisestä epäonnistumisesta. Jos 49/50 kielialueesta onnistui, tiimin pitäisi voida edetä valmiin työn kanssa samalla kun yhtä pyyntöä palautetaan.

Yritä uudelleen oikeasta rajasta

Uudelleenyrityksen pitäisi jatkaa epäonnistuneesta vaiheesta, ei toistaa kaikkia sitä edeltäneitä onnistuneita vaiheita.

Jos käännös onnistui ja push epäonnistui, säilytä tarkistettu käännös ja yritä pushia uudelleen. Jos Contentful päivitettiin ja julkaisu epäonnistui, yritä julkaisua uudelleen nykyistä entryn tilaa vasten.

Uudelleenkäynnistys käännöksestä voi tuottaa erilaista copya, mitätöidä tarkistuksen, lisätä kustannuksia ja peittää alkuperäisen ongelman.

Vaihetietoiset uudelleenyritykset pitävät onnistuneen työn vakaana.

Erota ohimenevät ja pysyvät epäonnistumiset

Jotkin epäonnistumiset ovat hyviä ehdokkaita automaattiselle uudelleenyritykselle:

• palveluntarjoajan aikakatkaisut
• nopeusrajoitukset
• lyhyet verkkokatkokset
• palautettavissa olevat versiokonfliktit

Toiset tarvitsevat ihmisen:

• virheellinen sisältökonfiguraatio
• puuttuva kielialueen käyttöönotto
• käyttöoikeuden epääminen
• suojattu rakenne, jota ei voida palauttaa
• kohdekenttä muuttui tarkistuksen jälkeen

Uudelleenyrityskäytännön pitäisi olla rajattu ja näkyvä. Kun automaattinen raja saavutetaan, pyyntö kuuluu ihmisten jonoon siten, että viimeisin hyödyllinen virhe säilyy.

Pidä epäonnistumislista kevyenä

Operointinäkymiä käytetään silloin, kun jokin on jo menossa pieleen. Niiden ei pitäisi käynnistää syvää CMS-hydraatiota jokaiselle riville eikä pollailla niin aggressiivisesti, että sivu aiheuttaa enemmän kuormaa kuin ne workerit, joita se valvoo.

Palauta ensin vakaa pyyntömetadata. Hae täydet entryn tiedot vasta, kun operaattori avaa pyynnön.

Nopea suodatus on osa palautumista.

Ydinajatus

Punainen badge ei ole palautusjärjestelmä.

Erota epäonnistumiset vaiheen mukaan, näytä vaikutuksen kohdealue ja yritä uudelleen vain sitä toimintoa, joka epäonnistui. Automatisoi ohimenevä palautuminen selkeiden rajojen puitteissa ja säilytä toiminnalliset virheet kaikkea muuta varten. Tiimit voivat sietää yksittäisiä epäonnistumisia, kun työnkulku tekee seuraavasta päätöksestä ilmeisen.