Arkiv/Hjemmeside/Oversættelse

Fra GLFPD Wiki, den frie encyklopædi

Oversættelse

Tips og tricks

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).

2. Standard skal altid forbindes med et eller andet - ikke "standard værdi", men "standard-værdi" eller "standardværdi".

3. 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.

4. Bydeform giver vi ofte en accent for at lette læsningen, f.eks. annullér, formatér.

5. O.k. staves med punktummer ifølge Retskrivningsordbogen (som i øvrigt ikke hedder andet end RO på e-post-listen).

6. Brug kommandoen "msgfmt -v -o /dev/null fil.po" til at kontrollere for fejl hvis du bruger et almindeligt tekstredigeringsprogram til at lave oversættelserne (po-mode og de specialindrettede programmer har alle denne funktionalitet indbygget).

7. Tag et kig på stavekontrolprogrammet til .po-filer, {pospell|http://www.image.dk/~byrial/spellutils/}, f.eks.

pospell -n da.po -p ispell -- -d dansk -x -C -T latin1 %f

8. 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:

\# Gennemset: dato navn <e-post-adresse>

9. 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.

Kommentering

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"

Accenter

Eftersom programmer med en grafisk grænseflade er interaktive, er mange af teksterne fra grafiske programmer ofte korte kommandoer i form af et udsagnsord i bydeform, f.eks. "kopiér", "kontrollér", "markér". Det kan både dreje sig om tekster til knapper og menupunkter, men også til menuer i sig selv, f.eks. "redigér" og "formatér" i et tekstbehandlingsprogram.

Ord som "kopier", "marker" og "formater" er imidlertid tvetydige i sig selv fordi de kan forveksles med navneord. Retskrivningsordbogen giver mulighed for at sætte accenter for at undgå denne tvetydighed. Det frarådes dog fordi det som regel er unødvendigt. I almindeligt skriftligt sprog optræder bydeform ofte kun sjældent og som regel i en kontekst der gør at det er umiddelbart forståeligt at det drejer sig om et udsagnsord i bydeform, f.eks. i en dialog mellem to personer.

Den generelle holdning i danskgruppen er at situationen er anderledes for et grafisk program. Her står ordene alene uden direkte sammenhæng med anden tekst, og selvom man næsten altid kan tænke sig frem til hvilken betydning et ord står i, er det at man er nødt til at tænke over det, en hæmsko for effektiv brug af programmet. Det korte kommandosprog er netop beregnet på at begrænse læsetiden så brugeren kan reagere hurtigst muligt.

Vi sætter derfor accenter over trykstærke endelser på de fleste udsagnsord i bydeform der indeholder "-er". Vi sætter som regel også en accent selvom ordet ikke er tvetydigt, men blot lettere at genkende som bydeform med accent, f.eks. "annullér" og "redigér". Det har vist sig at fungere godt i praksis.

Personlige værktøjer