Maskinöversättning är idag så bra att man i många fall inte längre kan skilja den från mänsklig översättning. Översättningstjänsterna fungerar smidigt, idiomatiskt och med känsla för språkligt register. Men när man översätter en DPP-datauppsättning blir plötsligt ”rear lock fiber closure” till ”Hinterschloss-Faserverschluss”.
Problemet heter fackterminologi. Här förklarar vi varför produktdata inte ska behandlas som romaner och vilka verktyg Transpareo tillhandahåller för att dina 39 språkversioner ska förbli begripliga.
Grundproblemet: ett ord, flera betydelser
”Seal” i DPP-data för en friluftsjacka: tätning. ”Seal” i ett laboratorium: säl eller tätning, beroende på sammanhanget. ”Seal” i ett underhållsprotokoll: under vissa omständigheter ett sigill.
En allmän översättningsmodell väljer utifrån det statistiska sammanhanget. I en flytande text fungerar det - romanen ger rikligt med sammanhang. I ett datafält primary_closure: seal finns det knappt något sammanhang. Modellen gissar.
Följden blir subtila fel. Inte lika dramatiska som ”Hinterschloss-Faserverschluss”, men med stora konsekvenser: en komponent som på tyska kallas ”Dichtung” heter plötsligt ”sigillo” istället för ”guarnizione” i ett italienskt DPP. En inköpare kan inte längre hitta reservdelen.
Vad Transpareo erbjuder idag
Vårt översättningssystem överför automatiskt allt nytt innehåll till alla aktiva språk. Fyra egenskaper kännetecknar det:
-
Bevarande av Markdown och variabler: Platshållare som
<a href="/sv/registrera sig">Pro-Mitgliedschaft</a>och Markdown-strukturer extraheras före översättningen, själva texten översätts och därefter återinsätts strukturerna oförändrade. På så sätt förblir länkar, formulär och layout konsekventa på alla språk. - Centrala översättningsposter: Översättningarna sparas inte i själva dataposten utan i ett gemensamt lager. Flera dataposter med samma originaltext delar på en översättning. Detta sparar översättningskostnader och standardiserar automatiskt termerna över hela datamodellen.
- Automatisk omöversättning vid ändring: Om originaltexten ändras genereras översättningarna på nytt i alla språk. En korrigering på tyska - 38 andra språkversioner följer automatiskt.
- Markeringar per datapost: Innehåll kan undantas från den automatiska processen eller befintliga översättningar kan låsas - till exempel för internationella produktnamn eller manuella korrigeringar.
Där kunden kompletterar bearbetningen
Den automatiska översättningen ger till stor del korrekta resultat för beskrivande texter, marknadsföringstexter och skötselanvisningar. När det gäller kritisk fackterminologi - som ”seal”/”guarnizione” - kvarstår en viss mängd fel som kundens administratör måste korrigera.
Här har administratören tre verktyg:
- Manuell överskrivning per språk och nyckel: Varje översättningspost kan öppnas i Applikationshanteraren och anpassas per språk. Med markeringen ”Spara” behålls denna manuella översättning vid nästa automatiska körning.
- Import av ordlista: Befintlig terminologi från översättningsverktyg eller PDF-ordlistor kan importeras som CSV-fil och genererar direkt skrivna översättningsposter.
- Språkspecifika korrigeringar under drift: En italiensk säljare upptäcker ett fel, korrigerar det i Application Manager - korrigeringen träder i kraft omedelbart, medan övriga översättningar förblir oförändrade.
Verkligheten bakom EU:s språk
24 officiella EU-språk låter mycket. I praktiken finns det tre nivåer:
- Kärnmarknader: DE, EN, FR, IT, ES, NL - här förväntar sig varje konsument perfektion
- Betydande marknader: PT, PL, SV, DA, FI - bra nivå, ibland märks det att översättningen är maskinöversatt
- Sällsynta språk: MT, GA, ET, LV, LT - ibland har man en DPP på maltesiska utan att någon slutkonsument på Malta någonsin skannar den. Ändå är det obligatoriskt.
Kravet är inte valfritt. ESPR kräver att DPP-innehållet finns på språket i den medlemsstat där produkten säljs. Den som betjänar 27 stater har alltså 24 språk att hantera (vissa delar språk).
Varför en centraliserad lokaliseringsnivå
De flesta plattformar lagrar översättningar som extra fält i dataposten: description_de, description_en, … 39 fält per översättningsbart attribut. Det låter enkelt, men har tre nackdelar:
- Dubbeltext. Två produkter med samma materialangivelse genererar 39 + 39 översättningar istället för en enda gång 39
- Svårt att skala upp. Att lägga till ett 40:e språk innebär: schemamigrering över alla översättningsbara modeller
- Korrigeringar är svåra att tillämpa globalt. Om ”guarnizione” korrigeras överallt måste alla dataposter redigeras en och en
Det delade översättningslagret löser detta: en post, många referenser. En korrigering, alla dataposter drar nytta av den.
Vad vi ännu inte har
En kundspecifik terminologidatabas med automatisk förslagsigenkänning finns med i utvecklingsplanen, men är ännu inte tillgänglig. Den som börjar idag kommer långt med de befintliga verktygen: manuella överskrivningar, import av ordlistor och markeringen ”bevara” täcker de vanligaste användningsfallen.
Vi anser att maskinerna bör sköta huvuddelen av arbetet och att människor endast ska ingripa där det verkligen behövs. Tills den automatiska terminologigenkänningen är tillgänglig är den manuella funktionen transparent - och det är ärligare än ett löfte som inte infrias.