Dette er en indføring i hvordan man griber oversættelsen af frie programmer an. Den skulle gerne indeholde essensen af flere års erfaringer med oversættelser af frie programmer.
Vejledning er samlet sammen fra materiale skrevet af medlemmerne i dansk-gruppen.
Mange programmer i Linux kommer i internationaliseret form, dvs. de bruger gettext()-funktionen til at oversætte de tekster som skal udskrives med printf() el.lign før udskriften. Der findes en engelsk brugsanvisning til gettext() med flere detaljer.
Gettext kigger efter en oversat streng svarende til det sprog man bruger (sat fx med LC_MESSAGES eller LANG) i en fil til programmet med endelsen .mo - som er en binær oversættelse af filer med endelsen .po. .po-filerne er så dem man oversætter.
I mange tilfælde skal man generere en opdateret .po-fil ud fra de eksisterende danske oversættelser i .po-filen og den komplette liste af uoversatte tekster i .pot-filen. Den nye fil laves med msgmerge, f.eks. for gedit:
msgmerge da.po gedit.pot > da1.po
Hvis der ikke er nogen danske oversættelser i forvejen, kopierer man .pot filen til da.po og går i gang med at oversætte teksterne efter at have udfyldt de øverste linjer med de relevante oplysninger - tag et kig på en allerede eksisterende .po-fil for at se hvordan.
I øvrigt indeholder mange programmer et lille program til at ordne opdateringerne (oftest med et navn i retning af update.sh), og der er desuden en pakke ved navn intltools med programmet xml-i18n-update med samme formål. intltools er at finde i Gnomes CVS, men mange distributioner har også en prækonfigureret pakke.
For at kunne se de danske tekster skal du i øvrigt have fortalt gettext at det befinder sig i et dansk miljø. Det kan gøres med følgende kommando (til Bash):
export LANG=da_DK
De forskellige distributioner har forskellige måder at gøre dette permanent for alle brugere. I Debian/Ubuntu kan "LANG=da_DK" indsættes i "/etc/environment", i Fedora/Red Hat/Centos/Mandriva/PCLinuxOS drejer det sig om filen "/etc/sysconfig/i18n".
Spørgsmålet er så hvordan man kommer i gang med at oversætte teksterne i .po-filen?
Det er faktisk ikke så svært at gå til, og man kan bruge et hvilken som helst tekstredigeringsprogram, men det er vigtigt at være opmærksom på at man aldrig må rette i "msgid"-strengene, kun i "msgstr"-strengene. Når en oversættelse er mærket som 'fuzzy' betyder det at den nok er forkert; den skal så checkes, rettes, og 'fuzzy'-bemærkningen skal fjernes.
Der er naturligvis dog en vis fordel i at bruge et program som forstår .po-filernes syntaks:
Et godt program til at oversætte tekster er KDE's Lokalize der kan bygge på tidligere oversættelser i andre programmmer og lave dansk stavekontrol. En tidligere udgave af Lokalize er Kbabel. Erik Kjær Pedersen har lavet en beskrivelse af brug af kbabel ved oversættelser af KDE programmer. Han har også lavet en oversættelse af kbabel-håndbogen (læses bedst med konqueror).
Hvis du bruger Emacs, er der en glimrende po-mode som muligvis endog allerede er installeret (nu om dage følger den med gettext-pakken så hent evt. den nyeste fra din distribution). I så fald er der en fin oversigtshjælp på '?' så snart en .po-fil er blevet åbnet. Nogle interessante muligheder som man måske ikke lægger mærke til med det samme er '#' som tilføjer en kommentar til den tekst man står ved, og 'E' som lader én slippe for po-mode når man f.eks. skal have gang i noget søg og erstat.
Der i øvrigt lidt Emacs Lisp-kode til at sørge for stavekontrol og noget til at få i-search til at ændre adfærd så den passer til det typiske forbrugsmønster under oversættelse med po-mode.
Også til 'vi' er der måske en god po-mode som måske endog allerede er installeret, det er den måske på Fedora og Mandrake systemer. Hvis ikke, kan man bruge filen .po.vimrc fx installeret i hjemmekataloget.
vi -u ~/.po.vimrc da.po
Denne fil giver nogen makroer, fx: ,ff giver næste fuzzy, ,fm giver næste manglende.
Til oversættelse af XML-tekster (såsom fx DocBook) findes programmet Rosetta, der også har translation memory. Se på http://www.irule.be/bvh/c++/rosetta/.
Endelig er der til Gnome gtranslator. Der går rygter om at det også kan nogle tricks.
Du kan finde emner til oversættelser ved at kigge på status for oversættelserne (FIXME: indsæt henvisning) og se hvilke der ikke er færdigoversat. Det bedste er naturligvis hvis det er drejer sig om programmer du bruger meget, ellers kan det være et hyr at få oversættelsen testet.
Mange gange kan .po-filen hentes direkte via CVS. F.eks. for Gnome får man fat i den danske .po-fil fra gedit ved:
cvs -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome login (skriv ingen adgangskode, bare tryk retur) cvs checkout gedit/po/da.po
Bemærk at inden du går i gang, skal du huske at kontakte danskgruppen så der ikke bliver lavet dobbelt arbejde. Gruppen tager sig af diverse opgaver i forbindelse med at fordanske frie programmer, og listen er mest til interne meddelelser (koordinering af oversættelser, planlægning af møde og den slags). Hvis du viser at du er interesseret i at hjælpe med og villig til at lægge noget tid i det, vil én af os sandsynligvis spørge dig om du ikke har lyst til at deltage på postlisten.
De forskellige paraplyprojekter har ofte en bestemt person der tager sig af at koordinere (oftest bare den mest aktive), men da dette skifter en gang imellem efter hvad folk har tid til, er det mest sikre at kontakte danskgruppens postliste.
På listen kan du også få hjælp til at få rettet oversættelsen igennem (hvis du ikke har prøvet det før, kan det synes at være en hård omgang - ligegyldigt hvem der har lavet oversættelsen, slipper der altid en hel del fejl igennem, så vær ikke ked af det hvis der kommer en del kritik af din oversættelse), og hjælp til at få den sendt videre hvis det f.eks. drejer sig om en oversættelse fra et CVS hvor du ikke har skriveadgang. Det kan være godt at begrænse kommenteringen på listen til kun de rettelser som du har lavet, dette gøres nemt ved at medsende uddata fra en diff -u - fx ved:
diff -u gammel.po ny.po
Vel overstået de praktiske detaljer følger her et par formaninger om hvordan man bør foretage oversættelserne.
Det er vigtigt at huske på at man ikke oversætter for at få oversættelsen så præcis eller så direkte som muligt. Man oversætter for at få det bedste program ud af det for brugerne, det er dem man står til regnskab for, så brug altid hovedet og vær ikke nervøs for at tænke selvstændigt. Man kommer en gang imellem ud for at de engelske tekster er noget værre, uforståeligt juks, eller at de er så anglificerede at der skal en hel del omformulering til.
Det med at bruge hovedet gælder også for de gamle oversættelser. Mange gange kan de have været lavet under tidspres og kan indeholde en hel del fejl.
Man skal forøvrigt huske at lægge mærke til hvor meget plads man har at gøre med til en given tekst. Nogle gange er der plads nok til at man kan slippe for mystiske forkortelser (folk der er inde i programmørslangen, kan godt lide at bruge forkortelser også hvor det ikke er nødvendigt - disse bør for det meste ikke få lov at slippe igennem til almindelige dansk brugere), andre gange er man nødt til at være lidt kreativ.
Bemærk dog at det vigtigste er en nogenlunde forståelighed og konsistens - hvis det bliver for galt, bør man måske overveje at bede vedkommende der har designet grænsefladen om at lave den mere fleksibel. Andre sprog end dansk har i sådanne tilfælde med garanti også problemer.
At formålet med oversættelsen ikke er en så præcis gengivelse af den engelske original som muligt, skal i øvrigt ikke misforstås - oversættelserne skal faktisk være så præcise og omhyggelige så muligt (sålænge det ikke går ud over forståelsen), men de skal være præcise i forhold til det, de engelske ord dækker over, det de forsøger at kommunikere - der kan nogen gange være en stor forskel, ikke alle programmører er sproglige genier. Derfor er det også en meget god idé at teste oversættelserne hvis det er muligt.
Der er flere grunde til dette råd.
Ordene i Dansk-gruppens og KLID's ordliste er samlet sammen gennem lang tids afprøvning og kan dermed være en stor hjælp hvis man lige sidder og mangler et bestemt ord, simpelt hen som et opslagsværk. Almindelige ordbøger indeholder ofte ikke IT-fagudtryk.
Og for at sikre at programmerne ser nogenlunde ens ud er det vigtigt at de betjener sig af samme terminologi (fx bør det ikke hedde udklipsholder i et program og klippebord i et andet). Det er ikke bare et æstetisk spørgsmål, men hænger direkte sammen med brugervenlighed. Hvis hvert program har sin egen terminologi, kan brugeren ikke overføre sine tidligere erfaringer direkte, men er nødt til at starte forfra hver gang. Dette kan let være nok til at tage modet fra almindelige mennesker uden større erfaring med computere.
Så ordlisten er at betragte som en slags sprogstandard som du stærkt bør overveje at følge (selvom en given situation naturligvis sagtens kan kræve en undtagelse). Den er i øvrigt mestendels tekstbaseret og derfor velegnet til søgning med programmet grep.
Bemærk dog at det med at bruge hovedet også gælder for brug af ordlisten - hvis et ord ikke passer ind, så undlad at bruge det blindt. Evt. kunne det endda være at du kunne finde et ord der var bedre end det der allerede er vedtaget - ordlisten er trods alt i konstant forandring efterhånden som oversættelserne bliver bedre og bedre.
En gennemlæsning af listen ville (ud over efterhånden at tage en hulens tid) vise at vi oversætter næsten alle af de engelske fagudtryk til dansk, f.eks. "cookie" = "infokage" eller "compiler" = "oversætter". Hvis man har en vis erfaring inden for computerverdenen, vil man naturligt nok kvie sig en del ved det fordi ordene så pludseligt får en dybere betydning, hvilket lyder mærkeligt eller ligefrem dybt komisk.
Men det er vigtigt at forstå at dette er et led i en bevidst og velgennemtænkt politik, som er fastlagt af danskgruppen.
Oversættelserne er til for hele befolkningen - vi ønsker at GNU og Linux kommer ud til masserne, men så nytter det ikke noget at programmerne stadig snakker delvist engelsk. Flertallet ville så simpelthen ikke forstå dem; programmerne skal ikke være afhængige af at folk er gode til at slå op i deres ordbog.
Garvede brugere høster faktisk også en fordel ved at bruge de oversatte programmer. Ofte læses og bruges de engelske udtryk nemlig uden at folk egentligt er helt klar over hvad de betyder. Det medfører at de associationer som engelske læsere får i forbindelse med ordene, tabes for danskere - hvad der er en skam fordi der ofte er gjort meget ud af at vælge en analogi der gør det lettere og hurtigere at forstå begrebet.
Prøv selv at slå nogle af ordene i ordlisten op i en engelsk-dansk-ordbog. Man bliver næsten altid overrasket over alle de medbetydninger som et givent ord har, og som engelske læsere har hængende i deres forståelse.
Man vænner sig bevisligt ret hurtigt til de danske udtryk; de bliver ikke ved med at lyde mærkelige.
Der er altså gode grunde til vores politik, mens der endnu ikke har vist sig nogle holdbare til det modsatte - diskussionerne kan næsten altid koges ned til at man ikke bryder sig om tilvænningsperioden.
Hovedmålet når der skal findes en oversættelse af et ord, er altså at det er et godt, letforståeligt dansk ord. Til tider kan andre delmål så spille ind når et konkret ord skal - hvis der f.eks. er præcedens på området, kan det være ønskeligt at søge i en bestemt retning, eller det kan være en god idé at bruge et ord som let kan genkendes ud fra kendskab til det engelske (f.eks. at bruge "brandmur" som oversættelse af "firewall"). Men vi er ikke bange for at gå nye veje når det er nødvendigt.
Et ofte tilbagevendende problem i oversættelserne er at én person starter en oversættelse, hvorefter der går noget tid og et par nye versioner af programmet inden en anden kommer til som afløsning for den første der ikke har tid mere. Nr. 2 retter så de fuzzy-tekster der er, og oversætter de nye. Den anden afløses så af den tredje osv.
Konsekvensen af dette er at konsistensen i oversættelsen meget let forsvinder (et begreb kan sagtens komme til at hedde 3-4 forskellige ting bare inden for det samme program, det er skam set), og samtidig ryger der værdifuld, surt sammensparet erfaring fra f.eks. testkørsler eller opdagelsesture i kildekoden om netop denne oversættelse.
Måden at bekæmpe dette på er at skrive kommentarer. Øverst i filen kan man mageligt under listen over oversættere tilføje diverse generelle bemærkninger og måske henvisninger til andre filer der bør læses, samt en "Konventioner:"-liste hvor man skriver alle problematiske begreber sammen med de ord som de er oversat med i netop denne oversættelse (gerne med lidt forklaring eller en begrundelse).
Et omfattende eksempel er hovedet til .po-filen til Gnumeric:
# Danish translation of Gnumeric. # Copyright (C) 1999-2001 Free Software Foundation, Inc. # Jan Normann Nielsen <normann@diku.dk>, 1999. # Kenneth Christiansen <kenneth@ripen.dk>, 1999-2000. # Birger Langkjer <birger.langkjer@image.dk>, 1999. # Keld Simonsen <keld@dkuug.dk>, 2000-2001. # Morten Welinder <terra@diku.dk>, 2000. # Ole Laursen <olau@hardworking.dk>, 2001. # # Kontakt dansk@klid.dk før du ændrer i denne fil. # # Læs README - vigtigt! # # BEMÆRK at tekster fra 'command.c' skal oversættes med navneord og ikke # - direkte fra engelsk - med verber da de indgår som # # fortryd/gentag: 'handlingstekst' # # # Konventioner: # # sheet -> ark # workbook -> arbejdsbog # evaluate -> finde værdien af # range -> interval, (dog til tider) omfang # plugin -> [udvidelses]modul (indstik el. lign. bliver for kryptisk) # constraint -> begrænsning (fx "x < 10") # truncate -> afkorte (fx 2.79 -> 2) # validate -> gyldighedskontrol # array -> matrix # custom -> selvvalgt, brugerdefineret (afhængig af sammenhæng) # paste special -> avanceret indsætning # # # Formater og formatér er med ét 't'. Eksemplerne under tekstrutinerne # er danskificerede.
Det er den ene del af kommenteringsopgaven. Den anden består i at man hver gang man støder på en tvetydig eller kryptisk tekst som man så finder ud af meningen med ved f.eks. at kigge i kildekoden (med po-mode til Emacs kan man forresten gøre dette med 's') eller ved en testkørsel af programmet, sørger for at skrive en kort kommentar ved teksten så denne viden ikke går tabt.
Et eksempel fra Gimp'en:
# display er ikke skærm her, men f.eks. RGB-farve #: app/info_window.c:288 msgid "Display Type:" msgstr "Visningstype:"
Hvis man ud fra en testkørsel kan se at en slavisk følgen af den engelske original ikke er den bedste løsning, bør der også være en kommentar - et eksempel mere fra Gimp'en:
# ingen grund til forkortelse her, masser af plads #: app/gradient.c:4152 msgid "FG color" msgstr "Forgrundsfarve"
Det kan ofte være en god idé at kigge lidt på de andre oversættelser for inspiration hvis man sidder fast, f.eks. de svenske, norske og tyske.
Til tider kan man endda bare oversætte en norsk eller svensk po-fil til dansk hvis der ikke er et dansk forlæg - ellers kan man flette eksempelvis norske oversatte strenge ind hvor der ikke er dansk oversættelse, med msgmerge:
msgmerge da.po no.po -o ny.da.poOg det kan være hensigsmæssigt at fjerne fuzzyer
msgattrib --no-fuzzy da.po -o - | msgmerge -N - project.pot -o da1.po
Der er et par sed-skripter til at lave nogen forbehandling for oversættelse fra norsk og svensk til dansk, og fra dansk til svensk.
De kan f.eks. bruges ved kommandoen:
msgmerge da.po no.po | no-da > ny.da.po
Med gettext 0.11 er dette lavet om. Her skal de udenlandske tekster køres som tekstkompendium, og de skal være mærkede som fuzzy. Fx gør:
sv-da < sv.po | msgattrib --set-fuzzy | msgmerge -C - da.po da.po > da1.po
Pas nu på at der ikke slipper oldnordiske passager forbi! Vær også opmærksom på at forældede beskeder og originale fuzzy'er skal være fjernet i begge filer, at de skal være samme tegnsæt ved fletningen, og at sed-skripterne bruger tegnsættet iso-8859-1
Folk skriver ofte fejlagtigt for mange udtryk i to ord i stedet for ét, f.eks. "Evolution bruger" i stedet for "Evolution-bruger". De danske retskrivningsregler er meget strikse hvad det angår! Brug en bindestreg hvis det kniber (men pas på ikke at få for mange af dem).
Standard skal altid forbindes med et eller andet - ikke "standard værdi", men "standard-værdi" eller "standardværdi".
Kommandoen
msgfmt -vc da.po -o /usr/share/locale/da/LC_MESSAGES/<pakke>.mo
opdaterer en oversættelse lokalt så man kan komme til at teste den. Programmet skal bare genstartes.
Bydeform giver vi ofte en accent for at lette læsningen, f.eks. annullér, formatér.
O.k. staves med punktummer ifølge Retskrivningsordbogen (som i øvrigt ikke hedder andet end RO på postlisterne).
Brug kommandoen 'msgfmt -v -o /dev/null fil.po' til at checke for fejl hvis du bruger et almindeligt tekstredigeringsprogram til at lave oversættelserne (po-mode og de specialindrettede programmer har alle denne funktionalitet indbygget).
Tag et kig på stavekontrolprogrammet til .po-filer, pospell, f.eks.
pospell -n da.po -p ispell -- -d dansk -x -C -T latin1 %f
Det kan være en god idé at tilføje en linje med oplysninger om hvornår og hvem der sidst har rettet oversættelsen igennem:
# Reviewed: dato navn <epostadresse>
Sidst men ikke mindst: hvis du er i tvivl om en tekst så prøv at søg flere oplysninger om den - f.eks. ved at kigge i hjælpefilerne, i kildekoden eller ved at teste programmet. Det sidste er især vigtigt ved grafiske programmer. Vi kommer og dunker dig (hårdt) oven i hovedet hvis du ikke sørger for at få luget de værste af den slags fatale bommerter ud der kommer sig af at der er to vidt forskellige valgmuligheder og du så ikke lige har tid til at undersøge hvilken en der er den rigtige.
Hvis du stadig er i tvivl når du beslutter dig for en bestemt mulighed, så sørg for at skrive en kommentar til teksten så problemet ikke går i glemmebogen. Nogle gange har man virkelig ikke tid eller mulighed for teste en oversættelse, og så kan dette være en nødløsning.
nogen programmer til ekstra kontrol:
Denne side er vedligeholdt af Keld Simonsen. Tak især til Ole Laursen for meget tekst på siden.