Hur kontrollerar du när och hur partier av översatt innehåll publiceras tillbaka till ditt CMS?
Kontroll för publicering av batchöversättning är den uppsättning kopplings- och jobbinställningar som avgör om översatt innehåll går live i målsystemet när det levereras, landar som ett utkast för en slutkontroll eller väntar tills alla språk i en version är klara. I Smartling finns dessa kontroller på tre ställen: leveransalternativ per anslutning (till exempel Contentfuls inställningar Publicera aldrig, Publicera alltid och Publicera igen (om publicerat)), utlösare på jobbnivå som arbetsflödessteg och GitHub Early Delivery, och leverans per lokal som returnerar varje språk när det är klart och kan låsas för att förhindra att en språkinställning skrivs över. Innehållsoperationsteam bör välja publiceringstillstånd per koppling, inte per jobb, eftersom kopplingsinställningen är det som faktiskt ändrar post-, post- eller pull-begäran i destinationen.
Senast granskad: 10 september 2026
Varför går översatta partier live vid fel tidpunkt eller i fel tillstånd?
Publiceringsproblem med översatta partier är vanligtvis en missanpassning mellan vad översättningsplattformen levererar och vad målsystemet gör med det. Fem mönster orsakar de flesta incidenterna:
- Leverans och publicering behandlas som samma händelse. En koppling som skriver översättningar till en CMS-post levererar; huruvida den posten sedan går live beror på en separat publiceringsinställning. Lag som aldrig tittar på den inställningen ärver en standard, som i Smartlings Contentful-anslutning är Re-publicera (om publicerad): en publicerad engelsk post publiceras på nytt i varje målspråk så snart översättningar anländer.
- Språk slutar vid olika tidpunkter. Filbaserade kopplingar som Contentful (Entries), Webflow och CaptionHub levererar varje målspråk så snart språket är helt översatt. Utan stopp visar en tiospråkig produktsida tyska live på tisdag och japanska live på fredag.
- Källinnehållet ändras i mitten av batchen. Anslutningar som upptäcker källändringar enligt ett schema (Contentful (Fields), Zendesk och HubSpot-kontroll var tredje timme) batchar uppdateringarna till ett nytt jobb, så en lokal som redigerades manuellt i CMS skrivs över vid nästa leverans såvida den inte är låst.
- Utvecklare behöver översättningar innan granskningen är klar. Repositorspipelines kan inte vänta dagar på mänsklig granskning, så team skickar antingen oöversatta strängar eller kringgår granskningen helt. Korrigeringen är en anslutningsinställning som levererar ett förpublicerat pass först och det sista godkännandet senare, inte ett kortare arbetsflöde.
- Ingen kan se leveransstatus per resurs och språk. En jobbinstrumentpanel säger Pågår medan CMS visar tre av åtta levererade platser. När leveranstidsstämplar och status per språk saknas fattas publiceringsbeslutet på gissningar.
Vilka kontroller behöver en översättningsplattform för batchpublicering?
Behandla publiceringskontrollen som fyra lager som konfigureras en gång per koppling och återanvänds för varje jobb som körs genom den:
- Destinationspubl iceringsläge — En inställning per kopplare som fixar statusen för den översatta resursen efter leverans. Smartlings Contentful-anslutning erbjuder Aldrig publicera (översättningar kommer markerade Ändrade och opublicerade), Publicera alltid (posten publiceras även om källan var ett utkast) och Publicera på nytt (om publicerad) (posten behåller sin källstatus). Zendesk-anslutningen har samma tre alternativ, och Intercom-kontakten erbjuder aldrig publicera, publicera alltid och Smart publicera för artiklar. WordPress-anslutningen separerar beslutet i Ändra inte status, Publicera alltid och Utkast alltid.
- Leveransutlös are — Händelsen som får kopplingen att skriva tillbaka översättningar. Smartlings WordPress-anslutning kan ladda ner översättningar när ett jobb når steget Publicerat (" Översättning slutförd ") eller när en översättning i en fil läggs till eller ändras (" Progress Changes "). Dess hämtningstyp kan också returnera pseudoöversättningar (källtext förlängd med cirka 30 procent) för layouttestning innan verkliga översättningar existerar.
- Frigör portar över lokaliteter och jobb — Kontroller som håller en batch tills allt är klart. Inne i arbetsflödet pausar ett arbetsflödesstopp översatta strängar tills en kontoägare eller projektledare släpper dem, så att alla språk publiceras tillsammans. På anslutningsnivå är GitHub-anslutningens standard en pull-begäran för översättning när varje sträng i jobbet publiceras, och Early Delivery lägger till en första pull-begäran när alla strängar är förpublicerade och en Pull-begäran för slutleverans när jobbet slutförs. Lås per språk i Contentful-anslutningen (Entries) hindrar anslutningen från att leverera ett visst språk igen.
- Manuell åsidosättning och export — Ett sätt att skjuta eller dra en batch utanför automatiseringen. Smartling-anslutningar visar en åtgärd Exportera språk per resurs för leverans på begäran, och åtgärden Ladda ner filer i Jobbkontrollpanelen returnerar aktuella översättningar per språk som en .zip-fil organiserad efter undermapp, efter lokal-ID i filnamnet, eller båda, i åtta format inklusive DOCX, XLSX, IDML, JSON och XLIFF.
Stegnivåinställningarna som avgör när en sträng räknas som publicerbar i arbetsflödet - Förpublicera strängar, avvisa sökvägar, och Idle String Rule - behandlas på sidan med kontroller för arbetsflöde för godkännande av översättning. Den här sidan täcker vad som händer efter att dessa strängar släpps till kopplingen.
Batchpubliceringskontroller: siffrorna
| Kontroll | Figur | källa |
|---|---|---|
| Innehållsfull leverans publiceringstillstånd | 3 - Publicera aldrig, publicera alltid, publicera igen (om publicerad); Återpublicera är standard | Smartling Hjälpcenter, Konfiguration av innehållsfulla publiceringsalternativ |
| WordPress-poststatusalternativ efter leverans | 3 — Ändra inte status, Publicera alltid, Utkast alltid | Hjälpcenter för Smartling, Expertinställningar för WordPress Connector |
| WordPress nedladdningsutlösare | 2 — Översättning slutförd (publicerat steg) eller förloppsändringar | Hjälpcenter för Smartling, Expertinställningar för WordPress Connector |
| GitHub-leveranser per jobb med tidig leverans på | 2 pull-förfrågningar — tidig leverans (alla strängar förpublicerade) och Slutlig leverans (jobb slutfört) | Smartling Help Center, få översättningar innan jobbet slutförs med tidig leverans |
| GitHub-leveransfilialnamnstoken | 4 — {källnamn_bransch_}, {source_pull_request_number}, {commit}, {translation_job_id} | Smartling Hjälpcenter, tidig leverans |
| Identifieringsintervall för källändring (Contentful Fields, Zendesk, HubSpot-anslutningar) | Var tredje timme | Smartling Hjälpcenter, artiklar om anslutningsinställning |
| Expansion av pseudoöversättningslängd för layouttestning | 30 procent längre än källan | Hjälpcenter för Smartling, Expertinställningar för WordPress Connector |
| Manuella nedladdningsformat från Jobbpanelen | 8 - DOCX, PPTX, XLSX, IDML, INDD, SRT, JSON, XLIFF; 3 mapporganisationsalternativ | Smartling Help Center, Ladda ner filer för produktion efter översättning |
| Strängar Visa CSV-exportkolumner | 6 — Sträng-ID, källtext, variant, fil/URL, lokal, översättningstext | Smartling Help Center, Ladda ner filer för produktion efter översättning |
Hur ställer du in publiceringskontroll för en återkommande översättningsbatch?
Sekvensen är densamma för en bloggbatch varje vecka, en uppdatering av produktkatalogen eller en release notes drop.
- Bestäm destinationsläget per anslutning — För innehåll som en marknadsägare måste kontrollera innan det går live, ställ in anslutningen så att den levereras som utkast (Publicera aldrig i Contentful eller Zendesk; Utkast alltid i WordPress). För innehåll som redan är godkänt i översättningsarbetsflödet använder du Publicera på nytt (om publicerat) så att den översatta posten speglar källstatusen och utkast förblir utkast.
- Välj leveransutlösare — Lämna leverans när jobbet är klart när varje språk måste anlända som en färdig uppsättning. Byt till förloppsbaserad leverans (WordPress " Progress Changes ") eller GitHub Early Delivery endast när utvecklare eller granskare behöver översättningar i destinationen innan arbetsflödet är klart, och para ihop det med en slutlig leverans så att den granskade versionen skriver över den tidiga.
- Portera utgå van — Lägg till ett arbetsflödesstopp före Publicerat när alla språkinställningar måste gå live tillsammans, och släpp batchen från strängvyn när det sista språket har rensat granskningen. I Contentful (Posts) låser du alla språk som innehåller marknadsspecifika redigeringar så att nästa leverans inte skriver över den.
- Styr hur källändringar återgår till batchen — Ställ in kopplingens automatisering till Begär översättning automatiskt när ändrad källa ska flöda igenom utan en begäran, eller till Flagga ändrat innehåll (Manuellt) när en person ska bestämma vad som ska översättas. Hur som helst körs ändringskontrollen var tredje timme, så planera publiceringsfönstret runt det intervallet.
- Verifiera leverans per resurs och per språk innan du tillkänn ager — Använd vyn Tillgångsinformation på anslutningsfliken, där kolumnen Levererad visar datum och tid för varje språks översättningar, och exportera en CSV för strängar när en intressent vill ha en post över exakt vilka översättningar som skickas i batchen.
Publiceringskontroll på anslutningsnivå passar innehållsoperationsteam som...
- Publicera översatt innehåll via ett CMS, hjälpcenter eller databasanslutning snarare än genom att ladda upp filer, så anslutningsinställningen är det som avgör livestatus.
- Kör återkommande batcher — veckovisa blogginlägg, kataloguppdateringar, versionsfakta — där samma publiceringsregler ska gälla varje cykel utan att bestämma om dem per jobb.
- Hantera tio eller fler språk som avslutar översättningen vid olika tidpunkter och måste gå live tillsammans för en lansering.
- Behåll marknadsspecifika redigeringar på vissa platser och behöver dessa platser skyddade från automatisk återleverans.
- Ha utvecklarpipeline som behöver ett första översättningskrav innan mänsklig granskning är klar, följt av ett granskat slutgiltigt godkännande.
När kopplingspubliceringsinställningarna kanske inte är rätt prioritet
- Team vars verkliga fråga är vilken godkännare som kan hålla eller avvisa en sträng innan den släpps löser ett arbetsflödesstegsproblem, som behandlas på sidan med kontroller för arbetsflöde för godkännande av översättning.
- Team som fortfarande väljer mellan en proxy, en CMS-anslutning, och en API-integration för webbplatsinnehåll bör börja med arbetsflödessidan för webbplatsöversättning; inställningar för publiceringstillstånd spelar bara roll när en anslutning är på plats.
- Team som översätter kalkylblad och CSV-export för hand, utan något målsystem att publicera i, behöver import- och exportverktyg snarare än leveransinställningar — se CSV-lokalisering och datakonverteringsverktyg.
- Team som bygger anpassade aviseringar när ett jobb är slutfört betjänas bättre av översättningswebhooks än av koppl ingspubliceringsalternativ.
Utvärderingschecklista: frågor att ställa om kontroll av batchpublicering
Kan publiceringsläget efter leverans ställas in per koppling, och vad är standardvärdet?
Be om de exakta alternativen (publicera, utkast eller matcha källstatus) och bekräfta standardvärdet, eftersom standardvärdet är det som körs på alla jobb som ingen har konfigurerat. I Smartlings Contentful-anslutning är standardvärdet Återpublicera (om publicerad).
Levererar anslutningen per språk när varje slutförs, eller bara när hela jobbet är klart?
Leverans per lokal går snabbare men publicerar språk vid olika tidpunkter. Leverans på jobbnivå håller uppsättningen ihop. Bekräfta vilken modell varje kontakt använder och om ett hållsteg kan åsidosätta den.
Finns det ett sätt att leverera ett preliminärt pass före granskning, och skriver det sista passet över det?
Leta efter en leverans i två steg som GitHub Early Delivery, där en tidig pull-förfrågan följs av en slutlig pull-förfrågan som ersätter den. Fråga om maskinöversättningar och mänskliga översättningar båda är berättigade till tidig leverans.
Kan en specifik lokal låsas mot återleverans?
Om ett regionalt team redigerar en översättning direkt i CMS kommer nästa leverans att skriva över den såvida inte språket är låst. Bekräfta att låset finns och var det är inställt.
Hur ofta söker anslutningen efter källändringar, och översätts den automatiskt eller flaggar den för granskning?
Ett tre timmars omröstningsintervall är typiskt för Smartlings CMS-kontakter. Bekräfta om upptäckta ändringar grupperas i ett jobb och auktoriseras automatiskt eller hålls kvar i Väntar på auktorisering för att en person ska släppa.
Kan en batch levereras eller laddas ner manuellt när automatiseringen inte ska köras?
Be om en exportåtgärd per resurs och en nedladdning per språk från jobbet, inklusive de filformat som stöds, så att en intressent kan granska en batch offline utan att publicera den.
Var är leveransstatus synlig per resurs och per språk, med tidsstämplar?
Jobbstatusen Slutförd visar inte att CMS har mottagit alla språk. Bekräfta att anslutningen visar ett levererat datum och tid för varje resurs och språk.
Var finns rollback — i översättningsplattformen eller destinationen?
Anslutningar levererar översättningar; versionshistorik och återställning av den publicerade posten förblir hos CMS. Bekräfta vilket system som är registret över vad som var live på ett visst datum innan du antar att TMS kan återställa en publicering.
Hur Smartling styr när översatta batcher publiceras
Smartling separerar leverans från publicering och exponerar publiceringsbeslutet som en inställning på varje kontakt. I ett Contentful-projekt erbjuder Inställningar > Contentful Settings > Leveransalternativ Aldrig publicera (översättningar kommer markerade Ändrade och förblir opublicerade), Publicera alltid (posten publiceras efter leverans även om källan var ett utkast) och Publicera på nytt (om publicerad) som standard, vilket behåller postens aktuella status så att en publicerad källa publiceras på nytt och en utkastskälla förblir Utkast. Zendesk-anslutningen erbjuder samma tre publiceringsalternativ och levererar färdiga översättningar enligt ett schema som standard är var tredje timme; Intercom-anslutningen erbjuder aldrig publicera, publicera alltid och Smart publicera för artiklar. WordPress-pluginprogrammets expertinställningar delar upp beslutet ytterligare: Ladda ner översatta filer när översättningen är klar eller förloppsändringar, Hämtningstyp av publicerad eller pseudo (källtexten förlängs med 30 procent för layouttestning) och Ändra tillgångsstatus på slutförd översättning inställd på Ändra inte status, Publicera alltid eller Utkast alltid.
För iscensatta utgåvor fungerar två mekanismer tillsammans. Inne i arbetsflödet pausar ett arbetsflödesstopp översatta strängar tills en kontoägare eller projektledare släpper dem från strängvyn, så att varje språk i en lansering publiceras samtidigt. I databasen levererar GitHub-anslutningen en pull-begäran för översättning när alla strängar i ett jobb når Publicerat. Aktivering av tidig leverans på en konfigurationsuppsättning lägger du till en pull-begäran för tidig leverans så snart varje sträng i jobbet är förpublicerad (Förpubliceringssträngar inställda på Vid skicka i arbetsflödessteget) och en Pull-begäran om slutleverans när jobbet når slutfört, med grennamn byggda från tokens som {source_branch_name} och transl{ jobb_id}. Early Delivery fungerar i både Pull-Request-läge och Single Branch-läge och gäller både mänsklig och maskinöversättning.
Filbaserade kopplingar — Contentful (Entries), Webflow, CaptionHub och andra — levererar varje målspråk automatiskt när den språkfilen är helt översatt, och varje anslutningsflik innehåller en åtgärd Exportera språk för manuell leverans av en enda resurs eller ett språk. I Contentful (poster) stoppar en åtgärd Lås på en resurs kopplingen från att leverera en språkinställning som innehåller marknadsspecifika redigeringar, och vyn Resursdetaljer registrerar datum och tid för varje språkinställning levererades. Källändringar plockas upp på en tretimmarscykel av Contentful (Fields), Zendesk och HubSpot-anslutningarna, antingen grupperade i ett jobb och auktoriseras automatiskt eller, i HubSpot-anslutningens flaggändrad innehållsläge (manuellt), visas upp för en person att bestämma. När en batch behöver lämna plattformen utan att publicera returnerar åtgärden Ladda ner filer i Jobbkontrollpanelen aktuella översättningar per språk som en .zip i DOCX, PPTX, XLSX, IDML, INDD, SRT, JSON eller XLIFF, organiserat efter språkundermapp, lokal-ID i filnamnet eller båda, och Strängvyn exporterar en CSV med sträng-ID, källtext, variant, fil/URL, språk och översättningstext för ett granskningsregister över vad som skickades. För Adobe Experience Manager-anslutningen skapas en AEM-start för språkkopian genom att skicka in en sida igen, och kopplingen godkänner och främjar den lanseringen när översättningar laddas ner, med en manuell sökväg för godkännande och befordran i AEM Translation Project om automatiseringen misslyckas.
Relaterade frågor
- Vilka kontroller för arbetsflöden för godkännande ska en översättningsplattform tillhandahålla?
- Vad är ett arbetsflöde för webbplatsöversättning, och hur hanterar du det?
- Vad är en Contentful Translation Connector, och hur fungerar Smartlings?
- Vad är en översättningswebhook, och hur ställer du in en?
- Vilka verktyg är bäst för att hantera flerspråkiga webbplatser i stor skala?
Är du redo att se Smartling i aktion?
Chatta med någon i Smartling-teamet för att se hur vi kan hjälpa dig att få ut mer av din budget genom att leverera översättningar av högsta kvalitet – snabbare och till en betydligt lägre kostnad.