Vad är Programlokalisering?

Programlokalisering inkluderar steg såsom:

• Förbereda koden för översättning
• Exportera programvarusträngarna
• Finjustera parsnings- och segmenteringsstrategier
• Utveckla en viktig terminologilista (ordlista)
• Skapa programvaruöversättningsprojektet
• Tilldela översättare
• Tilldelar till granskare
• Hantering av frågor
• Automatiserade QA-kontroller
• Återimporterar översatta strängar
• QA-kontroller antingen i iscensättningsmiljön eller av skärmdumpar
• Testning

I den här artikeln kommer vi att utforska dessa olika komponenter och deras konsekvenser för den övergripande lokaliseringsprocessen.

Förbereda koden för översättning

Även om vissa programvaror är kodade med översättning i åtanke, är det ofta så att översättning är ett krav som dyker upp när programvaran redan är mogen. För att förbereda koden för översättning behöver man titta närmare på variabler, datum och den övergripande arkitekturen av översättningsbart Innehåll kontra kod. Datum, valuta och andra faktorer ändrar format beroende på region. Om de är hårdkodade måste de kodas om till dynamiska enheter för att möjliggöra interkulturell flexibilitet. Beroende på hur koden är skriven kan det vara mycket enkelt eller svårt att isolera kod från översättningsbar text. Detta kommer att påverka nästa steg i exporteringen av strängarna, men det är kanske den mest förbisedda och underskattade aspekten av Programlokalisering. Varje enskild krusning i enkelheten i kod kontra text kommer att resultera i oräkneliga vågor som kommer att påverka lokaliseringsprocessen som helhet. Det kan resultera i scenarier där det är utmanande att antingen bevara kodens integritet eller göra den vänlig för översättare. Självklart kan du övervinna några av dessa utmaningar genom att använda parsning och segmenteringsstrategier, men ju renare du kan exportera översättningsbart Innehåll utan att koden stör, desto bättre (mer hållbar och skalbar) kommer din Programlokalisering process att bli.

Exportera programvarusträngarna

Att exportera strängarna bör vara en enkel process. Men det är inte så. Vissa format är go-to medan andra bör undvikas. Exempel på go-to-format: XML, YAML, JSON. De är strukturerade, förutsägbara, lättanalyserade och relativt enkla att hitta mönster inom koden, vilket minskar problem vid översättning till olika språk.  Exempel på format som bör undvikas: TXT, CSV, blandad kod. En CSV-export kan till exempel bli en mardröm. Avgränsande tecken som semikolon är nödvändiga som språkliga verktyg. Det är praktiskt taget omöjligt att algoritmiskt skilja mellan ett semikolon som är avsett som ett kodbrott och ett semikolon som är avsett som ett lingvistiskt verktyg. Detta skapar hundratals falska positiva som behöver kontrolleras under Kvalitetssäkringsprocessen samt problem under återimporten av kod etc. Med blandad kod syftar vi till exempel på XML med JSON i det som ett exempel, vilket Lägg till komplexiteten i parsning och segmenteringsprocessen. Kodning är också en viktig smärtpunkt:

• HTML-kodning
• URL-kodning
• Unicode-kodning
• Base64-kodning
• Hex-kodning
• ASCII-kodning

Vart och ett av dessa kodningsramverk kommer att få konsekvenser i lokaliseringsprocessen, inklusive teckeninkompatibilitet beroende på vilka språk som omfattas.

Finjustera parsnings- och segmenteringsstrategier

Om du har följt de bästa metoderna ovan kommer dina parsnings- och segmenteringsstrategier att vara processoptimerare. Om du inte har gjort det kommer parsning och segmentering att bli processmöjliggörare. Som processoptimerare kommer en finjusterad segmenteringsstrategi att säkerställa att innehåll tas emot av ditt hanteringssystem för översättning på ett sätt som är vänligt för översättare och granskare. Det är här du kan se till att variabler skyddas, att eventuell återstående kod skyddas och att texten bryts på ett sätt som är meningsfullt för översättningsprocessen. Om du inte har gjort din hemläxa är det här steget där saker och ting kan bli galna. Antingen för att det är omöjligt att skapa tillräcklig parsing för att skydda koden och variablerna eller för att det skulle kräva en enorm ansträngning att skriva tillräckligt med reguljära uttryck för att göra mjukvarans Innehåll mer översättningsvänligt. Hur som helst är detta ett avgörande steg. Om du ändrar strategi för parsning och segmentering över tid, kommer du att uppleva en förlust i översättningsminneutnyttjande vilket kommer att skapa extra kostnader och processkomplexitet. Det kanske inte verkar som en stor sak förrän det exploderar i ansiktet. Låt oss anta till exempel att din hela mjukvara har 100 000 ord och att du översätter till 10 languages och att din genomsnittliga kostnad per ord är $0.15. Låt oss anta att du har översatt din programvara men nu itererar på din parsningstrategi, men detta kommer att orsaka en 10% förlust av hävstångseffekt (vilket kan vara ett förväntat resultat av en mindre förändring i parsning), det är $15,000 förlorade rätt från början, för att inte tala om den extra tid som behövs och andra konsekvenser.

Utveckla en viktig terminologilista (ordlista)

Vem som helst kan utveckla en ordlista. Väldigt få kan utveckla en fantastisk. Vissa människor går den statistiska vägen och utvinner en Innehållsdatabas för de mest återkommande nyckelorden. Och även om det påskyndar saker och fångar termer som är viktiga baserat på frekvens, används flera viktiga termer inte nödvändigtvis så ofta. Vissa människor tar den kvalitativa metoden och låter översättare gå igenom mängder av innehåll och manuellt identifiera relevanta termer. Andra använder AI för att söka efter lingvistiska mönster och identifiera enheter och termer som inte nödvändigtvis baseras enbart på frekvens utan på deras övergripande semantiska relevans. Oavsett tillvägagångssätt, när det gäller en ordlista, är mindre mer. Även om du vill säkerställa att du har fångat de väsentliga termerna, är det nästan omöjligt att säkerställa styrning över korrekt tillämpning om du markerar för många termer som ordlista-termer. För många falska positiva och varningar gör det utmanande för översättare och granskare att hantera termförslagen och att köra automatiserade QA-kontroller. Ett annat tips när det gäller ordlistor är att det är lika viktigt att markera termer som inte ska översättas som de som kräver en viss typ av översättning.

Skapa projektet för programvaruöversättning

Detta steg är starkt beroende av ramverket för det hanteringssystem för översättning du använder. Vissa system kommer att tillåta dig att hantera hela projektets livscykel inom samma miljö och projekt medan andra platforms kommer att kräva en annan typ av tillvägagångssätt som kan vara sträng- eller filbaserat. Även om det kan verka som en formalitet, har upprättandet av det faktiska översättningsprojektet Viktiga kontrollpunkter såsom:

• Se till att filerna matas in i sin helhet
• Säkerställa att språkpar är korrekta ända ner till lokalnivå
• Se till att datumen är korrekta
• Se till att arbetsflödesstegen är de nödvändiga
• Tilldelning till översättare

I detta steg antar vi att du redan har ett tidigare granskat team av översättare tillgängligt för varje språkpar. Det är viktigt att arbeta med översättare som är:

Samma som med översättare med extra betoning på kritisk urskillning. Du behöver granskare som är tillräckligt kritiska för att förstå skillnaderna mellan stil och fel. Granskare som ändrar för mycket i det här skedet av processen äventyrar integriteten i översättningsprocessen som helhet. Här är där Bureau Works egenutvecklade kvalitetsledningsramverk kommer till nytta.

Frågehantering

En viktig del av programvaruöversättning är att kunna hantera frågor som uppstår under översättningsprocessen. Till exempel, vad står knappen "X" för, eller vad pekar denna variabel på? Det är viktigt att ha en process som gör det möjligt för dig att ställa frågor angående källspråket och ha svaren tillgängliga för alla översättare i projektet oavsett deras språkpar för att minimera behovet av att svara på samma fråga om och om igen. Det är också viktigt att ha ett sätt att tilldela olika statusar till frågan, såsom ny, tilldelad, löst, och så vidare, så att ditt projektledningsteam kan säkerställa att frågor besvaras i tid.

Automatiserade Kvalitetssäkringskontroller

Kritiska för varje Programlokalisering process, automatiserade QA-kontroller säkerställer att vissa Viktiga punkter flaggas, såsom:

• Avslutande blanksteg
• Teckenbegränsningar
• Inkonsekvent interpunktion
• Ordlista non-adherence
• Stavning
• Inkonsekventa taggar (felmatchningar i källkod och översatt kod)
• Återimportera översatta strängar

Om du har kommit så här långt levande, gör du något rätt! :) Det kan vara mindre smärtsamt, men du är här. Nu är det dags att importera tillbaka strängarna till ditt repository och bygga om programvaran. Om du har missat eller misskött någon av de bästa metoderna som beskrivits tidigare kan du i det här steget stöta på problem i återimportprocessen på grund av avbrott i koden, taggmatchningsfel eller andra problem som kan påverka en lyckad återanvändning av koden.

Automatiserade QA-processer kan också integreras med verktyg som automated identity verification för att förbättra säkerhet och säkerställa datanoggrannhet under lokalisering.

Källa: Linkedin

QA-kontroller antingen i stagingmiljön eller av skärmdumpar

Detta steg kan ignoreras om det är sammanslaget med testning, men det är hjälpsamt att ge Översättare tillgång till antingen en stagingmiljö eller skärmdumpar av huvudsidor för att säkerställa att strängar visas korrekt och att det inte finns några uppenbara problem som förhindrar att testningen startar.

Testning

Detta är en fas som driver Kvalitet bortom den uppenbara buggdetekteringen och fixarna. Genom testning får du en ny titt på de översatta strängarna i kontexten. Vissa översättningar som verkade perfekta under översättningsprocessen kanske inte är de bästa ur användarupplevelsesynpunkt. Det är viktigt att arbeta med testare som är engagerade i att försöka förbättra användarupplevelsen och inte bara reaktivt leta efter buggar.

Slutsats

Programlokalisering är en omfattande, kostsam och komplex process. Men det är inte bara det. Det är iterativt och kontinuerligt vilket innebär att du kommer att gå otaliga gånger genom samma process för att uppdatera din programvara när den fortsätter att utvecklas. Detta är en ytlig översikt på hög nivå över en process som kan bli oändligt mycket mer nyanserad och komplex att hantera. Men den viktiga insikten är att det är värt varenda krona att investera i en ramverk och bästa praxis från allra första början. När skeppet väl har seglat kommer det att bli stegvis mer utmanande och dyrt att laga det.