Instruktioner til oversættere
Fra GLFPD Wiki, den frie encyklopædi
Versionen fra 3. jan 2009 kl. 14:24 KennethNielsen (Diskussion | bidrag) � Gå til forrige forskel |
Nuværende version AskHLarsen (Diskussion | bidrag) Installation af PyG3T |
||
Linje 1: | Linje 1: | ||
- | Denne guide er beregnet til nye oversættere og forklarer, skridt for skridt, hvordan man laver en opdaterings af en eksisterende oversættelse eller starter en ny. Oversættelser opbevares og vedligeholdes i po-filer, så guiden vil starte med en forklaring af formatet af po-filer. | + | Denne guide er beregnet til nye oversættere og forklarer, skridt for skridt, hvordan man laver en opdatering af en eksisterende oversættelse eller starter en ny. Ved første øjekast kan denne guide virke lidt lang, men den besvarer mange af de spørgsmål, som man typisk støder på som ny oversætter, så prøv at komme igennem den. Oversættelser opbevares og vedligeholdes i po-filer, så guiden vil starte med en forklaring af formatet af po-filer. |
- | = po-filer (Gettext) = | + | Eventuelle kommentarer eller ændringsforslag sendes til [http://www.dansk-gruppen.dk/ dansk-gruppens] e-mail-liste (dansk@dansk-gruppen.dk). |
- | Internationalisering og lokalisering håndteres indenfor fri software hovedsageligt ved hjælp af et program som hedder Gettext. Måden det fungerer på er, at alle de tekststrenge som skal bruges i et program skrives på en bestemt måde, som gør det muligt at samle dem alle sammen i en po-fil. Denne fil kan så oversættes og oversættelserne kan begefter hives tilbage og bruges i programmet. Det betyder derfor, at alle de tekststrenge, som skal oversættes, er samlet i en enkelt fil (en po-fil) og for en oversætter er det derfor kun nødvendigt at lære hvordan denne fil ser ud, og ikke (sådan som nogle frygter) at skulle lære det programmeringssprog programmet er skrevet i. | + | = Gettext og po-filer = |
+ | |||
+ | Internationalisering og lokalisering håndteres indenfor fri software hovedsageligt, ved hjælp af et program som hedder [http://www.gnu.org/software/gettext/ Gettext]. Måden det fungerer på er, at alle de tekststrenge som skal bruges i et program skrives på en bestemt måde, som gør det muligt at samle dem alle sammen i en po-fil. Denne fil kan så oversættes og oversættelserne kan begefter hives tilbage og bruges i programmet. Det betyder, at alle de tekststrenge, som skal oversættes, er samlet i en enkelt fil (en po-fil) og for en oversætter er det derfor kun nødvendigt at lære hvordan denne fil ser ud, og ikke (sådan som nogle frygter) at skulle lære det programmeringssprog programmet er skrevet i. | ||
+ | |||
+ | (Meget af den information om hvordan po-filer er indrettet, som står beskrevet i denne sektion, er fundet i den del [http://www.gnu.org/software/gettext/manual/gettext.html Gettext-dokumentationen] som omhandler netop [http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files po-filer]. Dette er et godt sted at kigge, hvis man vil vide mere om hvordan det hele hænger sammen.) | ||
== En po-filsektion == | == En po-filsektion == | ||
- | En po-fil består af mange små sektioner af tekst (adskilt af en blank linje). Hver bid svarer til en tekststreng fra programmet. En sådan sektion har den følgende struktur: | + | En po-fil består af mange små sektioner af tekst (adskilt af en blank linje). Hver bid svarer til én tekststreng fra programmet. En sådan sektion har den følgende struktur: |
blank linje | blank linje | ||
Linje 18: | Linje 22: | ||
msgstr "oversatte streng" | msgstr "oversatte streng" | ||
- | Linjen som begynder med <code>msgid</code> er den uoversatte streng, altså den | + | Linjen som begynder med <code>msgid</code> er den uoversatte streng, altså den streng i programmet som programmøren har markeret til oversættelse. Linjen som begynder med <code>msgstr</code> er den dertil hørenden oversættelse og altså den linje, som man som oversætter skal udfylde. Alle linjerne som starter med <code>#</code> er kommentarer. Der er forskellige typer af kommentarer, som tjener forskellige formål. De kan kendes fra hinanden alt efter hvilket tegn som følger umiddelbart efter <code>#</code>. |
- | streng i programmet som programmøren har markeret til | + | |
- | oversættelse. Linjen som begynder med <code>msgstr</code> er den dertil hørenden | + | |
- | oversættelse og altså den linje som man som oversætter skal | + | |
- | udfylde. Alle linjerne som starter med <code>#</code> er | + | |
- | kommentarer. Der er forskellige typer af kommentarer, som tjener | + | |
- | forskellige formål. De kan kendes fra hinanden alt efter hvilket tegn | + | |
- | som følger umiddelbart efter <code>#</code>. | + | |
- | *<code># </code> er en oversætterkommentar. Her kan oversætterne lave kommentarer om deres oversættelse, enten til sig selv eller til den næste oversætter af projektet. Disse er virkelig praktiske, hvis man har været nødt til at lave research til oversættelsen af en bestemt streng, for at sikre at den viden og det arbejde ikke går tabt. | + | :*<code># </code> er en oversætterkommentar. Her kan oversætterne lave kommentarer om deres oversættelse, enten til sig selv eller til den næste oversætter af projektet. Disse er virkelig praktiske, hvis man har været nødt til at lave research til oversættelsen af en bestemt streng, for at sikre at den viden og det arbejde ikke går tabt. |
- | *<code>#.</code> er en programmørkommentar til oversætterne. Enhver kommentar som programmøren skriver umiddelbart før en streng som er markeret til oversættelse, vil blive trukket ud og tilføjet po-filen sådan så programmørerne har muligheden for at forklare meningen med en bestemt streng. | + | :*<code>#.</code> er en programmørkommentar til oversætterne. Enhver kommentar som programmøren skriver umiddelbart før en streng, som er markeret til oversættelse, vil blive trukket ud og tilføjet po-filen sådan så programmørerne har muligheden for at forklare meningen med en bestemt streng. |
- | *<code>#:</code> er kildekodereferencer. Her vil stå filnavne og linjenumre på de steder i kildekoden hvor den pågældende streng står. | + | :*<code>#:</code> er kildekodereferencer. Her vil stå filnavne og linjenumre, på de steder i kildekoden hvor den pågældende streng står. |
- | *<code>#,</code> er mærker som er tildelt den pågældende streng. Disse er som regel mærker, der beskriver hvilket programmeringssprog strengene kommer fra. Derudover kan strengene også tildeles mærket <code>fuzzy</code>. Dette mærke bruges enten, hvis der i forvejen var en oversættelse, men originalstrengen eller positionen af denne ændrer sig i kildekoden, i det tilfælde vil mærket være sat automatisk af programmet som trækker oversættelser ud af kildekoden. Men mærket kan også bruges af oversætterne selv til at indikerer at arbejdet med denne streng ikke er færdigt. Streng med mærker <code>fuzzy</code> vil ikke blive brugt. | + | :*<code>#,</code> er mærker som er tildelt den pågældende streng. Disse er som regel mærker, der beskriver hvilket programmeringssprog strengene kommer fra. Derudover kan strengene også tildeles mærket <code>fuzzy</code>. Dette mærke bruges enten, hvis der i forvejen var en oversættelse, men originalstrengen eller positionen af denne ændrer sig i kildekoden, i det tilfælde vil mærket være påhæftet automatisk af programmet som trækker oversættelser ud af kildekoden. Men mærket kan også bruges af oversætterne selv, til at indikerer at arbejdet med denne streng ikke er færdigt. Så længe mærket <code>fuzzy</code> er til stede, vil den pågældende streng ikke bliver brugt. |
- | *<code>#|</code> er en ny form for kommentar som bruges til at vise den gamle originalstreng hvis den er ændret i kildekoden. Dette er ment som en service overfor oversætteren, således at når man komme til en <code>fuzzy</code> streng, så behøver man ikke at gætte på hvordan den har ændret sig, men kan med det samme se det, og derved lettere finde ud af hvordan man skal ændre sin oversættelse. | + | :*<code>#|</code> er en ny form for kommentar, som bruges til at vise den gamle originalstreng, hvis den er ændret i kildekoden. Dette er ment som en service overfor oversætteren, således at når man kommer til en <code>fuzzy</code> streng, så behøver man ikke at gætte på hvordan den har ændret sig, men kan med det samme se det, og derved lettere finde ud af hvordan man skal ændre sin oversættelse. |
== po-filhovedet == | == po-filhovedet == | ||
- | Den første streng i en po-fil, som har en <code>msgid</code> som er | + | Den første streng i en po-fil, som har en <code>msgid</code> som er tom (<code>""</code>), er speciel. Denne bliver brugt som en filhoved og bruges til at indeholde forskellig information. Et filhoved bør se ud som dette her fra [http://projects.gnome.org/gedit/ gedit]: |
- | tom(""), er speciel. Dennne bliver brugt som en filhoved og bruges til | + | |
- | at indeholde forskellig information. Et filhoved bør se ud som dette | + | |
- | her fra gedit: | + | |
# Danish translations of gedit. | # Danish translations of gedit. | ||
# Copyright (C) 1999-2007 Free Software Foundation, Inc. | # Copyright (C) 1999-2007 Free Software Foundation, Inc. | ||
- | # This file is distributed under the same license as the gedit | + | # This file is distributed under the same license as the gedit package. |
- | package. | + | |
# | # | ||
# Birger Langkjer <birger.langkjer@image.dk>, 1999. | # Birger Langkjer <birger.langkjer@image.dk>, 1999. | ||
Linje 76: | Linje 69: | ||
"Plural-Forms: nplurals=2; plural=(n != 1);\n" | "Plural-Forms: nplurals=2; plural=(n != 1);\n" | ||
- | I kommentaren til denne specielstreng findes først noget | + | I kommentaren til denne specielstreng findes først noget ophavsretsinformation, her skal man som oversætter huske at opdatere årstallet således at det stadig inkluderer det år man er i. Derefter følger en liste af navne og e-mail-adresser for alle de oversættere, som har arbejdet på filen, her skal man selvfølgelig også skrive sig selv på. Dette er også et godt sted at kigge, hvis man af forskellige årsager vil kontakte sidste oversætter. Her er også en kommentar om at man skal huske at skrive sig selv på "credit"-listen, [[#"translator-credits"-strengen|mere om det senere]]. Derefter følger en liste af konventioner, som de forskellig oversættere har lavet for denne oversættelse, husk at bruge og opdatere denne. Efter kommentaren kommer selve strengen, som indeholder forskellige former for specielinformation. Der er kun 3 af linjerne som man behøver at bekymre sig om som oversætter. Man skal opdatere linjen <code>Last-Translator</code> med sit eget navn og e-mail, samt sikre sig at linjen <code>Language-Team</code> indeholder informationen <code>Danish <dansk@dansk-gruppen.dk></code>, hvis den ikke gøre det i forvejen. Derudover er der linjen <code>Plural-Forms</code> som beskriver hvilke flertalsformer man har på det på sprog som filen oversættes til, [[#Flertalsformer|mere om det senere]]. |
- | ophavsretsinformation, her skal man som oversætter huske at opdatere | + | |
- | årstallet således at det stadig inkluderer man er i. Derefter følger | + | |
- | en liste af navne og e-mail-adresser for alle de oversættere som har | + | |
- | arbejdet på filen, her skal man selvfølgelig også skrive sig selv | + | |
- | på. Dette er også et godt sted at kigge hvis man af forskellige | + | |
- | årsager vil kontakte sidste oversætter. Her er så også en kommentar om | + | |
- | at man skal huske at skrive sig selv på "credit"-listen, mere om det | + | |
- | senere. Derefter følger en liste af konventioner som de forskellig | + | |
- | oversættere har lavet for denne oversættelse, husk at bruge og | + | |
- | opdatere denne. Efter kommentaren komme selve strengen som indeholder | + | |
- | forskellige former for specielinformation. Der er kun 3 af linjerne | + | |
- | som man behøver at bekymre sig om som oversætter. Man skal opdatere | + | |
- | linjen <code>Last-Translator</code> med sit eget navn og e-mail, samt | + | |
- | sikre sig at linjen <code>Language-Team</code> indeholder | + | |
- | informationen <code>Danish <dansk@dansk-gruppen.dk></code>, hvis den | + | |
- | ikke gøre det i forvejen. Derudover er der linjen | + | |
- | <code>Plural-Forms</code> som beskriver hvilke man flertalsformer man | + | |
- | har på det på sprog som filen oversættes til, mere om det senere. | + | |
== Flertalsformer == | == Flertalsformer == | ||
- | Når man skriver tekststrenge i et program, har man muligheden for at | + | Når man skriver tekststrenge i et program, har man muligheden for at [http://en.wikipedia.org/wiki/Printf skrive en variabel ind i strengen], som vil blive erstattet af noget andet, f.eks. et tal eller noget andet tekst. Hvis det der bliver sat ind, er et tal, vil det være nødvendigt for strengen at ændre sig alt efter hvad dette tal er. Det forklares måske nemmest med at eksempel, igen fra gedit |
- | skrive en variabel ind i strengen, som vil blive erstattet af noget | + | |
- | andet, f.eks. et tal eller noget andet tekst. Hvis det der bliver sat | + | |
- | ind er et tal vil det være nødvendigt for at strengen at ændre sig alt | + | |
- | efter hvad dette tal er. Det forklares måske nemmest med at eksempel, | + | |
- | igen fra edit | + | |
#: ../gedit/gedit-commands-file.c:266 | #: ../gedit/gedit-commands-file.c:266 | ||
Linje 112: | Linje 82: | ||
msgstr[1] "Indlæser %d filer..." | msgstr[1] "Indlæser %d filer..." | ||
- | I denne type af strenge er der nu 2 <code>msgid</code>'er, en for hver | + | I denne type af strenge er der nu 2 <code>msgid</code>'er, en for hver af de forskellige former der er på engelsk. Herefter skal der så være en <code>msgstr</code>, for hver af de forskellige flertalsformer der findes på dansk. Efter <code>msgstr[0]</code> skal stå den danske streng, som svarer til at der er nøjagtig 1 og efter <code>msgstr[1]</code> skal stå den streng, som svarer til at der er 0 eller flere (mere end 1). Grunden til at man har lavet det på denne måde, i stedet for bare at lave det som 2 strenge, er at andre sprog har væsentligt mere indviklede regler for flertalsformer og i flere tilfælde mere end 2 former. |
- | af de forskellige former der er på engelsk. Herefter skal der så være | + | |
- | en <code>msgstr</code> for hver af de forskellige flertalsformer der | + | |
- | findes på dansk. Efter <code>msgstr[0]</code> skal stå den danske | + | |
- | streng, som svarer til at der er nøjagtig 1 og | + | |
- | efter <code>msgstr[1]</code> skal stå den streng som svarer til at der | + | |
- | er 0 eller mere end 1. Grunden til at man har lavet det på denne måde, | + | |
- | i stedet for bare at lave det som 2 streng, er at andre sprog har | + | |
- | væsentligt mere indviklede regler for flertalsformer og i flere end 2 | + | |
- | former. | + | |
- | ''VIGTIGT:'' Eftersom det kan variere fra sprog til sprog hvordan man | + | Eftersom det kan variere fra sprog til sprog, hvordan man laver flertalsformer, er man nødt til at definere dette i filen, hvis der findes sådan nogle <code>plural</code>-strenge som denne her. Dette gøres med den linje i filhovedet, som starter med <code>Plural-Forms:</code> og den skal for danske oversættelser have værdien <code>nplurals=2; plural=(n != 1);</code>. Hvis man støder på en uoversat flertalsstreng, skal man derfor sikre sig at denne linje er i filhovedet, eller får man en fejl senere når man kontrollerer filen for fejl. |
- | laver flertalsformer er man nødt til at definere dette i filen hvis | + | <!-- indsæt reference til syntakskontrolsektionen --> |
- | der findes sådan nogle <code>plural</code>-streng som denne her. Dette | + | |
- | gøres med den linke i filhovedet som starter | + | |
- | med <code>Plural-Forms:</code> og den skal for danske oversættelser | + | |
- | have værdien <code>nplurals=2; plural=(n != 1);</code>. Hvis man | + | |
- | støder på en uoversat flertalsstreng, skal man derfor sikre sig at | + | |
- | denne linje er i filhovedet, eller får man en fejl senere når man | + | |
- | kontrollerer filen for fejl. | + | |
== Specielle entiteter i strenge == | == Specielle entiteter i strenge == | ||
- | De fleste strenge indeholder blot almindelig tekst, men der er også | + | Nogle strenge indeholder blot almindelig tekst, men der er også indtil flere specielle entiteter, som man kan støde på og som det som ny oversætter, kan være svært at vide hvad man skal gøre ved. Disse er beskrevet i de følgende undersektioner. |
- | indtil flere specielle ting som man kan støde på og som det som ny | + | |
- | oversætter kan være svært at vide hvad man skal gøre ved. Disse er | + | |
- | beskrevet i de følgende undersektioner. | + | |
=== Variable === | === Variable === | ||
- | Som tidligere nævnt kan man bruge variable i programstrenge og bruge | + | Som [[#Flertalsformer|tidligere nævnt]] kan man bruge variable i programstrenge og bruge disse, til at få sat et eller andet ind i strengen. Det kan være alt lige fra tal, fil-navne eller -stier, eller blot noget andet tekst. Der vil stå en variabel, det sted i strengen hvor dette skal sættes ind. Hvordan disse variable ser ud, vil afhænge af hvilket programmeringssprog programmet er skrevet i. Det kan f.eks. være sådan nogle som <code>%s</code>, <code>%d</code> og <code>%i</code>. Der er for mange muligheder, inden for de forskellige sprog, til at skrive dem alle sammen her, så hvis man som oversætter er i tvivl om noget er en variabel, må man endelig spørge. Det vigtige ved disse strenge er ''at man bevarer dem''. Når man er færdig med strengen, skal der altid stå de samme variable, som der gør i originalstrengen. Nogle (sjældne) gange vil det være nødvendigt, at bytte rundt på rækkefølgen af disse variable og her skal man være forsigtig. Måden at gøre dette på vil varierer fra sprog til sprog og hvis man støder på problemet, er det derfor nemmere at spørge og så finder vi en løsning i det pågældende tilfælde. |
- | disse til at få sat et eller andet ind i strengen. Det kan være alt | + | |
- | lige fra tal, fil-navne eller -stier eller blot noget andet tekst. Der | + | |
- | vil så stå en variabel, det sted i strengen hvor dette skal sættes | + | |
- | ind. Hvordan disse variable ser ud, vil afhænge af hvilket | + | |
- | programmeringssprog programmet er skrevet på. Det kan f.eks. være | + | |
- | sådan nogle som <code>%s</code>, <code>%d</code> | + | |
- | og <code>%i</code>. Der er for mange muligheder inden for de | + | |
- | forskellige sprog til at skrive dem alle sammen her, så hvis man som | + | |
- | oversætter er i tvivl om noget er en variabel må man endelig | + | |
- | spørge. Det vigtig ved disse strenge er ''at man bevarer dem''. Når | + | |
- | man er færdig med strengen, skal der altid stå de samme variable som | + | |
- | der gør i originalstrengen. Nogle gange vil det være nødvendigt at | + | |
- | bytte rundt på rækkefølgen af disse variable og her skal man være | + | |
- | forsigtig. Måden at gøre dette på vil varierer fra sprog til sprog og | + | |
- | hvis man støder på problemet, er det derfor nemmere at spørge og så | + | |
- | finder vi en løsning. | + | |
- | === Genvejstegn === | + | === Tastaturgenveje === |
- | Strenge som skal have et bogstav associeret med sig, således at disse | + | Strenge som skal have et bogstav associeret med sig, således at disse bogstaver kan komme til at fungere som genvejs-"tegn", håndteres i oversættelser ved at sætte et tegn foran det bogstav, som skal være genvejstegn. Denne form for tastaturgenveje i programmer er kendetegnet ved, at der er en streg under bogstavet, som fremhævet med gult i [http://upload.wikimedia.org/wikipedia/en/e/e2/Firefoxshortcuts.png dette billede]. Hvilket tegn der bliver brugt, til at markere dette kan variere fra projekt til projekt, men i næsten alle GNOME-relaterede projekter bruger bundstregen "_". Et eksempel på sådan en streng kunne være "Save" i filmenuen, vist hernedenunder. |
- | bogstaver kan komme til at fungere som genvejstegn (kendetegnet i | + | |
- | programmer ved at der er en streg under bogstavet), håndteres i | + | |
- | oversættelser ved at sætte et tegn foran det bogstav som skal være | + | |
- | genvejstegn. Hvilket tegn der bliver brugt til at markere dette kan | + | |
- | variere fra projekt til projekt, men i næsten alle GNOME-relaterede | + | |
- | projekter bruger bundstregen "_". Et eksempel på sådan en streng kunne | + | |
- | være "Save" i filmenuen, vist hernedenunder | + | |
msgid "_Save" | msgid "_Save" | ||
msgstr "_Gem" | msgstr "_Gem" | ||
- | På engelsk er der valgt "s" som genvejstegn og i den danske version | + | På engelsk er der valgt "s" som genvejstegn og i den danske version har man valgt "g". Det er vigtigt at sørge for, at man får defineret sådan et genvejstegn, når der er et i originalstrengen. Det er også vigtigt at man tænker lidt over hvilke tegn man bruger, sådan at genvejtegnene bliver så konsistente som muligt, på tværs af programmerne og at man ikke bruger det samme tegn til flere strenge i f.eks. den samme menu. |
- | har man valgt "g". Det er vigtigt at sørge for, at man får defineret | + | |
- | sådan et genvejstegn, når der er et i originalstrengen. Det er også | + | |
- | vigtigt at man tænker lidt over hvilke tegn man bruger, sådan at | + | |
- | genvejtegnene bliver så konsistente som muligt på tværs af | + | |
- | programmerne og at man ikke bruger det samme tegn til flere strenge | + | |
- | i f.eks. den samme menu. | + | |
=== Opmærkning === | === Opmærkning === | ||
- | I visse sammenhænge bliver de tekststrenge som skal oversættes | + | I visse sammenhænge bliver de tekststrenge, som skal oversættes, formatteret ved hjælp af [[:Wikipedia:Markup_language|opmærkning]], i stil med måden man skriver hjemmesider på. Så hvis man f.eks. vil have noget tekst til at stå med '''fed''' skrifttype, så skriver man <code><bold>'''fed tekst'''</bold></code>. Det sidste mærke, som har en skråstreg i sig, er det afsluttende eller lukkende mærke. Man kan indlejre sådanne mærker, således, at hvis man i en streng som er fed, vil have noget til både at være med fed og på skrå, kan man skrive <code><bold>'''både fed '''<italic>'''''og på skrå'''''</italic></bold></code>. Som oversætter er det vigtigt at huske på at lukke indlejrede mærker på samme måde som i originalen. |
- | formatteret ved hjælp af opmærkning i stil med måden man skriver | + | |
- | hjemmesider på. Så hvis man f.eks. vil have noget tekste med '''fed''' | + | |
- | skrifttype så skriver man <code><bold>'''fed | + | |
- | tekst'''</bold></code>. Det sidste, som har en skråstreg i sig, er det | + | |
- | afsluttende eller lukkende mærke. Man kan indlejre sådanne mærker, | + | |
- | således at hvis man i en streng som er fed vil have noget til både at | + | |
- | være med fed og på skrå kan man skrive <code><bold>'''både fed | + | |
- | '''<italic>''''og på skrå''''</italic></bold></code>. Det er vigtigt | + | |
- | at lukke indlejrede mærker på samme måde som i originalen. | + | |
- | === Lodret stregtegn "|" (en. pipecharacter) === | + | === Lodret stregtegn "|" (en. pipe character) === |
- | Hvis den samme tekstreng optræder mere end en gang i et program, vil | + | Hvis den samme tekststreng optræder mere end en gang i et program, vil Gettext samle det til en sektion i po-filen, som vil have flere kildekodereferencer. Selv om dette er rigtigt smart og hjælper ufattelig meget i langt størstedelen af tilfældende, er der visse tilfælde hvor det ikke dur. Det kan være, hvis det samme ord kan betyder mere end en ting og bruges forskellig flere steder i programmet. Det kunne (som et tænkt eksempel) være et program, hvor man måler ydelse af et eller andet og samtidig kan gemme og indlæse profiler, for hvordan det bliver vist. I sådan et program kunne man forestille sig, at strengen "Load" bliver brugt både i betydningen "Belastning" og i betydningen "Indlæs". Hvis strengene bliver samlet til en, er det selvfølgelig ikke muligt at oversætte det til to forskellige ting. I et lang stykke tid er det blevet ordnet, ved at man har hæftet et stykke kontekst på før strengen, adskilt fra selve strengen med en "|" og man har så, i en kommentar, bedt oversætterne om kun at oversætte det efter "|". Dette ville så betyde, at der nu i stedet vil være to strenge, f.eks. "Noun|Load" og "Verb|Load" som skal oversættes forskelligt. Det er meget vigtigt at være opmærksom på at gøre dette rigtigt og kun oversætte det efter "|". Denne metode er imidlertid meget sårbar for fejl og man er lige nu (December 2008) i gang med at implementere en erstatning for dette system. ''Løst forklaret vil dette nye system betyde, at der vil komme et ekstra felt ligesom <code>msgstr</code> og <code>msgid</code> som hedder <code>msgctxt</code> hvori strengens kontekst vil komme til at stå, i stedet for i selve strengen. Dette vil blive forklaret nærmere når implementeringen er nået længere.'' |
- | Gettext samle det til en sektion i po-filen, som vil have flere | + | |
- | kildekodereferencer. Selv om dette er rigtigt smart og hjælper | + | |
- | ufatteligt meget i langt størstedelen af tilfældende er der visse | + | |
- | tilfælde hvor det ikke duer. Det kan være hvis det samme ord kan | + | |
- | betyder mere end en ting og bruges forskellig flere steder i | + | |
- | programmet. Det kunne (som et tænkt eksempel) være et program hvor man | + | |
- | måler ydelse af et eller andet og samtidig kan gemme og indlæse | + | |
- | profiler for hvordan det bliver vist. I sådan et program kunne man | + | |
- | forestille sig at strengen "Load" bliver brugt, både i betydningen | + | |
- | "Belastning" og i betydningen "Indlæs". Hvis strengene bliver samlet | + | |
- | til en er det selvfølgelig ikke muligt at oversætte det til to | + | |
- | forskellige ting. I et lang stykke tid er det blevet ordnet ved at man | + | |
- | har hæftet et stykke kontekst på før strengen adskilt fra selv | + | |
- | strengen med en "|" og man har så i en kommentar bedt oversætterne om | + | |
- | kun at oversætte det efter "|". Dette ville så betyde at der nu i | + | |
- | stedet vil være to strengen f.eks. "Noun|Load" og "Verb|Load" som skal | + | |
- | oversættes forskelligt. Det er meget vigtigt at være opmærksom på at | + | |
- | gøre dette rigtigt og kun oversætte det efter "|". Denne metode er | + | |
- | umidlertid meget sårbar for fejl og man er lige nu (December 2008) i gang med at | + | |
- | implementere en erstatning for dette system. '''Løst forklaret vil | + | |
- | dette nye system betyde, at der vil komme et ekstra felt ligesom | + | |
- | <code>msgstr</code> og <code>msgid</code> som hedder | + | |
- | <code>msgctxt</code> hvor strengens kontekst vil komme til at stå, i stedet | + | |
- | for i selve strengen. Dette vil blive forklaret nærmere når | + | |
- | implementeringen er nået længere.''' | + | |
=== "translator-credits"-strengen === | === "translator-credits"-strengen === | ||
- | I nogle programmer findes en speciel streng med <code>msgid</code> | + | I nogle programmer findes en speciel streng med <code>msgid</code> "translator-credits". Denne bruges sådan, at det den bliver oversat til, indsættes i en boks (f.eks. i "Om ..."-vinduet) med folk som har bidraget til oversættelse. Det betyder, at i stedet for at oversætte den ordret skal man i stedet for indsætte en liste over folk, som har bidraget til oversættelsen, samt hold- og kontakt-information. Indenfor GNOME-oversættelser bruges altid en standard måde at udforme denne på, som ser ud som nedenfor: |
- | "translator-credits". Denne bruges sådan, at det den bliver oversat | + | |
- | til, indsættes i en boks med folk som har bidraget til | + | |
- | oversættelse. Det betyder at i stedet for at oversætte den ordret skal | + | |
- | man i stedet for indsætte en liste over folk som har bidraget til | + | |
- | oversættelsen, samt hold- og kontakt-information. Indenfor | + | |
- | GNOME-oversættelser bruges altid an standard måde at udforme denne på | + | |
- | som ser ud som nedenfor: | + | |
#: ../gedit/gedit-commands-help.c:106 | #: ../gedit/gedit-commands-help.c:106 | ||
Linje 250: | Linje 131: | ||
"Mere info: http://www.dansk-gruppen.dk" | "Mere info: http://www.dansk-gruppen.dk" | ||
- | Som det kan ses, er det altså først en liste af navne på | + | Som det kan ses, er det altså først en liste af navne på bidragsyderne, herefter en blank linje og til sidst to linjer med navn og kontaktinformation for holdet. |
- | bidragsyderne, herefter en blank linje og til sidst to linjer med navn | + | |
- | og kontaktinformation for holdet. | + | |
- | = Hjælpeprogrammer (poabc og podiff) = | + | = Hjælpeprogrammer (pyg3t) = |
- | Ud over det program man bruger til at redigere po-filen med, er der to små kommandolinjeprogrammer som bruges i løbet af et oversættelsesforløb, poabc og podiff. | + | Ud over det program man bruger til at redigere po-filen med, er der en samling mindre kommandolinjeprogrammer, kaldet [https://launchpad.net/pyg3t PyG3T], som bruges i løbet af et oversættelsesforløb. PyG3T indeholder blandt andet poabc og podiff, som beskrives nedenfor. |
== poabc == | == poabc == | ||
- | poabc (ABC står for Automatic Blunder Corrector) er et program, som man kan bruge til at lede efter typiske fejl i en oversættelse, efter at man er færdig med den. Blandt de fejl som poabc kigger efter er om man har glemt strengens afsluttende punktum eller mellemrum, at man ikke har korrekt stort eller lille bogstav i starten og om man har husket genvejsbogstavstegnet hvis der er sådan et i originalen. poabc køres fra terminalen, med filen der skal tjekkes som argument | + | poabc (ABC står for Automatic Blunder Corrector) er et program, som man kan bruge til at lede efter typiske fejl i en oversættelse, efter at man er færdig med den. Blandt de fejl som poabc kigger efter er, om man har glemt strengens afsluttende punktum eller mellemrum, at man ikke har korrekt stort eller lille bogstav i starten og om man har husket genvejsbogstavstegnet hvis der er sådan et i originalen. poabc køres fra terminalen, med filen der skal tjekkes som argument, |
poabc gedit.po | poabc gedit.po | ||
Linje 278: | Linje 157: | ||
msgstr "Slet nogle filer fra projektet" | msgstr "Slet nogle filer fra projektet" | ||
- | Uddata ovenfor viser de mest typiske former for fejl som poabc vil rapportere i sin uddata. Desværre vil de kriterier som poabc er sat til at registrer som fejl, også nogle gange give falske positive, altså advarsler hvor der ikke er noget i vejen. Det er dog hurtigt at gennemgå uddata fra poabc og sortere de falske advarsler fra og bruge de rigtige, og brugen af poabc vil ofte fange en del fejl, selv for rutinerede oversættere. Et eksempel på en falsk fejlbesked kan se nedenfor. | + | Uddata ovenfor viser de mest typiske former for fejl, som poabc vil rapportere i sin uddata. Desværre vil de kriterier som poabc er sat til at registrere som fejl, også nogle gange give falske positive, altså advarsler hvor der ikke er noget i vejen. Det er dog hurtigt at gennemgå uddata fra poabc og sortere de falske advarsler fra og bruge de rigtige, og brugen af poabc vil ofte fange en del fejl, selv for rutinerede oversættere. Et eksempel på en falsk fejlbesked kan ses nedenfor. |
=== Line 708 : Leading character type or case mismatch === | === Line 708 : Leading character type or case mismatch === | ||
Linje 284: | Linje 163: | ||
msgstr "kun %s" | msgstr "kun %s" | ||
- | Her har poabc taget fejl, fordi den fordi den forventer at strengen starter med et tegn, men i den danske streng er variablen rykket over til sidst og derfor starter den danske streng med et bogstav. Man kan også bede poabc om at tjekke om filens syntaks er korrekt (mere om hvordan man gør det manuelt længere nede). Dette gøre med tilvalgt m efter kommandoen | + | Her har poabc taget fejl, fordi den forventer at strengen starter med et tegn, men i den danske streng er variablen rykket over til sidst og derfor starter den danske streng med et bogstav. |
- | + | ||
- | poabc m gedit.po | + | |
== podiff == | == podiff == | ||
Linje 292: | Linje 169: | ||
podiff bruges til at dokumentere de ændringer, man har lavet i en po-fil under en opdatering, på en sådan måde at det er nemt at læse korrektur på ændringer. Dansk-gruppen læser korrektur på alle oversættelser før de integreres, men for at man ikke skal læse hele oversættelsen igennem, hver gang der bliver foretaget en opdatering, gennemlæses kun de dele af filen som er blevet opdateret. | podiff bruges til at dokumentere de ændringer, man har lavet i en po-fil under en opdatering, på en sådan måde at det er nemt at læse korrektur på ændringer. Dansk-gruppen læser korrektur på alle oversættelser før de integreres, men for at man ikke skal læse hele oversættelsen igennem, hver gang der bliver foretaget en opdatering, gennemlæses kun de dele af filen som er blevet opdateret. | ||
- | Måden podiff bruges på er som følger. Når man skal til at opdatere en oversættelse vil man først hente den fil ned man skal arbejde med. Før man går i gang med oversætterarbejdet laver man en kopi af denne fil, som skal dokumentere hvordan filen så ud før (hvilket er nødvendig fordi podiff skal dammenligne før med bagefter). Denne ubearbejdede kopi kaldes her for "gammel.po". Efter at oversættelsen er færdig og kontrolleret på alle tænkelige måder, har man en anden fil, som her kaldes for "ny.po". Med disse to filer kører man podiff på følgende måde | + | Måden podiff bruges på er som følger. Når man skal til at opdatere en oversættelse, vil man først hente den fil ned man skal arbejde med. Før man går i gang med oversætterarbejdet, laver man en kopi af denne fil, som skal dokumentere hvordan filen så ud før (hvilket er nødvendig fordi podiff skal sammenligner før med bagefter). Denne ubearbejdede kopi kaldes her for "gammel.po". Efter at oversættelsen er færdig og kontrolleret på alle tænkelige måder, har man en anden fil, som her kaldes for "ny.po". Med disse to filer kører man podiff på følgende måde |
podiff gammel.po ny.po | podiff gammel.po ny.po | ||
- | Dette vil så udskrive uddata til terminalen. Eftersom man senere skal vedhæfte dette til e-mail, er det praktisk at få gemt dette uddata til en fil. Det gør man ved at videresende uddata til en, på følgende måde | + | Dette vil så udskrive uddata til terminalen. Eftersom man senere skal vedhæfte dette til e-mail, er det praktisk at få gemt dette uddata til en fil. Det gør man ved at videresende uddata til en fil, på følgende måde |
podiff gammel.po ny.po > gammel_ny_diff.podiff | podiff gammel.po ny.po > gammel_ny_diff.podiff | ||
- | Uddata fra podiff vil typisk se ud på følgende måde, bemærk at et "-" foran en streng betyder at det var sådan, den så ud i "gammel.po" og et "+" foran en streng betyder, at det er sådan den ser ud i "ny.po" | + | Uddata fra podiff vil typisk se ud som vist længere nede, bemærk at et "-" foran en streng betyder at det var sådan, den så ud i "gammel.po" og et "+" foran en streng betyder, at det er sådan den ser ud i "ny.po" |
#: ../xfburn/xfburn-device-box.c:627 ../xfburn/xfburn-device-box.c:670 | #: ../xfburn/xfburn-device-box.c:627 ../xfburn/xfburn-device-box.c:670 | ||
Linje 313: | Linje 190: | ||
+msgstr "Ingen disk er fundet i drevet." | +msgstr "Ingen disk er fundet i drevet." | ||
- | Her ses to typiske eksempler på en opdateringsstreng. Den første er en uoversat streng som er blevet oversat. Det kan ses idet der var en tom <code>msgstr</code> i "gammel.po" og en dansk tekstreng i "ny.po". Den anden er en streng er en som er blevet fuzzy. Det er den, i dette her tilfælde, højst sandsynligt blevet fordi udviklerne har tilføjet et punktum til sidst i strengen. Man kan se, at det oversætteren har gjort, er at opdatere oversættelsen, sådan så den passer til denne ændring, således at oversættelsen nu også har et punktum til sidst, samt at fjerne <code>fuzzy</code>-mærket fra mærkekommentaren. <code>fuzzy</code>-mærket var blevet indsat automatisk fordi Gettext har indset at dette højst sandsynligt stadig er den gamle streng der er tale, men at den blot er blevet ændret. | + | Her ses to typiske eksempler på opdateringsstrenge. Den første er en uoversat streng, som er blevet oversat. Det kan ses idet der var en tom <code>msgstr</code> i "gammel.po" og en dansk tekststreng i "ny.po". Den anden er en streng, som er blevet fuzzy. Det er den, i dette her tilfælde, højst sandsynligt blevet, fordi udviklerne har tilføjet et punktum til sidst i strengen. Man kan se, at det oversætteren har gjort, er at opdatere oversættelsen, sådan så den passer til denne ændring, således at oversættelsen nu også har et punktum til sidst, samt at fjerne <code>fuzzy</code>-mærket fra mærkekommentaren. <code>fuzzy</code>-mærket var blevet indsat automatisk, fordi Gettext har indset, at dette højst sandsynligt stadig er den gamle streng der er tale, men at den blot er blevet ændret. |
- | == Installation af poabc og podiff == | + | == Installation af PyG3T == |
- | Både poabc og podiff er simple eksekverbare Python-skripter og skal som sådan ikke "installeres", men blot hentes ned, gøres eksekverbare og placeres i ens $PATH. | + | PyG3T udgives under GPL og kan hentes fra [https://launchpad.net/pyg3t/+download Launchpad] enten som tarball eller RPM. For Ubuntubrugere installeres det nemmest via dets [https://launchpad.net/~pyg3t-dev-team/+archive/ppa personlige pakkearkiv] (mere detaljerede instruktioner om installation fra personlige pakkearkiver kan om nødvendigt findes på [https://help.launchpad.net/Packaging/PPA/InstallingSoftware Launchpads PPA-hjælpeside]). |
- | For poabc gøres følgende (disse er kommandoer der skal køres i en kommandoskal) | + | For ikke-Ubuntubrugere installeres PyG3T nemmest ved at hente nyeste udgave fra [https://launchpad.net/pyg3t/+download download-siden], pakke filen ud med kommandoen |
+ | tar xzf pyg3t-version.tar.gz, og dernæst køre: | ||
- | wget http://www.student.dtu.dk/~ashj/translation/poabc | + | sudo python setup.py install |
- | chmod +x poabc | + | |
- | sudo mv poabc /usr/local/bin/poabc | + | |
- | for podiff er proceduren den samme | + | Programmerne kan også installeredes uden superbrugeradgang ved at tilføje bin-mappen fra den udpakkede tar.gz-fil til $PATH, samt pyg3t-undermappen til $PYTHONPATH. |
- | wget http://www.student.dtu.dk/~s021749/podiff/podiff.py | + | Mere information kan findes i [http://article.gmane.org/gmane.comp.internationalization.dansk/15995 e-brevet om udgivelsen af PyG3T] og [http://article.gmane.org/gmane.comp.internationalization.dansk/17689 e-brevet om udgivelsen af PyG3T 0.2] |
- | chmod +x podiff.py | + | |
- | sudo mv podiff.py /usr/local/bin/podiff | + | |
- | + | ||
- | herefter er disse to programmer tilgængelige ligesom almindelige kommandoer. | + | |
= Oversættelsesproceduren = | = Oversættelsesproceduren = | ||
- | Denne sektion beskriver selve oversættelsesproceduren. Det er lavet som en nummereret punktopstilling, således at hvis man løber ind i problemer, kan man henvise til det punkt man er nået til. I det følgende vil filen gedit.po blive brugt som eksempel på den fil som skal oversættes (bemærk at filer man henter ned som regel har noget længere navne, fordi navnet også indeholder information om hvilken udviklingsgren den er en del af, men det betyder ikke noget for proceduren). | + | Dette afsnit beskriver selve oversættelsesproceduren. Det er lavet som en nummereret punktopstilling, således at hvis man løber ind i problemer, kan man henvise til det punkt man er nået til. I det følgende vil filen gedit.po blive brugt som eksempel på den fil som skal oversættes (bemærk at filer man henter ned som regel har noget længere navne, fordi navnet også indeholder information om hvilken udviklingsgren den er en del af, men det betyder ikke noget for proceduren). |
- | :# Find en oversættelse som du har lyst til at tage fat på (f.eks. gedit) og send en e-mail til dansk-gruppens e-mail-liste med emnet "Jeg går i gang med gedit". Hvis du ikke har været på listen så længe, så vent gerne lige en dags tid for at se om der er nogen som protesterer, enten fordi de allerede er i gang med den, eller fordi de selv tidligere har oversat den og godt kunne tænke sig at fortsætte med det. | + | :# '''Find en oversættelse''' som du har lyst til at tage fat på (f.eks. gedit) og send en e-mail til dansk-gruppens e-mail-liste med emnet "[GNOME] Jeg går i gang med gedit" ([GNOME] i dette tilfælde fordi gedit kommer fra GNOME). Hvis du ikke har været på listen så længe, så vent gerne lige en dags tid for at se om der er nogen som protesterer, enten fordi de allerede er i gang med den, eller fordi de selv tidligere har oversat den og godt kunne tænke sig at fortsætte med det. |
- | :# Hent filen ned fra internettet. | + | :# '''Hent filen''' ned fra internettet. |
- | :# Lav en kopi af filen sådan som den ser ud før du går i gang med at oversætte den (F.eks. med følgende kommandio: <code>cp gedit.po gedit_gammel.po</code>) | + | :# '''Lav en kopi af filen''' sådan som den ser ud før du går i gang med at oversætte den (F.eks. med følgende kommando: <code>cp gedit.po gedit_gammel.po</code>) |
- | :# Oversæt filen ved brug af et af [[Oversættelsesprogrammer de programmer beskrevet her]] eller et andet hvis du foretrækker og gør brug af retninglinjer og fif nedenfor. | + | :# '''Oversæt filen''' ved brug af et af [[Oversættelsesprogrammer|de programmer som er beskrevet her,]] eller et andet hvis du foretrækker, og gør brug af [[#Retningslinjer og fif til oversættelsesarbejdet|retninglinjer og fif]] nedenfor. |
- | :# Efter endt oversættelse, stavekontrol, poabc-check og syntakscheck (som beskrevet nedenfor) er filen klar til at blive gennemlæst. Nu laves en podiff for at dokumentere de ændringer du har lavet, f.eks. med følgende kommando: <code>podiff gedit_gammel.po gedit.po > gedit_gammel_ny.podiff</code> | + | :# Efter endt oversættelse, stavekontrol, poabc-check og syntakscheck (som beskrevet nedenfor<!-- indsæt referencer -->) er filen klar til at blive gennemlæst. Nu '''laves en podiff''' for at dokumentere de ændringer du har lavet, f.eks. med følgende kommando: <code>podiff gedit_gammel.po gedit.po > gedit_gammel_ny.podiff</code> |
- | :# | + | :# Uddata fra podiff '''sendes til gennemlæsning''' på dansk-gruppens e-mail-liste. Det gøres ved at sende en mail til listen med emnet "gedit til gennemlæsning (''antal strenge som er opdateret'')", hvor uddata fra podiff både indsættes i brevkroppen og vedhæftes som fil. |
+ | :# Når du modtager kommentarer fra en gennemlæser, gennemgår du dem og '''retter din oversættelse til.''' Hvis der er noget som du er uenig i, skriver du bare tilbage, hvorefter du og gennemlæseren (og evt. andre) kan tage en diskussion om stridspunkterne. Hav lidt tålmodighed med gennemlæsningen, vi er alle samme frivillige og det er ikke sikkert at der er nogen som har tid til at lave gennemlæsningen omgående. | ||
+ | :# Når alle kommentarer fra gennemlæseren er behandlet, er oversættelsen færdig og den '''sendes til integration'''. Det gøres ved at sende en e-mail til dansk-gruppens med emnet "gedit til integrering", hvorefter en fra dansk-gruppen, som har integreringsrettigheder til det pågældende projekt, vil integrere den og bekræfte dette i en e-mail | ||
+ | :# Hop tilbage til 1 og start på en ny ;) | ||
= Retningslinjer og fif til oversættelsesarbejdet = | = Retningslinjer og fif til oversættelsesarbejdet = | ||
+ | |||
+ | Følger snart | ||
+ | |||
+ | [[Bruger:KennethNielsen|KennethNielsen]] 3. jan 2009 kl. 18:33 (CET) |
Nuværende version
Denne guide er beregnet til nye oversættere og forklarer, skridt for skridt, hvordan man laver en opdatering af en eksisterende oversættelse eller starter en ny. Ved første øjekast kan denne guide virke lidt lang, men den besvarer mange af de spørgsmål, som man typisk støder på som ny oversætter, så prøv at komme igennem den. Oversættelser opbevares og vedligeholdes i po-filer, så guiden vil starte med en forklaring af formatet af po-filer.
Eventuelle kommentarer eller ændringsforslag sendes til dansk-gruppens e-mail-liste (dansk@dansk-gruppen.dk).
Indholdsfortegnelse |
Gettext og po-filer
Internationalisering og lokalisering håndteres indenfor fri software hovedsageligt, ved hjælp af et program som hedder Gettext. Måden det fungerer på er, at alle de tekststrenge som skal bruges i et program skrives på en bestemt måde, som gør det muligt at samle dem alle sammen i en po-fil. Denne fil kan så oversættes og oversættelserne kan begefter hives tilbage og bruges i programmet. Det betyder, at alle de tekststrenge, som skal oversættes, er samlet i en enkelt fil (en po-fil) og for en oversætter er det derfor kun nødvendigt at lære hvordan denne fil ser ud, og ikke (sådan som nogle frygter) at skulle lære det programmeringssprog programmet er skrevet i.
(Meget af den information om hvordan po-filer er indrettet, som står beskrevet i denne sektion, er fundet i den del Gettext-dokumentationen som omhandler netop po-filer. Dette er et godt sted at kigge, hvis man vil vide mere om hvordan det hele hænger sammen.)
En po-filsektion
En po-fil består af mange små sektioner af tekst (adskilt af en blank linje). Hver bid svarer til én tekststreng fra programmet. En sådan sektion har den følgende struktur:
blank linje # oversætterkommentarer #. kommentarer trukket ud af kildekoden #: reference... #, mærker... #| msgid "tidligere uoversatte streng" msgid "uoversatte streng" msgstr "oversatte streng"
Linjen som begynder med msgid
er den uoversatte streng, altså den streng i programmet som programmøren har markeret til oversættelse. Linjen som begynder med msgstr
er den dertil hørenden oversættelse og altså den linje, som man som oversætter skal udfylde. Alle linjerne som starter med #
er kommentarer. Der er forskellige typer af kommentarer, som tjener forskellige formål. De kan kendes fra hinanden alt efter hvilket tegn som følger umiddelbart efter #
.
#
er en oversætterkommentar. Her kan oversætterne lave kommentarer om deres oversættelse, enten til sig selv eller til den næste oversætter af projektet. Disse er virkelig praktiske, hvis man har været nødt til at lave research til oversættelsen af en bestemt streng, for at sikre at den viden og det arbejde ikke går tabt.#.
er en programmørkommentar til oversætterne. Enhver kommentar som programmøren skriver umiddelbart før en streng, som er markeret til oversættelse, vil blive trukket ud og tilføjet po-filen sådan så programmørerne har muligheden for at forklare meningen med en bestemt streng.#:
er kildekodereferencer. Her vil stå filnavne og linjenumre, på de steder i kildekoden hvor den pågældende streng står.#,
er mærker som er tildelt den pågældende streng. Disse er som regel mærker, der beskriver hvilket programmeringssprog strengene kommer fra. Derudover kan strengene også tildeles mærketfuzzy
. Dette mærke bruges enten, hvis der i forvejen var en oversættelse, men originalstrengen eller positionen af denne ændrer sig i kildekoden, i det tilfælde vil mærket være påhæftet automatisk af programmet som trækker oversættelser ud af kildekoden. Men mærket kan også bruges af oversætterne selv, til at indikerer at arbejdet med denne streng ikke er færdigt. Så længe mærketfuzzy
er til stede, vil den pågældende streng ikke bliver brugt.#|
er en ny form for kommentar, som bruges til at vise den gamle originalstreng, hvis den er ændret i kildekoden. Dette er ment som en service overfor oversætteren, således at når man kommer til enfuzzy
streng, så behøver man ikke at gætte på hvordan den har ændret sig, men kan med det samme se det, og derved lettere finde ud af hvordan man skal ændre sin oversættelse.
po-filhovedet
Den første streng i en po-fil, som har en msgid
som er tom (""
), er speciel. Denne bliver brugt som en filhoved og bruges til at indeholde forskellig information. Et filhoved bør se ud som dette her fra gedit:
# Danish translations of gedit. # Copyright (C) 1999-2007 Free Software Foundation, Inc. # This file is distributed under the same license as the gedit package. # # Birger Langkjer <birger.langkjer@image.dk>, 1999. # Kenneth Christiansen <kenneth@gnome.org>, 1999, 2000. # Keld Simonsen <keld@dkuug.dk>, 2000, 01. # Ole Laursen <olau@hardworking.dk>, 2002, 03, 04, 05, 06. # Marie Lund <marielund@post.cybercity.dk>, 2004. # Martin Willemoes Hansen <mwh@sysrq.dk>, 2004. # Kenneth Nielsen <k.nielsen81@gmail.com>, 2006, 2007. # Ask Hjorth Larsen <asklarsen@gmail.com>, 2007. # M.P. Rommedahl <lhademmor@gmail.com>, 2008 # # Husk at tilføje dig i credit-listen (besked id "translator_credits") # # Konventioner: # # plugin -> udvidelsesmodul # snippet -> tekststump # msgid "" msgstr "" "Project-Id-Version: gedit.gnome-2-16\n" "Report-Msgid-Bugs-To: http://bugzilla.gnome.org/enter_bug.cgi?" "product=gedit&component=general\n" "POT-Creation-Date: 2009-01-01 19:23+0000\n" "PO-Revision-Date: 2008-10-04 11:20+0200\n" "Last-Translator: Kenneth Nielsen <k.nielsen81@gmail.com>\n" "Language-Team: Danish <dansk@dansk-gruppen.dk>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n"
I kommentaren til denne specielstreng findes først noget ophavsretsinformation, her skal man som oversætter huske at opdatere årstallet således at det stadig inkluderer det år man er i. Derefter følger en liste af navne og e-mail-adresser for alle de oversættere, som har arbejdet på filen, her skal man selvfølgelig også skrive sig selv på. Dette er også et godt sted at kigge, hvis man af forskellige årsager vil kontakte sidste oversætter. Her er også en kommentar om at man skal huske at skrive sig selv på "credit"-listen, mere om det senere. Derefter følger en liste af konventioner, som de forskellig oversættere har lavet for denne oversættelse, husk at bruge og opdatere denne. Efter kommentaren kommer selve strengen, som indeholder forskellige former for specielinformation. Der er kun 3 af linjerne som man behøver at bekymre sig om som oversætter. Man skal opdatere linjen Last-Translator
med sit eget navn og e-mail, samt sikre sig at linjen Language-Team
indeholder informationen Danish <dansk@dansk-gruppen.dk>
, hvis den ikke gøre det i forvejen. Derudover er der linjen Plural-Forms
som beskriver hvilke flertalsformer man har på det på sprog som filen oversættes til, mere om det senere.
Flertalsformer
Når man skriver tekststrenge i et program, har man muligheden for at skrive en variabel ind i strengen, som vil blive erstattet af noget andet, f.eks. et tal eller noget andet tekst. Hvis det der bliver sat ind, er et tal, vil det være nødvendigt for strengen at ændre sig alt efter hvad dette tal er. Det forklares måske nemmest med at eksempel, igen fra gedit
#: ../gedit/gedit-commands-file.c:266 #, c-format msgid "Loading %d file..." msgid_plural "Loading %d files..." msgstr[0] "Indlæser %d fil..." msgstr[1] "Indlæser %d filer..."
I denne type af strenge er der nu 2 msgid
'er, en for hver af de forskellige former der er på engelsk. Herefter skal der så være en msgstr
, for hver af de forskellige flertalsformer der findes på dansk. Efter msgstr[0]
skal stå den danske streng, som svarer til at der er nøjagtig 1 og efter msgstr[1]
skal stå den streng, som svarer til at der er 0 eller flere (mere end 1). Grunden til at man har lavet det på denne måde, i stedet for bare at lave det som 2 strenge, er at andre sprog har væsentligt mere indviklede regler for flertalsformer og i flere tilfælde mere end 2 former.
Eftersom det kan variere fra sprog til sprog, hvordan man laver flertalsformer, er man nødt til at definere dette i filen, hvis der findes sådan nogle plural
-strenge som denne her. Dette gøres med den linje i filhovedet, som starter med Plural-Forms:
og den skal for danske oversættelser have værdien nplurals=2; plural=(n != 1);
. Hvis man støder på en uoversat flertalsstreng, skal man derfor sikre sig at denne linje er i filhovedet, eller får man en fejl senere når man kontrollerer filen for fejl.
Specielle entiteter i strenge
Nogle strenge indeholder blot almindelig tekst, men der er også indtil flere specielle entiteter, som man kan støde på og som det som ny oversætter, kan være svært at vide hvad man skal gøre ved. Disse er beskrevet i de følgende undersektioner.
Variable
Som tidligere nævnt kan man bruge variable i programstrenge og bruge disse, til at få sat et eller andet ind i strengen. Det kan være alt lige fra tal, fil-navne eller -stier, eller blot noget andet tekst. Der vil stå en variabel, det sted i strengen hvor dette skal sættes ind. Hvordan disse variable ser ud, vil afhænge af hvilket programmeringssprog programmet er skrevet i. Det kan f.eks. være sådan nogle som %s
, %d
og %i
. Der er for mange muligheder, inden for de forskellige sprog, til at skrive dem alle sammen her, så hvis man som oversætter er i tvivl om noget er en variabel, må man endelig spørge. Det vigtige ved disse strenge er at man bevarer dem. Når man er færdig med strengen, skal der altid stå de samme variable, som der gør i originalstrengen. Nogle (sjældne) gange vil det være nødvendigt, at bytte rundt på rækkefølgen af disse variable og her skal man være forsigtig. Måden at gøre dette på vil varierer fra sprog til sprog og hvis man støder på problemet, er det derfor nemmere at spørge og så finder vi en løsning i det pågældende tilfælde.
Tastaturgenveje
Strenge som skal have et bogstav associeret med sig, således at disse bogstaver kan komme til at fungere som genvejs-"tegn", håndteres i oversættelser ved at sætte et tegn foran det bogstav, som skal være genvejstegn. Denne form for tastaturgenveje i programmer er kendetegnet ved, at der er en streg under bogstavet, som fremhævet med gult i dette billede. Hvilket tegn der bliver brugt, til at markere dette kan variere fra projekt til projekt, men i næsten alle GNOME-relaterede projekter bruger bundstregen "_". Et eksempel på sådan en streng kunne være "Save" i filmenuen, vist hernedenunder.
msgid "_Save" msgstr "_Gem"
På engelsk er der valgt "s" som genvejstegn og i den danske version har man valgt "g". Det er vigtigt at sørge for, at man får defineret sådan et genvejstegn, når der er et i originalstrengen. Det er også vigtigt at man tænker lidt over hvilke tegn man bruger, sådan at genvejtegnene bliver så konsistente som muligt, på tværs af programmerne og at man ikke bruger det samme tegn til flere strenge i f.eks. den samme menu.
Opmærkning
I visse sammenhænge bliver de tekststrenge, som skal oversættes, formatteret ved hjælp af opmærkning, i stil med måden man skriver hjemmesider på. Så hvis man f.eks. vil have noget tekst til at stå med fed skrifttype, så skriver man <bold>fed tekst</bold>
. Det sidste mærke, som har en skråstreg i sig, er det afsluttende eller lukkende mærke. Man kan indlejre sådanne mærker, således, at hvis man i en streng som er fed, vil have noget til både at være med fed og på skrå, kan man skrive <bold>både fed <italic>og på skrå</italic></bold>
. Som oversætter er det vigtigt at huske på at lukke indlejrede mærker på samme måde som i originalen.
Lodret stregtegn "|" (en. pipe character)
Hvis den samme tekststreng optræder mere end en gang i et program, vil Gettext samle det til en sektion i po-filen, som vil have flere kildekodereferencer. Selv om dette er rigtigt smart og hjælper ufattelig meget i langt størstedelen af tilfældende, er der visse tilfælde hvor det ikke dur. Det kan være, hvis det samme ord kan betyder mere end en ting og bruges forskellig flere steder i programmet. Det kunne (som et tænkt eksempel) være et program, hvor man måler ydelse af et eller andet og samtidig kan gemme og indlæse profiler, for hvordan det bliver vist. I sådan et program kunne man forestille sig, at strengen "Load" bliver brugt både i betydningen "Belastning" og i betydningen "Indlæs". Hvis strengene bliver samlet til en, er det selvfølgelig ikke muligt at oversætte det til to forskellige ting. I et lang stykke tid er det blevet ordnet, ved at man har hæftet et stykke kontekst på før strengen, adskilt fra selve strengen med en "|" og man har så, i en kommentar, bedt oversætterne om kun at oversætte det efter "|". Dette ville så betyde, at der nu i stedet vil være to strenge, f.eks. "Noun|Load" og "Verb|Load" som skal oversættes forskelligt. Det er meget vigtigt at være opmærksom på at gøre dette rigtigt og kun oversætte det efter "|". Denne metode er imidlertid meget sårbar for fejl og man er lige nu (December 2008) i gang med at implementere en erstatning for dette system. Løst forklaret vil dette nye system betyde, at der vil komme et ekstra felt ligesom msgstr
og msgid
som hedder msgctxt
hvori strengens kontekst vil komme til at stå, i stedet for i selve strengen. Dette vil blive forklaret nærmere når implementeringen er nået længere.
"translator-credits"-strengen
I nogle programmer findes en speciel streng med msgid
"translator-credits". Denne bruges sådan, at det den bliver oversat til, indsættes i en boks (f.eks. i "Om ..."-vinduet) med folk som har bidraget til oversættelse. Det betyder, at i stedet for at oversætte den ordret skal man i stedet for indsætte en liste over folk, som har bidraget til oversættelsen, samt hold- og kontakt-information. Indenfor GNOME-oversættelser bruges altid en standard måde at udforme denne på, som ser ud som nedenfor:
#: ../gedit/gedit-commands-help.c:106 msgid "translator-credits" msgstr "" "Birger Langkjer\n" "Keld Simonsen\n" "Kenneth Christiansen\n" "Marie Lund\n" "Martin Willemoes Hansen\n" "Ole Laursen\n" "Kenneth Nielsen\n" "M.P. Rommedahl\n" "\n" "Dansk-gruppen <dansk@dansk-gruppen.dk>\n" "Mere info: http://www.dansk-gruppen.dk"
Som det kan ses, er det altså først en liste af navne på bidragsyderne, herefter en blank linje og til sidst to linjer med navn og kontaktinformation for holdet.
Hjælpeprogrammer (pyg3t)
Ud over det program man bruger til at redigere po-filen med, er der en samling mindre kommandolinjeprogrammer, kaldet PyG3T, som bruges i løbet af et oversættelsesforløb. PyG3T indeholder blandt andet poabc og podiff, som beskrives nedenfor.
poabc
poabc (ABC står for Automatic Blunder Corrector) er et program, som man kan bruge til at lede efter typiske fejl i en oversættelse, efter at man er færdig med den. Blandt de fejl som poabc kigger efter er, om man har glemt strengens afsluttende punktum eller mellemrum, at man ikke har korrekt stort eller lille bogstav i starten og om man har husket genvejsbogstavstegnet hvis der er sådan et i originalen. poabc køres fra terminalen, med filen der skal tjekkes som argument,
poabc gedit.po
og vil give uddata som det nedenunder.
=== Line 1127 : Hotkey assignment inconsistency === msgid "Simulation of (S)VCD burning" msgstr "_Simulering af (s)vcd-brænding" === Line 1664 : Leading character type or case mismatch === msgid "Session Import Error" msgstr "sessionsimport-fejl" === Line 1694 : Trailing characters or punctuation mismatch === msgid "Please, delete some files from the project." msgstr "Slet nogle filer fra projektet"
Uddata ovenfor viser de mest typiske former for fejl, som poabc vil rapportere i sin uddata. Desværre vil de kriterier som poabc er sat til at registrere som fejl, også nogle gange give falske positive, altså advarsler hvor der ikke er noget i vejen. Det er dog hurtigt at gennemgå uddata fra poabc og sortere de falske advarsler fra og bruge de rigtige, og brugen af poabc vil ofte fange en del fejl, selv for rutinerede oversættere. Et eksempel på en falsk fejlbesked kan ses nedenfor.
=== Line 708 : Leading character type or case mismatch === msgid "%s only" msgstr "kun %s"
Her har poabc taget fejl, fordi den forventer at strengen starter med et tegn, men i den danske streng er variablen rykket over til sidst og derfor starter den danske streng med et bogstav.
podiff
podiff bruges til at dokumentere de ændringer, man har lavet i en po-fil under en opdatering, på en sådan måde at det er nemt at læse korrektur på ændringer. Dansk-gruppen læser korrektur på alle oversættelser før de integreres, men for at man ikke skal læse hele oversættelsen igennem, hver gang der bliver foretaget en opdatering, gennemlæses kun de dele af filen som er blevet opdateret.
Måden podiff bruges på er som følger. Når man skal til at opdatere en oversættelse, vil man først hente den fil ned man skal arbejde med. Før man går i gang med oversætterarbejdet, laver man en kopi af denne fil, som skal dokumentere hvordan filen så ud før (hvilket er nødvendig fordi podiff skal sammenligner før med bagefter). Denne ubearbejdede kopi kaldes her for "gammel.po". Efter at oversættelsen er færdig og kontrolleret på alle tænkelige måder, har man en anden fil, som her kaldes for "ny.po". Med disse to filer kører man podiff på følgende måde
podiff gammel.po ny.po
Dette vil så udskrive uddata til terminalen. Eftersom man senere skal vedhæfte dette til e-mail, er det praktisk at få gemt dette uddata til en fil. Det gør man ved at videresende uddata til en fil, på følgende måde
podiff gammel.po ny.po > gammel_ny_diff.podiff
Uddata fra podiff vil typisk se ud som vist længere nede, bemærk at et "-" foran en streng betyder at det var sådan, den så ud i "gammel.po" og et "+" foran en streng betyder, at det er sådan den ser ud i "ny.po"
#: ../xfburn/xfburn-device-box.c:627 ../xfburn/xfburn-device-box.c:670 msgid "Cannot access drive (it might be in use)" -msgstr "" +msgstr "Kan ikke tilgå drev (det er muligvis i brug)" #: ../xfburn/xfburn-blank-dialog.c:360 -#, fuzzy msgid "No disc detected in the drive." -msgstr "Ingen disk er fundet i drevet" +msgstr "Ingen disk er fundet i drevet."
Her ses to typiske eksempler på opdateringsstrenge. Den første er en uoversat streng, som er blevet oversat. Det kan ses idet der var en tom msgstr
i "gammel.po" og en dansk tekststreng i "ny.po". Den anden er en streng, som er blevet fuzzy. Det er den, i dette her tilfælde, højst sandsynligt blevet, fordi udviklerne har tilføjet et punktum til sidst i strengen. Man kan se, at det oversætteren har gjort, er at opdatere oversættelsen, sådan så den passer til denne ændring, således at oversættelsen nu også har et punktum til sidst, samt at fjerne fuzzy
-mærket fra mærkekommentaren. fuzzy
-mærket var blevet indsat automatisk, fordi Gettext har indset, at dette højst sandsynligt stadig er den gamle streng der er tale, men at den blot er blevet ændret.
Installation af PyG3T
PyG3T udgives under GPL og kan hentes fra Launchpad enten som tarball eller RPM. For Ubuntubrugere installeres det nemmest via dets personlige pakkearkiv (mere detaljerede instruktioner om installation fra personlige pakkearkiver kan om nødvendigt findes på Launchpads PPA-hjælpeside).
For ikke-Ubuntubrugere installeres PyG3T nemmest ved at hente nyeste udgave fra download-siden, pakke filen ud med kommandoen tar xzf pyg3t-version.tar.gz, og dernæst køre:
sudo python setup.py install
Programmerne kan også installeredes uden superbrugeradgang ved at tilføje bin-mappen fra den udpakkede tar.gz-fil til $PATH, samt pyg3t-undermappen til $PYTHONPATH.
Mere information kan findes i e-brevet om udgivelsen af PyG3T og e-brevet om udgivelsen af PyG3T 0.2
Oversættelsesproceduren
Dette afsnit beskriver selve oversættelsesproceduren. Det er lavet som en nummereret punktopstilling, således at hvis man løber ind i problemer, kan man henvise til det punkt man er nået til. I det følgende vil filen gedit.po blive brugt som eksempel på den fil som skal oversættes (bemærk at filer man henter ned som regel har noget længere navne, fordi navnet også indeholder information om hvilken udviklingsgren den er en del af, men det betyder ikke noget for proceduren).
- Find en oversættelse som du har lyst til at tage fat på (f.eks. gedit) og send en e-mail til dansk-gruppens e-mail-liste med emnet "[GNOME] Jeg går i gang med gedit" ([GNOME] i dette tilfælde fordi gedit kommer fra GNOME). Hvis du ikke har været på listen så længe, så vent gerne lige en dags tid for at se om der er nogen som protesterer, enten fordi de allerede er i gang med den, eller fordi de selv tidligere har oversat den og godt kunne tænke sig at fortsætte med det.
- Hent filen ned fra internettet.
- Lav en kopi af filen sådan som den ser ud før du går i gang med at oversætte den (F.eks. med følgende kommando:
cp gedit.po gedit_gammel.po
) - Oversæt filen ved brug af et af de programmer som er beskrevet her, eller et andet hvis du foretrækker, og gør brug af retninglinjer og fif nedenfor.
- Efter endt oversættelse, stavekontrol, poabc-check og syntakscheck (som beskrevet nedenfor) er filen klar til at blive gennemlæst. Nu laves en podiff for at dokumentere de ændringer du har lavet, f.eks. med følgende kommando:
podiff gedit_gammel.po gedit.po > gedit_gammel_ny.podiff
- Uddata fra podiff sendes til gennemlæsning på dansk-gruppens e-mail-liste. Det gøres ved at sende en mail til listen med emnet "gedit til gennemlæsning (antal strenge som er opdateret)", hvor uddata fra podiff både indsættes i brevkroppen og vedhæftes som fil.
- Når du modtager kommentarer fra en gennemlæser, gennemgår du dem og retter din oversættelse til. Hvis der er noget som du er uenig i, skriver du bare tilbage, hvorefter du og gennemlæseren (og evt. andre) kan tage en diskussion om stridspunkterne. Hav lidt tålmodighed med gennemlæsningen, vi er alle samme frivillige og det er ikke sikkert at der er nogen som har tid til at lave gennemlæsningen omgående.
- Når alle kommentarer fra gennemlæseren er behandlet, er oversættelsen færdig og den sendes til integration. Det gøres ved at sende en e-mail til dansk-gruppens med emnet "gedit til integrering", hvorefter en fra dansk-gruppen, som har integreringsrettigheder til det pågældende projekt, vil integrere den og bekræfte dette i en e-mail
- Hop tilbage til 1 og start på en ny ;)
Retningslinjer og fif til oversættelsesarbejdet
Følger snart
KennethNielsen 3. jan 2009 kl. 18:33 (CET)