Vilken typ av lokaliserings-teknikstack behöver jag?

Vilken typ av Localization Tech Stack behöver jag?

Innan vi besvarar den här frågan ska vi ta upp paradigmklyftan som finns inom frågan: paradigmet med processen först kontra paradigmet med programvaran först. Varje olika paradigm kommer att resultera i olika svar och logiska skäl för dessa svar. Låt oss börja med att definiera dessa paradigm.

Det process-första paradigmet

Det process-första paradigmet tar processen och etablerar den som en relativt oföränderlig självklarhet. Sökandet är efter en teknisk stack som passar bäst för processen. Processen bryts vanligtvis ner i mindre komponenter och varje komponent mappas sedan till en slags programvara.

I det processinriktade tillvägagångssättet börjar personer inom lokalisering vanligtvis med att ange sin process som sina krav. Men denna process-först-ansats har också en stor klyfta: människor som börjar bygga sin teknikstack från grunden och människor som redan har system för flera av sina processer på plats.

Låt oss börja med att undersöka personer som bygger från grunden och antar att de har minst ett CAT (datorstödd översättning) verktyg till sitt förfogande. Så låt oss till exempel börja med den här processen som ett exempel:

1. Intressenter begär via e-post
2. Projektledare träffar intressenter angående krav
3. Projektledare förbereder tillgångarna för offerter
4. Projektledare laddar tillgångarna på CAT-verktyget
5. Projektledare laddar ner loggfilen och skapar en offert baserat på loggfilen
6. Intressenter godkänner offerten
7. Projektledare förbereder tillgångar och skickar filer, översättningsminne, och ordlista till översättare
8. Översättare slutför uppgiften i sina egna CAT-verktyg
9. Översättare skickar filer tillbaka till projektledare
10. Projektledare QA tillgångar
11. Projektledare levererar tillbaka tillgångar till intressenter

Det är vanligt att människor delar upp sin process i kategorier: affärsledning, översättningshantering, bokföring, kommunikation, kvalitetsledning, kopplingar. I det här sammanhanget är CAT-verktyget den grundläggande programvarukomponenten i vilken teknisk stack som helst. Utan det kommer du inte att kunna utnyttja kunskap i form av översättningsminne och termbaser.

Paradigmet "software-first"

Paradigmet "software-first" tittar först på de olika programvaror som finns på marknaden och försöker sedan bygga ut en effektiv process som utnyttjar vad varje programvara gör.De andra teknikstackkomponenterna är vanligtvis lagda på CAT-verktyget. En stor uppgradering skulle till exempel vara att lägga till ett affärshanteringssystem som Plunet eller XTRF för att hålla koll på de olika fordringarna och skulderna i varje projekt samt projektstatus, ägarskap, leverantörer etc. Du kan sedan överväga att lägga till en kvalitetsledning som Content-quo, du kan använda middleware-programvara för att integrera dina kopplingar, lägga till ett bokföringsprogram som Xero eller Quickbooks och voilà! Du är klar. Bokstavligen klar. Du har nu en teknisk stack, men frågan kvarstår: vilket är det enklaste och mest effektiva sättet att hantera dina översättningar på ett förutsägbart sätt? Med alla dessa olika programvaror tittar du på:

• Höga licensavgifter,
• mycket ingenjörsmässig omkostnader för att hålla alla dessa olika plattformar fungerande,
• mycket fram och tillbaka med olika supportteam och
• den intensivt frustrerande processen att försöka koppla ihop system som i grunden inte var gjorda för att kopplas ihop med varandra.

Lektion #1

Att ha en programvarustack som täcker alla dina behov av användningsfall från en funktion kontra kompatibilitet med användningsfall garanterar inte att du kommer att ha en effektiv programvaruinfrastruktur på plats. Att hålla det enkelt, smidigt och lätt att hantera har en enorm inverkan på din övergripande hantering över tid. Som en utveckling från denna paradigm väljer många företag att använda ett hanteringssystem för översättning som Memsource, MemoQ, Trados eller andra. Och även om Translation Management-system är utmärkta och erbjuder en mer sömlös integration med översättare, translation memories, projektledare och klienter, är du fortfarande fast med den återstående teknikstacken som inte kommer att bli föråldrad. Och här kommer det:

Lektion #2

Det finns en avgrund mellan programvara som är avsedd att automatisera kontra att anpassa. De flesta jag möter letar efter programvara som passar ett användningsfall. De kommer följaktligen vanligtvis att kräva en kombination av olika programvaror för att tillgodose de olika dimensionerna av deras användningsfall och viktigast av allt, de kommer att föredra programvara med många anpassningsbara fält och flexibilitet för datainmatning. Till exempel:

• Jag vill ha ett fält för min översättares t-shirtstorlek
• Jag vill ha ett fält för min klients födelsedag
• Jag vill kunna ange olika priser för helgen och natten
• Jag vill kunna ta betalt per ord, per mening och per stycke

Du fattar. Du kan bli galen över vad du vill att din programvara ska anpassa sig till och på många sätt skulle du ha rätt i att göra det. Men å andra sidan kan du ompröva relevansen av alla dessa krav och fokusera på de mest grundläggande och abstrakta begreppen som du försöker uppnå, till exempel:

• Minimera time-to-market
• Minimera mänsklig inblandning
• Maximera kundengagemanget
• Maximera Kvalitetsstyrningsverktyg

När du ser på den större bilden bleknar de hårda specifika kraven ut till mjukare och svagare idéer som inte längre är hårda krav. Bilden ändras sedan och en programvara som Bureau Works blir mycket tilltalande.

Föda fram det nya

Bureau Works byggdes för att hantera hela lokaliseringsarbetsflödet, inklusive:

• Offerter/scoping,
• Översättningsminne,
• Innehållshantering,
• Automatisk jobbdistribution till översättare och andra relevanta parter,
• Skulder och fordringar,
• Kvalitetsledning.

Du kan ersätta 5 olika programvarukomponenter med Bureau Works:Hejdå, hanteringssystem för översättning, hejdå Business Management System, hejdå Kvalitetsledning, Hej Bureau Works! :)Självklart är Bureau Works, även om det är integrerat över olika användarbehov, inte en universallösning för alla dina problem. Det är bra om du letar efter ultimat effektivitet och inte vill arbeta med undantag efter undantag som regel. Som en automatisering-först mjukvara var Bureau Works utformad för att hålla fält och manuell datainmatning till ett absolut minimum. Så det är inte en bra programvara om du vill ha ett fält för din översättares favoritdjur eller om du vill manuellt lägga till så många fält som behövs. Det är inte heller en bra passform om du vill att dina översättare ska arbeta i vilket CAT-verktyg de föredrar (även om det är möjligt) och om du vill maximera ditt teams personalstyrka och behov av manuellt arbete.

Men det är egentligen vad det handlar om: varför?

Letar du efter programvara för att upprätthålla status quo eller letar du efter programvara som gör att du kan omforma hur du arbetar i grunden? Den här frågan förändrar allt. Även om den är skrämmande och till synes riskfylld, öppnar omdesignmetoden oändliga möjligheter om den obevekligt fullföljs. Det är också bra att behålla saker som de är och sätta ihop och lappa ihop ett lapptäcke av system för att täcka det användningsfallet.Det är som att bygga ett hus med tanke på tidigare krav kontra att bygga med tanke på framtida möjligheter. Även om jag inte tror att det finns ett kategoriskt korrekt tillvägagångssätt, handlar det om att ha klarhet i var man står så att man inte omedvetet hamnar någonstans i mitten.