Lokalisering av stor och agil programvara: Fallstudie om Kaspersky

Att leda lokaliseringsarbetet för ett stort mjukvaruföretag är i sig en utmaning. Vad händer när detta företag går över till agila metoder? Jo, utmaningarna blir ännu större och man måste genomföra drastiska förändringar, snabbt. I denna fallstudie, Ekaterina Galitskaya och Darya Egorushkina från Kasperskys dokumentations- och lokaliseringsgrupp berättar om sin resa mot att öka kapaciteten och effektiviteten i sina processer med Smartcat.

Ytterligare text av Ekaterina & Darya

Vårt team ansvarar för att skriva och lokalisera både UI-texter och hjälpcenterartiklar för företagets mobila säkerhetsappar. Nedan berättar vi hur vi började lokalisera Mobile Security-appar på ett mer tillförlitligt, smidigt och automatiserat sätt. Vi börjar med de problem som ledde till att vi behövde förändra något, och går sedan igenom de utmaningar vi stod inför och de lösningar vi kom fram till. Vi hoppas att den här artikeln är intressant för alla medelstora till stora mjukvaruföretag som står inför utmaningen att implementera Agile, inte bara i sin utveckling, utan även i alla relaterade aspekter.

Liksom många andra företag hade Kaspersky vid ett tillfälle gått över till agila utvecklingsmetoder. Detta ledde naturligtvis till mycket kortare release-cykler. Om vi tidigare lanserade nya appversioner med några månaders mellanrum, blev det nu en gång varannan vecka. Visst, det fanns nu färre strängar i varje ny release, men det hjälpte inte mycket: Vi var fortfarande tvungna att köra dessa få strängar genom hela vår lokaliserings- och språktestningsprocess, samtidigt som vi hade mycket snävare deadlines.

Det finns också en vanlig missuppfattning att mobilappar endast innehåller en liten mängd text. Om det bara vore så väl! I vårt fall hade vi till exempel i genomsnitt cirka 25 000 ord per app bara i UI-texter, multiplicerat med cirka 10 appar och cirka 20 målspråk för varje app. Allt detta med nya UI- och dokumentationstexter som kom in varje vecka.

Som ett resultat blev lokaliseringen i praktiken flaskhalsen i hela lanseringsprocessen. Och om produktcheferna tidigare inte ens kände till namnen på lokaliseringsteamet – varför skulle de göra det, när alla översättningar verkade dyka upp ”som genom ett trollslag”? – så var de nu medvetna om alla problem på ett mycket djupare plan än de någonsin hade önskat.

Hos Kaspersky består lokaliseringsprocessen i allmänhet av två steg: översättning och språklig testning.

Det allmänna problemet i översättningsfasen var att det krävdes för mycket manuellt arbete, både på grund av den process som användes och CAT-verktygets begränsningar. Mer specifikt:

• Eftersom multibranch-pipelines inte stöddes var vi tvungna att manuellt skapa deltas för översättning och senare skicka tillbaka dem till grenarna.

• Det var omöjligt att säkerställa konsistens mellan appar och språk.

• Vi kunde inte göra ytterligare begärda översättningar parallellt, t.ex. om källtexterna ändrades under processen. Istället var vi tvungna att vänta på att det grundläggande översättningspaketet skulle bli klart och först därefter fortsätta med de ytterligare översättningarna.

• Byggfel på grund av fel i ”icke-översättbara” delar, oeskapade apostrofer och andra mänskliga fel blev ett allt större problem.

När det gäller språktestningen kan det ta upp till två veckor, jämfört med de tre till fem dagar som själva översättningen tog. ”Vad i hela världen är språktestning?”, hör vi dig fråga.

Det huvudsakliga syftet med språktestning är att kontrollera hela översättningen i sitt sammanhang. Vi har ett starkt team av översättare som känner väl till vår terminologi. Men när man översätter text utan att se vad som omger den, eller ens om det är en knapp eller en rubrik, kan det snabbt gå snett.

Språktestning innebär alltså att man manuellt kontrollerar alla appskärmar, vanligtvis via skärmdumpar. Det hjälper till att identifiera problem som

• Texten är för lång för skärmens storlek. Ibland kan detta ha juridiska konsekvenser, om den utelämnade texten innehåller ansvarsfriskrivningar eller finansiell information.

• Text som inte översatts, antingen på grund av ett misstag från översättaren eller för att den var hårdkodad istället för att vara externiserad som en string,

• Text som översatts i fel sammanhang, t.ex. när texten på en knapp – t.ex. ”Ladda ner” – grammatiskt sett är en imperativ istället för en infinitiv.

Bara skärmdumpningen tog oerhört mycket tid. Om en ny funktion till exempel omfattade 40 UI-skärmar och det fanns 20 målspråk, kunde det ta upp till 70 timmar av manuellt, mekaniskt slit.

Sammantaget var detta något man kunde leva med när det kom en ny release var tredje månad. Men med releaser varannan vecka började detta ta ut sin rätt på lokaliseringsgruppen. Det måste åtgärdas, och det snabbt.

1. Anställa arbetare med låg erfarenhet och minska mängden lokaliseringsarbete – vilket naturligtvis leder till en försämring av kvaliteten, ELLER
2. Automatisera.

Vi valde det senare alternativet.

När vi valde CAT/TMS-lösningen var våra högsta prioriteringar:

1. Färre interna godkännanden – godkännande av budgetar, generering av serienummer och allt sådant. — så att vi kunde börja använda den direkt utan att behöva vänta på att fler funktioner skulle utvecklas,

2. Lätta serverkrav — återigen för att undvika långdragna godkännanden,

3. Prisvärd, helst gratis, tillgång till tjänsten.

4. Adekvat support från tjänstens sida så att vi inte behöver anställa en intern utvecklare.

5. Säkerhetskrav – vi ansluter till tjänsten, inte tvärtom.

6. Stöd för flera grenar — för att översätta flera funktioner parallellt,

7. Ytterligare översättningar möjliga parallellt med den ursprungliga batchen.

När vi sammanställde en kortlista med alternativ blev det till slut bara två namn kvar: Smartcat och Zing, en kontinuerlig lokaliseringsserver från skaparna av Evernote.

Vi gillade Zing för dess anpassningsbarhet, kostnadsfria installationspaket och privata åtkomst – vi kunde hosta det inom vår egen organisation. Nackdelen var att installationsprocessen var långt ifrån enkel, så att integrera alla våra översättare och medarbetare skulle göra tidskostnaden för att driva tjänsten för hög.

Så det blev Smartcat. Eftersom vi inte får ansluta CAT-verktyg direkt till vårt interna VCS valde vi att använda ett Smartcat–Serge-paket. (Serge är en öppen källkodsprogramvara som synkroniserar strängar mellan versionshanterings- och översättningshanteringssystem. Den identifierar strängar i filer av olika format och konverterar dem till branschstandardformatet PO, som sedan matas in i Smartcat. Vi kan installera den direkt på våra servrar, så ingen av våra konfidentiella uppgifter hamnar utanför.)

Här är vad vi gillade mest med den slutliga lösningen:

• Den uppfyller alla våra krav: multibranch-pipelines, ytterligare översättningar, säkerhet osv.

• Vi får uppdateringar direkt, utan att behöva ladda ner eller installera något.

• Vi kan skapa våra egna parsningsscheman för strängar tack vare Smartcat–Serge-paketet.

• Vi kan prata med översättare som arbetar med våra dokument utan att lämna plattformen.p>

• Vi kan hitta frilansare direkt på plattformens marknadsplats, om vi någonsin behöver öka produktionen.

• Vi kan betala för alla språk och projekt med en enda faktura.

• Vi älskar den support vi får — Smartcats team hjälpte oss att få igång vårt arbetsflöde och prioriterade några av de funktioner som var kritiska för oss. — vi valde till slut ett abonnemang på grund av funktionen för textsökning i hela projektet, men detta var valfritt.

Några av de utmaningar vi ställdes inför var:

• Inledningsvis kunde vi inte söka efter text i alla dokument i ett projekt – detta är inte längre ett problem, eftersom Smartcat sedan dess har implementerat den funktionen.

• Projektledaren måste manuellt skicka inbjudningar till översättare – men vi har hört att detta steg snart kommer att automatiseras.

Med tanke på våra erfarenheter av Smartcat hittills är vi hoppfulla att deras team redan arbetar med att lösa dessa problem.

För att sätta saker i perspektiv, här är en jämförelse mellan vad vi hade och vad vi har nu, både vad gäller processer och siffror.

Före

Innan förändringarna genomfördes var vi tvungna att genomföra närmare 30 steg i översättnings- och språktestningsfaserna:

Översättning:

1. Hämta texter från olika grenar i rep — manuellt,

2. Skapa en delta för översättning — manuellt,

3. Skapa paket för översättning,

4. Ladda upp dem på en FTP-server,

5. Skriv en massa e-postmeddelanden till byråer, frilansare eller lokala kontor,

6. Hämta översättningen från FTP-servern när den är klar,

7. Ladda den i CAT-verktyget och se till att allt ser bra ut,

8. Ladda upp de översatta strängarna till repo och försök att inte blanda ihop grenarna – manuellt,

9. Kör en byggnad, åtgärda fel, slutför byggnaden,

10. Begär ytterligare översättningar – i princip upprepa samma process igen.

Språktestning:

1. Starta byggprocessen och vänta tills den är klar.

2. Starta om byggprocessen om den misslyckades på grund av lokaliseringsfel.

3. Konfigurera en speciell testmiljö om det inte finns något felsökningsmeny.

4. Ta alla relevanta skärmdumpar för över 20 språk.

5. Ta reda på, tillsammans med QA-teamet, hur man kan få tag på de skärmdumpar som fortfarande saknas.

6. Skapa och namnge skärmdumpspaket.

7. Ladda upp dem till FTP-servern.

8. Tilldela översättningsbyråer uppgifter för att kontrollera översättningarna.

9. Svara på byråernas frågor,

10. Acceptera uppgifterna och gör ändringarna,

11. Gör bygget – vilket ibland tar lång tid,

12. Gör om bygget om det uppstod fel,

13. Ta skärmdumpar för regressiv testning,

14. Ladda upp skärmdumparna igen och tilldela översättningsbyråerna uppgifter.

15. Diskutera allt med byråerna igen.

16. Gör en ny omgång regressiv testning om det har gjorts ändringar i översättningen.

Efter

Nu har vi bara nio steg över alla faser:

1. Copywritern lägger in nya strängar i Git. Serge matar automatiskt in strängarna i Smartcat,

2. Lokaliseringens projektledare tilldelar översättare,

3. Översättarna översätter i sitt sammanhang – med skärmdumpar och kommentarer till hands,

4. Lokaliseringens projektledare granskar och bekräftar översättningen, som sedan automatiskt skickas tillbaka till Git,

5. Lokaliseringsteamet kör funktionen för skärmdumpbot för lokaliserade texter,

6. Lokaliseringsteamet lägger de lokaliserade skärmdumparna på FTP-servern och skickar dem till lingvisterna.

7. Lingvisterna kontrollerar och korrigerar översättningarna vid behov medan de tittar på de lokaliserade skärmdumparna.

8. Ändringarna skickas automatiskt tillbaka till Git.

9. Lokaliseringsteamet stänger pull-förfrågan.

Det är allt – med denna tredubbla minskning av komplexiteten känner vi verkligen skillnaden jämfört med hur det var tidigare!

Alla siffror avser en release – varannan vecka – och en app.

Ytterligare fördelar – varav vissa vi inte hade förväntat oss – inkluderar:

• Mer tillförlitliga byggnader: Tack vare platshållare behöver vi inte längre oroa oss för att icke-översättbar text översätts eller att apostrofer inte undantas, och så vidare.

• Smartcat identifierade några äldre buggar tack vare sina inställningar för kritiska fel.

• Vi slösar inte bort andras tid och resurser: Vi behöver inte ta testutrustning från QA-teamet eller ta upp utvecklarteamets tid med att ta skärmdumpar.

• Skärmdumpar tillgängliga för översättare, som de enkelt kan öppna och visa direkt från redigeraren, har förbättrat kvaliteten på översättningarna avsevärt.

Vi skulle kunna fortsätta, och vi är säkra på att vi med tiden kommer att hitta andra sätt att förbättra både effektiviteten och kvaliteten i våra lokaliseringsprocesser. Det viktigaste är att lokalisering inte längre är en flaskhals i lanseringscykeln. Vi anser att det var en bedrift både för vårt team och för Smartcat-plattformen att uppnå dessa resultat på så kort tid.

Här är några konkreta åtgärder som vi har vidtagit efter att vi implementerade Smartcat. Vi lägger upp dem här som en ”cheat sheet” för andra företag och team som vill följa i våra fotspår. Alla är inte lätta att genomföra, men de flesta bidrar till att göra lokaliseringsprocessen smidigare och mindre felbenägen.

Integration:

• Testa integrationen mellan Git, Serge och Smartcat för att säkerställa att alla strängar överförs till Smartcat-projekt och tillbaka. Du vill inte stöta på överraskningar i produktionsfasen.

• Kom överens om namngivning av grenar med mjukvaruutvecklare. På så sätt kan du ställa in en bot som letar efter specifika grenar som behöver lokaliseras – vilket sparar både dig och utvecklarna timmar av kommunikationstid.

• Anpassa Serges standardparsers om det behövs. Vi gjorde till exempel sträng-id:n, kommentarer och länkar till referensskärmdumpar synliga för översättarna.

• Skapa ett cron-jobb för att hitta lokaliseringsgrenar enligt den namnmast som överenskommits ovan.

• Överväg UI-testning och skärmdumpning av funktioner med hjälp av ramverket Kaspresso. Till exempel lägger våra utvecklare in en länk till en skärmdump för varje sträng de använder. När filen hamnar i Smartcat läggs skärmdumpens länk automatiskt in i fliken Kommentarer. Du kan läsa mer om Kaspresso och varför du kanske vill använda det här.

Lokalisering och språktestning:

• Om du har ordlistor, ladda upp dem till Smartcat för att säkerställa konsekvens i dina lokaliseringar.

• Lägg till dina interna lingvister så att de kan utforska plattformen och lära sig hur den fungerar innan de får faktiska uppdrag från dig.

• Hitta och välj frilansare och introducera dem till ditt företags processer, så att de vet hur man använder skärmdumpar, kommentarer, ordlistor etc.

• Vid behov kan du hitta översättningsbyråer för ytterligare lokaliserings- eller testbehov.

Hoppas dessa var till hjälp — hör av dig om du har några egna tips!