Lokalisering helt enkelt. Översättning med extra allt.

Men vad är då lokalisering?

Lokalisering förknippas med förkortningen L10N. Första och sista bokstaven i ordet skrivs ut samt hur många bokstäver som utesluts. L+10+N ger Localization. Lokalisering är steg tre av fyra för när en produkt ska börja användas globalt, eller när en global produkt introduceras på en ny marknad.

Det börjar med G11N, Globalization. Ett bolag bestämmer sig för att bedriva global verksamhet. Det innebär att ledningen måste tänka globalt och planera globalt.

Nästa steg är I18N, Internationalization. Rent tekniskt måste produkten anpassas till andra tekniska plattformar, alfabet, lagar och förordningar med mera. För varje språk som ska användas skapas en språkkonvention (på engelska: locale). Observera att detta inte är en synonym till språk, eftersom språk kan ha regionala skillnader, såsom exempelvis europeisk och latinamerikansk spanska eller brittisk och amerikansk engelska. Även designen kan behöva ändras i detta steg.

När vi talar om lokalisering handlar det ofta om användargränssnitt, och språkkonventionen påverkar då datorns uppsättning förinställda värden. Här är datatermgruppens lista på vad språkkonventionen[1] tar höjd för:

• språk

• alfabet (vilka tecken som behöver finnas)

• sorteringsregler (exempelvis när ska de svenska bokstäverna å, ä och ö komma i en alfabetisk lista?)

• rättstavning och andra skrivregler

• skrivregler för siffror och datum

• helgdagar

• andra språkliga och kulturella sedvänjor som är relevanta.

Den som är van att byta språk i Office exempelvis, eller som arbetar med olika operativsystem på olika datorer, vet hur språkkonventionen förändras beroende på om man har valt engelska eller svenska. Vid val av svenska blir alla svenska inställningar det förvalda alternativet i gränssnittet. I Excel är det exempelvis svenska namn på formler. I Word använder du ctrl+F för att få fetstil, medan det är ctrl+B om du har engelska Word. De olika sätten att skriva nummer och datum följer också förvalt språk.

Problemet med Edit

Microsoft var tidigt ute på lokaliseringsområdet och hade en imponerande organisation för att kvalitetssäkra översättningarna och skriva definitioner av datatermer. I dag ses Microsofts termbank som standard inom IT, och bolaget har en öppen språkportal där man kan söka efter översättningar och läsa och jämföra definitioner.[2] Det är alltså Microsofts ”fel” att vi har två översättningar av Edit och Delete (redigera/ändra respektive ta bort/radera), vilket alltid ställer till problem när man saknar kontext.

Användargränssnitt består av kod och visningstext. Koden anger vad som händer när du trycker på knappen Spara. Texten Spara på knappen berättar för användaren vad som händer när hen trycker på knappen. För att travestera Shakespeare så är det alltså så logiskt att oavsett vad du översätter Save till så kommer den att spara. Det här kan låta självklart. Jag ska snart förklara varför det inte är självklart för gemene hen. Program kan vara antingen standardprogram (som Office-paketet) eller anpassade program. I det senare fallet finns det en kärna som är likadan för alla användare, men det finns också möjlighet för organisationen att anpassa och bygga ut programmet. Exempelvis kan organisationens namn stå på skärmen när du öppnar programmet. Det kan finnas funktioner som är specifika för organisationen, val, nivåer och fält som inte finns i standardversionen. Lättast förklaras detta som en påbyggnad som inte påverkar kärnfunktionerna. Det här är ett billigare sätt att få ett program anpassat för den egna organisationen jämfört med att bygga ett helt nytt program.

Validering ett krav

Och därmed är vi framme vid L10N. Lokalisering. Lokalisering kan alltså omfatta såväl standardprogram som anpassade program. När en produkt ska lokaliseras till svenska måste innehållet anpassas till svenska förhållanden och all översättning måste valideras. Jag brukar kalla detta översättning med extra allt. Om en fråga brukar besvaras jakande på engelska men nekande på svenska, måste ja ”översättas” med nej. Om vi har tre vårdnivåer men USA har fyra måste vår version ändras till tre nivåer. Om fler yrkesgrupper får skriva ut läkemedel i Sverige jämfört med i USA måste programmet anpassas till detta. Och så vidare i nära nog all oändlighet.[3]

Vad händer då om vi har en knapp där det står PRINT men våra arbetsflöden brukar bara spara filerna, inte skriva ut dem? Lokalisering borde förstås vara att ”översätta” knappen till Spara, men som jag påpekade tidigare kommer koden ändå att skicka filen till utskrift.

Programmerare dyrare än översättare

Rent kostnadsmässigt är översättning billig jämfört med att skriva om kod, eftersom alla språk som använder kärnfunktionerna (om det rör en kärnfunktion) då måste uppgraderas och en ny version installeras. Ibland går det att fulkoda, vilket vi inte ska gå in på här, men det vanligaste är att det krävs en kodändring som då är gemensam för kärnsystemet, dvs den delen av programmet som alla kunder använder sig av, oavsett språk. I samband med beslutet om globalisering kanske bolaget tänkte för kortsiktigt angående språkskillnader, och tog inte med sådana saker som att olika ord kräver olika val i bestämd form, som i franskan, samt att språk kan använda sammansatta ord och att de då inte kan delas upp på skärmen trots att designen är skapad för en uppdelning. Ett annat svenskt dilemma uppstår när vi hänvisar till alternativ som kan vara både den- och det-ord, det vill säga kongruens. För att skriva korrekt svenska kan vi inte använda samma.

Säg att du har en lista med olika val och alla val är 8–15 tecken långa, men så kommer ett som är 115 tecken långt och du måste skrolla fram och tillbaka i en evighet för att läsa och välja – då fungerar det sämre på mobilskärmen.Problemet här är dock oftast att det finns en standardöversättning på svenska som måste användas och som inte kan förkortas. Ett exempel är DOB (Date of Birth), Födelsedatum på svenska. Finns det bara plats för 6 punkter (dvs 2 punkter per versal D O B), kommer Födelsedatum att klippas på skärmen oavsett din översättning och där står det Födel. Observera att det ibland kan vara svårt att se att ett ord är avklippt om du inte jämför med originalprogrammet. Ett sammansatt ord som klipps på rätt ställe kan ju se OK ut.

Klister inte alltid en lösning

Vid valideringen apporteras detta tillbaka till teknikerna. Ibland är det ett tekniskt beslut, ibland ett ekonomiskt beslut vad som kan/ska kodas om. Något som alltid måste åtgärdas är däremot konkateneringsbuggar. Konkatenering är det smarta sättet att ta två fristående strängar och limma ihop dem och på så sätt skapa en sträng. Problemet är bara att det nya språket kanske har omvänd ordföljd jämfört med konkateneringen. Då måste kodningen lösa upp limmet så att strängarna går att flytta. Lokalisering handlar inte alltid om vad som är rätt, utan om vad som fungerar utifrån dessa förutsättningar. Viktigt är förstås också att två (eller fler) termer inte kan ha samma översättning, för en sak som är säker är att de förr eller senare kommer att dyka upp bredvid varandra i användargränssnittet. Jag såg ett exempel för några år sedan med tre flikar som hette Plats/Plats/Plats. Alla var korrekt översatta men behövde självklart få nya namn som sedan skulle återanvändas konsekvent inom programmet, hjälptexterna och de tekniska instruktionerna.

Jag nämnde inledningsvis listor med fristående termer som skickas för översättning. Lokaliseringsprojekt omfattar ofta flera miljoner ord. En hel del är standard-IT-översättningar för att programmet ska fungera, men samma term kan förekomma i flera idiolekter med olika översättningar. Ett exempel är engelskans position. I åtkomstprogram och i databaser över användare motsvarar detta befattning. Men i CAD-program och liknande motsvarar det position, dvs platsen. Översättningsminnet som annars förenklar arbetet genom att återanvända redan översatta segment, kan av naturliga skäl inte skilja mellan dessa två position om kontext saknas. Lösningen är att lägga in båda i termbasen, med definition och i samband med QA-kontrollen där termbasen är redskapet, kontrollera vilken som är rätt i detta sammanhang. Det krävs alltså sedan två segment i ditt TM med position översatt på båda sätt.

Termbasen som en livboj

För översättaren som arbetar med ett användargränssnitt är definitionerna ens bästa vän. Är du inte terminolog när du börjar så kommer du att vara det inom en kort framtid. Samma definition på engelska som på svenska? Bara att tuta och köra och använda översättningen. Skiljer sig definitionerna åt (dvs omfattar mer eller mindre) blir det rött ljus direkt, för att inte användaren ska tolka det som står på skärmen felaktigt. Det är naturligtvis nödvändigt att enbart använda etablerade termbaser från välrenommerade organisationer. Ett annat tips är att ju mer specialiserad en källa är, desto mer korrekt är troligen översättningen och en senare publicerad källa har också högre poäng.

När jag vidareutbildade mig på det medicinska området läste jag bland annat vårdjuridik. Där lärde vi oss samma princip för lagtexter. Om en term skiljde sig åt i en mer allmän lagtext som Hälso- och sjukvårdslagstiftningen (HSL), jämfört med patientdatalagen (PDL) skulle den mer specialiserade lagen äga företräde. Det är en bra tumregel.

För de nya funktioner som introduceras i och med ett nytt program på den svenska marknaden måste översättaren vara kreativ och välja något som beskriver funktionen utan att förvirra slutanvändaren till att tro att det handlar om en annan funktion som finns sedan tidigare. Det krävs att man arbetar med en termlista samt bra kvalitetsgranskningsverktyg. X-bench exempelvis, för att kontrollera att översättningen är konsekvent.

När upprepning är bra

Observera att filerna som översättaren arbetar med innehåller de synliga textraderna som har skrivits av en uppsjö av tekniska skribenter (UX writer) under en längre tidsperiod. De ska följa stilguider, men det gör de inte. Alla har inte heller engelska som sitt modersmål. Och exakt samma kommando kan ibland ha skrivits på 68 olika sätt. På svenska kan vi då vara konsekventa, trots att källan inte är det. Det finns mindre överseende i Sverige för en pratig ton i program. Vi är dessutom vana vid direkta tilltal som ”Vill du spara?”, ”Stäng programmet”, ”Försök igen”, och felmeddelanden som ”Alla obligatoriska fält måste vara ifyllda”.

På bolaget som har utvecklat programmet utbildar de naturligtvis de tekniska skribenterna, men med stora volymer och hög arbetstakt är det inte konstigt att det blir oavsiktliga variationer. Om de lokaliserade språken återkopplar kan stavfel, grammatiska, fel, inkonsekvent termanvändning i källtexten åtgärdas så att kommande språk får det enklare vid översättning. Tyvärr är ibland vissa nivåer låsta och kan inte åtgärdas. En tidigare teknisk skribent/översättare kan ha misstolkat något och ingen har uppmärksammat det förrän flera uppgraderingar senare. Kostnaden för att skriva om kod och skicka ut uppgraderingar till samtliga kunder är hög. De gånger som detta ändå görs är när termer blir en belastning. Tidigare användes exempelvis herre-/slavdator. Nu är det överordnad/underordnad dator. Tidigare användes svartlistning/vitlistning, nu är det godkänd/icke godkänd.

Just akronymer är en styggelse vid översättning av användargränssnitt, eftersom vi oftast inte har en motsvarighet på svenska utan måste skriva ut ordet som då blir minst 200 procent längre. Översättningen som sådan har ju också en tendens att bre ut sig och bli minst 30 procent längre men det ska finnas med i beräkningen vid lokalisering. En bra regel är ändå att hålla det kort, klart och på svenska, vilket även var käpphästarna inom journalistiken. Stryk alla vänligen, herr/fru och sådant, så finns det plats för de långa svenska orden när de inte kan förkortas. Använd inte akronymer som går att missförstås. En regel är att om akronymerna har ersatt orden de härstammar ifrån, går de att använda. Som BB.

Vedertagna förkortningar är ett av de kortaste avsnitten i Svenska skrivregler. Men det finns fler förkortningar som går att använda och som är ämnesspecifika. I tabeller finns det exempelvis sällan plats för utskrivna termer. Och varför skriva laboratorium och tvingas avstava det fyra gånger och ta upp fyra rader, när du kan skriva labb utan att någon missförstår?[4]

Programmerare dyrare än översättare

Rent kostnadsmässigt är översättning billig jämfört med att skriva om kod, eftersom alla språk som använder kärnfunktionerna (om det rör en kärnfunktion) då måste uppgraderas och en ny version installeras. Ibland går det att fulkoda, vilket vi inte ska gå in på här, men det vanligaste är att det krävs en kodändring som då är gemensam för kärnsystemet, dvs den delen av programmet som alla kunder använder sig av, oavsett språk. I samband med beslutet om globalisering kanske bolaget tänkte för kortsiktigt angående språkskillnader, och tog inte med sådana saker som att olika ord kräver olika val i bestämd form, som i franskan, samt att språk kan använda sammansatta ord och att de då inte kan delas upp på skärmen trots att designen är skapad för en uppdelning.

Ett annat svenskt dilemma uppstår när vi hänvisar till alternativ som kan vara både den- och det-ord, det vill säga kongruens. För att skriva korrekt svenska kan vi inte använda samma form för båda. Om valet står mellan dokument och journal kommer ändelserna att vara olika när man exempelvis ska bekräfta en handling som ”Verifierad (journalen)/Verifierat (dokumentet). Men om vi i ett tidigare skede väljer mellan journal och dokument och båda har samma sträng i nästa skede? Lösningen här är som så ofta på svenska att vi använder plural. Verifierade. Här går det att istället för att se det enskilda objektet se det som en stor låda i IT-systemet där alla verifierade journaler och dokument hamnar efter att användaren har kryssat i rutan.

En klassiker är förstås även namn på program som kan vara svåra att uttala på svenska eller som missuppfattas. Här finns en lösning i form av att ge namnet ett förklarande förled i hjälpfiler och marknadsföring. En gång i tiden sa vi exempelvis ordbehandlingsprogrammet Word.

Översättarens uppgift

Översättning kallas i detta sammanhang för T9N, Translation, och IT-översättare är vana att få massiva volymer med termer att översätta och inte alltid med kontext. Det är inte bara kommandon som översätts utan även menyval, flervalstermer, listor, titlar, felmeddelanden, instruktioner, hjälptexter, tekniska specifikationer, konfigureringshjälp, felsökning, installationsinstruktioner med mera. Oavsett vad slutanvändaren har programmet för så ingår det mycket som är enbart IT-relaterat, såsom reglerna för att skapa och ta bort användare, åtkomsträttigheter och kontrollsystem. Allt ska översättas för att sedan valideras.

Är lokalisering höna eller ägg?

Det finns en debatt bland de lärde på det översättningsteoretiska området om lokalisering är en form av översättning eller om översättning är en byggsten i lokaliseringsarbetet. I Irland, där det finns utbildning på kandidatnivå i lokalisering kan du välja teknisk specialisering eller översättning som specialisering när du löser lokalisering. I Sverige har jag inte sett några kurser som ger den möjligheten, trots att detta är ett ständigt växande fält. Svenska översättare som halkar in på lokalisering får lära sig den hårda vägen. En bra kurs i IT-översättning är till hjälp men det är så mycket annat man måste tänka på.

Det är meningen att förarbetet ska identifiera alla strängar som ska översättas, kallat externalization, och dra ut dem så att texten som visas kommer med i ett översättningsuppdrag. I all lokalisering hittills där jag har varit med på ett hörn har man dock missat text. Då visas det text på källspråket, i de flesta fall på engelska. Denna engelska text är då hårdkodad och går inte att ersätta utan en kodändring. Det ansvariga bolaget använder sig ofta av pseudoöversättning för att kontrollera att all text som ska översättas har dragits ut för översättning samt att den översatta texten får plats på skärmen. Här utgår man ifrån en algoritm för maximal längd. Om något visas på engelska mitt i pseudotexten är det ett tecken på att hårdkodad text har missats. Om text är avklippt finns det en teckenbegränsning som antagligen är baserad på källspråkets term och inte har anpassats för en längre översättning.

Även dynamiska platser behöver begränsas

Dynamiska webbplatser har inte det senare problemet med avklippt text eftersom texten tar den plats den behöver, men beroende på var texten visas – mobilen, plattan, datorn, storskärm – kan en för lång textrad ställa till problem. Som översättare/validerare måste du även ta hänsyn till användarvänlighet.

När stilguiden inte alltid kan följas

Många stilguider brukar slå fast att skribenterna ska använda ”inte” på svenska. Ej och icke är inte önskvärda. Men valet mellan inte, icke eller ej är också ett exempel på ett specifikt översättningsproblem när det handlar om användargränssnitt. Ej är kort (1,5 punkter långt) och på skärmen räknas varje punkt. Ibland är ej därför det enda alternativet. Allt som går att skriva kort ska vi skriva kort för att spara på utrymme åt det som inte kan skrivas kort. Därför ska man inte ropa på rödpennan så fort man ser ett ej på skärmen. Icke är etablerat i vissa sammansättningar och ska då förstås användas där.

Den stora fördelen med lokalisering är att man ser programmet i samband med valideringen och att man får massor av testplaner att följa för att få fram de enskilda skärmbilderna och kontrollera att svenskan fungerar. Om något behöver ändras kan man oftast göra ändringen direkt i ett lokaliseringsverktyg som Passolo, spara ändringen och öppna programmet på nytt och kontrollera att ändringen fungerar. Till skillnad från när jag började för 20 år sedan har översättaren blivit sin egen tekniker på det området.

SISU-effekten

I Passolo går det även att se om vissa bokstäver redan används för snabbnavigering (så kallad Access Key). Däremot varnade inte den version av programmet jag använde när en svensk bokstav eller i, l, j, t eller I var understrukna, dvs markerade för snabbnavigering (för att snabbt komma till en viss plats på skärmen). Inga av dessa alternativ ska användas på grund av att det är svårt att se understrykningen under bokstäver på 0,5–1 punkt, samt att de svenska bokstäverna inte fungerar. Detta kan enkelt korrigeras i Passolo, där du ser vilka bokstäver som är lediga på just den skärmen.

För användargränssnitt är lokaliseringsverktyg oumbärliga. WYSIWYG (What you see is what you get) är ledstjärnan som hjälper dig att korrigera de inlästa översättningarna så att skärmen är användarvänlig och termerna korrekta. Tyvärr stämmer den kära gamla SISU-devisen, Skit in=skit ut. En användare som har kört maskinöversättning utan att tänka på vad programmet handlar om kan faktiskt leverera ett helt program för läkemedel där ordet läkemedel inte förekommer en enda gång, däremot droger och mediciner. Något av det första jag stötte på när jag började med lokalisering i början av 2000-talet var en lista på färger, där en färg hette ”kalk” på svenska. Det var engelskans lime som hade översatts med kalk, trots att färgen i rutan bredvid INTE var kalkvit … För några år sedan såg jag en lista på olika färger på urin, där en färg var ”gladlynt”. Fundera och se om du kan komma på vad engelskan hade för alternativ där!

Konsten att översätta platshållare

Tillbaka till den mindre skojiga förformateringen. Om den formatering man anger inte ger önskat resultat på skärmen, som exempelvis hur datum ska visas beroende på vilket språk som används i programmet, måste teknikerna rycka in, men annars är det häpnadsväckande mycket man kan fixa själv. Översättning här handlar oftast om översättning av platshållare, där m/d/yy kan ha yyyy-mm-dd som korrekt översättning. I samband med klockslag är den lilla prepositionen at riktigt irriterande, eftersom den då, men enbart då, ska översättas som kl.

Mitt specialområde under åren i Irland handlade om att kontrollera hjälpavsnitten mot programmet så att råden gick att följa. Även här styr ekonomin eftersom det är billigare att skriva om hjälptexten än att göra en kodändring. Om hjälpavsnitten inte beskriver det som faktiskt händer på skärmen kan en lätt omskrivning göra det förklarligt. Ibland är det så enkelt att olika översättare har arbetat med användargränssnitt respektive hjälpfiler och den som översatte hjälpfilerna inte alltid har haft tillgång till skärmbilder utan gissat sig till vad menyerna kallas. Utifrån frågor i olika Facebook-grupper kan jag se att detta problem fortfarande är aktuellt. Översättare av hjälpfiler ska alltid få en termbas med alla användargränssnitt-översättningar som referens. Om det inte skickas med så fråga beställaren. Alla tjänar på detta eftersom valideringen efteråt tar kortare tid. Om det finns skärmbilder på källspråket underlättar det också.

Ett kungarike för en skärmbild

Även tekniska filer om installation, konfigurering, underhåll och felsökning ska översättas och även här behöver översättaren ha tillgång till användargränssnitt och eventuella skärmbilder. Observera att felsökningsavsnitten kan vara baserade på inskickade frågor till supporten och därmed vara mer eller mindre tydligt skrivna.

Lokalisering kräver ämnesexpertis inom såväl IT som specialämnet för programmet. Det kräver också nära kontakt med tekniska skribenter och tekniker samt ämnesexperter att bolla termer med. Frilansöversättare ansvarar ofta för det som närmast är att se som en råöversättning som sedan det anställda lokaliseringsteamet validerar och ändrar. Ju närmare du befinner dig uppdragsgivaren, desto bättre blir slutresultatet. Dessutom är jobbet så mycket roligare. Krävande, ja, men även roligare.

UI med UX är bäst

Vad är då den allra finaste presenten en översättare av användargränssnitt kan få? Svar: Att få delta i UX-testning av användarbarheten. Här får jag följa hur användare med olika lång erfarenhet inom sitt fält och olika lång IT-erfarenhet tolkar översättningen de ser på skärmen. Jag var och lyssnade på en föreläsning om ett UX-test inom EU för många år sedan inför lanseringen av EUs nya webbplats. Där följde de användarens ögonrörelser för att bestämma var olika delar av webbplatsen skulle ligga för att förenkla för användaren. De UX-test jag har varit med på har inte varit så avancerade men jag har fått se var användaren klickar, vad användaren inte ser fast det finns med på skärmen, samt höra resonemanget bakom. Efter en omskrivning av de termer som användarna fastnade på, har jag sedan kunnat se hur det har blivit lättare för de som testar version två att genomföra sina arbetsuppgifter.

Det blir inte mycket bättre än så, eller hur?