Het vertalen van content: de vier basismodellen

Online bedrijven gaan in rap tempo internationaal, wat betekent dat het aanbieden van content in de moedertaal van uw klanten steeds belangrijker wordt. Stel dat u uw vertalingen wilt automatiseren met een vertaalmachine van Google Translate, SDL of Lionbridge. Of misschien wilt u content publiceren via een platform zoals Liferay, Sitecore of Adobe Experience Manager. Wat zijn uw belangrijkste uitdaging voor het implementeren van de vertaal-workflow of publicatie workflow van de vertaalde content? Om deze vraag te beantwoorden, moeten we eerst kijken hoe vertalingen worden verwerkt in content repositories.

 Vier modellen voor vertaling

In de loop der tijd hebben ontwikkelaars slimme oplossingen gezocht om vertaling in hun producten te implementeren. Er zijn vier modellen die het meest worden gebruikt:

Model 1: VrijstaandRoot blog image.png
Dit is het basismodel. In feite bestaat er helemaal geen echt model, het is gewoon gebaseerd op de naamgevingsconventie. Neem bijvoorbeeld een document op uw computer. Het is in het Engels geschreven, dus u slaat het op in een map met de naam "Engels". Vervolgens maakt u een vertaling in het Duits en slaat u dat document op in een map met de naam "Duits". Dit vertaalmodel is vrijstaand omdat er geen formeel mechanisme is om de vertalingen anders dan aan de hand van naamgeving op te slaan. Het vrijstaande model wordt informeel gebruikt in ECM-systemen in veel organisaties, maar is ook te vinden in veel WCM-producten.

Model 2: Gekoppeldroot blog2.png
Net als bij het vrijstaande model, is er nog steeds geen formeel mechanisme voor het omgaan met vertalingen. Het systeem slaat echter wel informatie over documenten op in de vorm van metadata. Het systeem slaat bijvoorbeeld de taal van het document op en heeft de mogelijkheid om een "translationOf" -relatie met andere documenten toe te voegen. Het gekoppelde model is populair in ECM- en WCM-systemen die oorspronkelijk helemaal geen vertalingen ondersteunden. Zij hebben nu slimme manieren gevonden om hun metadatamodel te gebruiken om vertalingen beter te ondersteunen.

Model 3: EmbeddedRoot blog 3.png
Het embedded model introduceert als eerste een formele benadering voor vertaling op API-niveau. De API kan CRUD-bewerkingen (Create, Read, Update, Delete) uitvoeren op vertalingen van een document. In dit model wordt elke vertaling nog steeds beschouwd als een stand-alone document. De formatting van de content en de beschikbaarheid van metadata kunnen per vertaling verschillen. Dit model komt het meest voor bij systemen die native support bieden voor vertalingen.

Model 4: Transparantroot blog 4.png
Het vierde model is ook het meest geavanceerde model. Naast volledige API-ondersteuning, wordt vertaling ook daadwerkelijk verwerkt op basis van per-veld/per-contentsegment. Vertaling is in wezen transparant voor de gebruiker; alle content en metadata is onderling uitwisselbaar tussen vertalingen en volgt dezelfde conventies en kwaliteitsregels. U zult merken dat dit model vaak wordt gebruikt in meer geavanceerde systemen, zoals bijvoorbeeld digitale publicatieplatforms, product informatie management en datamanagementproducten.

Bouw uw integratieoplossing
De dagelijkse problemen waarmee uw ontwikkelaars te maken hebben, zijn op het niveau van hoe om te gaan met: vertaalde metadata zoals titel en trefwoorden; locatie specifieke afbeeldingen; en het uniform formatteren van content in verschillende vertalingen.

De sleutel tot een succesvolle implementatie zit hem in het vroeg herkennen van het onderliggende vertaalmodel en begrijpen hoe u dit in uw vertaal-workflow of publicatie-workflow kunt verwerken.

Vergeet daarnaast niet om onze Xillio API te bekijken, die met alle genoemde vertaalmodellen kan omgaan en volledig transparant is voor de ontwikkelaar.
Share this post on

Comments

Subscribe to email updates

Recente posts