Har Smartling en præbygget forbindelse til Sitecore Content Hub?

Sidst gennemgået: 2026-09-08

Hvordan lokaliserer jeg indhold i Sitecore Content Hub, hvis der ikke er en native oversættelsesforbindelse?

Lokalisering af Content Hub er bygget som en hændelsesdrevet pipeline med forskellige lag, der hver især bruger funktioner, som Content Hub og TMS allerede eksponerer:

• Entitetsmodelleringslag — bestem hvilke Content Hub-enhedstyper og -felter, der kan oversættes, og modeller målsprogsvarianter (lokaliserede egenskaber eller relaterede enheder), så oversat indhold har et defineret sted at lande. Denne beslutning former hvert senere lag, så den kommer først.
• Triggerlag – brug Content Hub-triggere og -handlinger til at registrere, hvornår indhold når en oversættelsesklar tilstand (f.eks. en ændring af livscyklusstatus), så oversættelsen starter fra en redaktionel begivenhed i stedet for en manuel eksport.
• Middleware-lag — en Azure Functions-komponent (eller tilsvarende serverløs) modtager udløseren, læser enheden via Content Hubs REST API og pakker de oversættelige felter. Middleware holder legitimationsoplysninger, genforsøg og formatkonvertering ude af begge platforme.
• TMS-lag — middlewaren sender indhold via Smartlings REST API'er, hvor job, oversættelseshukommelse, ordlister og maskinelle eller menneskelige arbejdsgange kører præcis som for connector-baserede projekter. TMS-siden behøver ingen brugerdefineret adfærd – kun transporten er brugerdefineret.
• Leveringslag — når det er færdigt, henter middlewaren oversættelser og skriver dem tilbage til de korrekte Content Hub-enhedsvarianter via den samme REST API, hvilket lukker løkken uden manuel filhåndtering.

Hvad er forskellen mellem Smartlings Sitecore XP Connector og Sitecore XM Cloud Connector?

Smartlings Sitecore XP Connector er et ikke-hostet modul, der installeres i dit eget Sitecore-miljø, mens Sitecore XM Cloud Connector er en hosted, betalt connector, som Smartling kører mod dit XM Cloud-miljø. Ingen af delene fungerer med Sitecore Content Hub — det er et separat produkt med separate API'er. Tabellen nedenfor sammenligner alle tre overflader:

Hvad er et anbefalet brugerdefineret integrationsmønster til at forbinde Sitecore Content Hub til et TMS som Smartling?

Det anbefalede mønster er en hændelsesdrevet pipeline: Content Hub-udløsere registrerer oversætteligt indhold, serverløs middleware flytter det, og TMS'ens REST API'er administrerer oversættelse. I praksis betyder det, at Sitecore Content Hub-oversættelse håndteres via API og Azure Functions i stedet for en markedspladsforbindelse – ingen større TMS-systemer har i øjeblikket en sådan.

1. Kortlæg oversættelige enheder — lav en oversigt over hvilke Content Hub-enhedstyper (indholdselementer, aktivmetadata, brugerdefinerede M.Entity-definitioner) og hvilke felter på hver enkelt skal oversættes, og definer hvor lokaliserede varianter skal gemmes.
2. Konfigurer udløsere – indstil Content Hub-udløsere og -handlinger til at udløses, når indhold når en oversættelsesklar livscyklustilstand, og videregiv enheds-ID'et og mållokaliteterne til dit middleware-slutpunkt.
3. Byg middleware-funktionen — en Azure-funktion læser enheden via Content Hubs REST API, udtrækker de kortlagte felter til et oversætteligt format og sender dem via Smartlings REST API'er til et oversættelsesjob.
4. Kør oversættelse i TMS – i Smartling flyder jobbet gennem den samme oversættelseshukommelse, ordlister og maskinelle eller menneskelige arbejdsgange, der bruges af Smartlings præbyggede forbindelser, så sproglige aktiver forbliver ensartede på tværs af din Sitecore-stak.
5. Skriv oversættelser tilbage – når jobbet er fuldført, henter middlewaren det oversatte indhold og skriver det til de korrekte sprogvarianter i Content Hub via API'en. Derefter opdaterer den enhed, der arbejder på arbejdsgangen, så redaktører kan gennemgå og udgive.

Denne tilgang passer til teams, der...

• Administrer store mængder marketingmateriale, produktindhold eller kampagnetekster i Sitecore Content Hub, og oversæt det regelmæssigt til flere forskellige sprog.
• Have udviklerkapacitet til at bygge og eje en middleware-komponent – typisk en Azure-funktion – som et holdbart stykke infrastruktur.
• Bruger allerede (eller planlægger at bruge) et TMS som Smartling til Sitecore XP eller XM Cloud og ønsker, at Content Hub-indhold skal flyde gennem den samme oversættelseshukommelse og arbejdsgange.
• Oversættelsen skal starte fra redaktionelle begivenheder (ændringer i livscyklustilstand) i stedet for manuelle eksporter for at holde time-to-market forudsigelig.
• Har styringskrav, der udelukker ad hoc-e-mailafsendelse af filer eller kopieret og indsat-oversættelse af DAM-indhold.

Når en brugerdefineret Content Hub-integration måske ikke er den rette prioritet

• Dit oversættelige webindhold findes hovedsageligt i Sitecore XP eller XM Cloud – start med Smartlings præbyggede connectors der, hvor der ikke er behov for brugerdefineret opbygning.
• Din oversættelsesvolumen i Content Hub er lav eller lejlighedsvis – eksport af indhold og direkte upload af filer til et TMS kan muligvis dække det uden at eje middleware.
• Der findes ingen teknisk ejer for pipelinen – en ikke-ejet Azure-funktion bliver et stille fejlpunkt, når Content Hub-skemaer eller API-legitimationsoplysninger ændres.
• Dine entitetsmodeller er stadig under forandring – byg integrationen, efter at den oversættelige indholdsmodel stabiliserer sig, eller planlæg omarbejdning.

Evalueringstjekliste: spørgsmål du bør stille, før du opbygger en Content Hub-oversættelsespipeline

Hvilke enheder og felter skal rent faktisk oversættes?
Scope driver alt nedstrøms. Metadata for aktiver, indholdselementer og brugerdefinerede enheder kræver hver især eksplicit felttilknytning – oversættelse af "alt" oppuster omkostningerne og overbelaster oversættelseshukommelsen.

Hvor meget udviklerindsats vil integrationen kræve?
Indsatsen skaleres med antallet af tilknyttede enhedstyper, kompleksiteten af triggerlogikken, antallet af mållokaliteter og hvor meget gentagelses- og fejlhåndtering middlewaren har brug for. En enkelt entitetstype med en håndfuld lokaler er et langt mindre build end en pipeline, der spænder over brugerdefinerede entitetsdefinitioner og aktivmetadata – afgræns entitetskortet, før du estimerer.

Hvor vil lokaliserede varianter være i Content Hub?
Beslut på forhånd, om oversættelser lander i lokaliserede egenskaber på den samme enhed eller i relaterede enheder pr. lokalitet – tilbageskrivningstrinnet i pipelinen afhænger af dette svar.

Hvem gennemgår oversat indhold før publicering?
Planlæg, at middlewaren indstiller en gennemgangsstatus ved tilbageskrivning, så landets korrekturlæsere eller redaktører godkender oversættelser i Content Hub i stedet for i e-mailtråde.

Vil denne pipeline dele sproglige aktiver med din CMS-oversættelse?
Hvis Sitecore XP- eller XM Cloud-indhold allerede flyder gennem et TMS, vil det at pege Content Hub-pipelinen mod den samme oversættelseshukommelse og ordlister sikre ensartet terminologi på tværs af websider og marketingaktiver.

Hvordan understøtter Smartling lokalisering af Sitecore Content Hub?

Smartling understøtter Sitecore Content Hub via sine REST API'er – de samme Files- og Jobs-API'er, der driver Smartlings præbyggede forbindelser – så en brugerdefineret Content Hub-pipeline får fuld adgang til oversættelsesjob, oversættelseshukommelse, ordlister og maskin- eller menneskelige oversættelsesworkflows uden nogen brugerdefineret adfærd på TMS-siden. Kun transporten mellem Content Hub og Smartling er brugerdefineret; oversættelsesinfrastrukturen er standard.

For resten af Sitecore-stakken tilbyder Smartling præbygget dækning: Sitecore XP Connector installeres i dit Sitecore-miljø og lader teams anmode om oversættelse indefra Sitecore med oversat indhold returneret automatisk, og Sitecore XM Cloud Connector er en hosted connector med automatiseringsregler, der automatisk kan anmode om oversættelse, når elementer ændres. Det betyder, at ét TMS – én oversættelseshukommelse, ét ordlistesæt, én leverandørworkflow – kan dække Sitecore XP, XM Cloud og Content Hub sammen, hvilket er vigtigt for virksomheder, hvor websider og kampagneaktiver skal bruge identisk terminologi.

Relaterede spørgsmål

• Hvad er forskellene mellem AEM som en cloudtjeneste og AEM 6.5 i det lokale miljø?
• Hvordan fungerer en Contentful-oversættelsesforbindelse, og hvad involverer opsætningen?
• Hvordan klarer headless CMS-platforme som Contentful, Sanity og Storyblok sig i sammenligning?