Författare: Tommy Pettersson (ptp_at_lysator.liu.se)
Datum: 2002-05-16 01:19:47
> > #: ieee.c:3254
> > msgid "C++ default values not in a function"
> > msgstr "C++-standardvärden inte innom en funktion"
>
> "Inom" med ett "n".
Attans. Jag som just hittat ett rättstavningsprogram för
po-filer, men jag glömde köra det.
> > #: ieee.c:5333
> > #, c-format
> > msgid "IEEE unsupported integer type size %u\n"
> > msgstr "IEEE klarar inte heltalstyper av storlek %u\n"
>
> Jag undrar om det verkligen är IEEE som inte klarar storleken. Det
> skulle också kunna vara en IEEE heltalstyp som inte stöds.
>
> > #: ieee.c:5369
> > #, c-format
> > msgid "IEEE unsupported float type size %u\n"
> > msgstr "IEEE klarar inte flyttalstyper av storlek %u\n"
> >
> > #: ieee.c:5405
> > #, c-format
> > msgid "IEEE unsupported complex type size %u\n"
> > msgstr "IEEE klarar inte komplextyper av storlek %u\n"
>
> Motsvarande.
Jag tycker det skulle stå 'Unsupported IEEE integer type
size' då, som i det existerande fallet "unsupported IEEE
expression operator". Alla meddelanden i ieee.c som börjar
med "IEEE ..." (dessa tre samt "IEEE numeric overflow"
och "IEEE string lengt overflow") skrivs ut men fprintf().
Alla andra skrivs ut med funktionen ieee_error(). Jag vet
inte om det har någon betydelse, men det är lite skumt.
I fallet med 'IEEE string lengt overflow' skriver programmet
ieee_extension_length_1_enum och ieee_extension_length_2_enum
före utdatat som talar om hur lång en text är, men det finns
ingen length_3 eller lengt_4, utan om talet är större än 32
bitar, vilket testas med en if(), skrivs felmeddelandet ut.
I fallet med 'IEEE numeric overflow' görs kontrollen
av talet mot uttrycket (ieee_number_repeat_end_enum -
ieee_number_repeat_start_enum) som blir 8. Alla ieee_...
är definierade i /include/ieee.h, så jag tror att det faktiskt
är begränsningar i IEEE.
> > #: nlmconv.c:726 nlmconv.c:915
> > msgid "custom section"
> > msgstr "personlig sektion"
>
> Jag kan inte NLM-formatet, men jag betvivlar att "personlig" är en bra
> översättning av "custom" här.
Det jag fann när jag surfade för att kunna översätta den
här klurigheten var att 'custom' i det här fallet helt klart
innebär 'customizable'. Skulle 'skräddarsydd sektion' kanske
vara bättre?
> > #: nlmconv.c:910 nlmconv.c:939 nlmconv.c:957 nlmconv.c:1006 nlmconv.c:1025
> > #, c-format
> > msgid "%s: read: %s"
> > msgstr "%s: läsfel: %s"
>
> Det står inget om "fel" i orginalet.
Det är ett sådant där dumt felmeddelande med ett
funktionsanrop, fast inte riktigt. Det är funktionen fread()
som anropas, och om den returnerar ett fel så kommer detta
felmeddelande. Både 'läsfel' och 'read' (oöversatt) blir
ju fel. Jag vet inte hur jag ska göra.
> > #: nlmconv.c:1228
> > msgid "set .nlmsections size"
> > msgstr "sätt .nlm-sektionsstorlek"
>
> ".nlmsections" är nog ett namn. Du behandlade det så tidigare.
>
> > #: nlmconv.c:1316 nlmconv.c:1324 nlmconv.c:1333 nlmconv.c:1338
> > msgid "set .nlmsection contents"
> > msgstr "sätt .nlm-sektionsinnehåll"
>
> Motsvarande.
Det stämmer. Jag byter till 'sätt .nlmsections innehåll'
och motsvarande.
> > #: nlmconv.c:1980
> > #, c-format
> > msgid "unresolved PC relative reloc against %s"
> > msgstr "olöst PC-relativ omlokalisering mot %s "
>
> Ett onödigt blanksteg på slutet.
Fixat.
> > " -n, --numeric-sort Sort symbols numerically by address\n"
> > " -n, --numeric-sort Sortera symboler nummeriskt efter adress\n"
>
> "Numeriskt" med ett "m".
Fixat. (Hittade en till dessutom.)
> > #: nm.c:334 objdump.c:216
> > #, c-format
> > msgid "Report bugs to %s.\n"
> > msgstr ""
> > "Rapportera fel till $s.\n"
> > "Rapportera fel i översättningen till sv@li.org.\n"
>
> "$s" var nog fel.
Den sitter på tangenten intill på mitt tangentbord. :-)
> > #: nm.c:546
> > #, c-format
> > msgid "data size %ld"
> > msgstr "datasegmentets storlek: %ld"
>
> Valde du avsiktligt att lägga till ett kolon för att du tyckte det
> blev bättre så, eller var det ett misstag? (Själv skulle jag nog bara
> skrivit "datastorlek %ld", men det är jag det.)
Det var nog bara en väldigt fri översättning. "Datat" är
hur mycket minne programmet använt sig av under exekveringen
(räknas ut med sbrk() och &environ) och utskriften får man
om man anger den odokumenterade flaggan --stats till nm,
så jag antar att det är till för utvecklare som felsöker och
testar prestandan på programmet. Risken är att det blir fel
att blanda in 'segment' här, så jag ändrar till ditt förslag.
De som vet vad det är för ett meddelande vet ändå exakt vad
den betyder.
> > #: objcopy.c:1550
> > msgid "making"
> > msgstr "tillverkning"
>
> Eller kanske "tillverkar".
Nej.
[...]
err = "making"
goto loser
[...]
loser:
print ("error in %s", err)
Så nu blir det "fel på tillverkning", "fel på storlek",
"fel på jämn gräns" osv.
> > #: objcopy.c:2092
> > msgid "byte number must be non-negative"
> > msgstr "byte-nr får inte vara negativ"
>
> "NegativT" väl, ett negativt nummer.
Det ska vara glada data. ;-)
't' ditsatt.
> > #: objcopy.c:2342
> > #, c-format
> > msgid "Warning: truncating gap-fill from 0x%s to 0x%x"
> > msgstr "Varning: kortar av utfyllnadstalet från 0x%s till 0x%x"
>
> Man kan ju fråga sig om det verkligen skall vara %s första gången,
> eller om det skulle varit %x. Har du koden lätt tillgänlig så du kan
> kolla?
Japp. Jag har tankat ner hela binutils från CVS och prisar
cscope flera gånger om dagen när jag sitter och översätter.
Det är korrekt med %s, som fås från en strängbuffert till
vilken en adress skrivits med en konverteringsfunktion som
spottar ur sig hexadecimala siffertecken, därav 0x före %s
i formatsträngen.
> > #: objcopy.c:2494
> > msgid "alternate machine code index must be positive"
> > msgstr "index för annan maskinkod måste vara positiv"
>
> Ett index, alltså positivT.
Jag skulle inte tagit så mycket uppåttjack när jag översatte. ;-)
> > " -z, --disassemble-zeroes Do not skip blocks of zeroes when "
> > "disassembling\n"
> > " -z, --disassemble-zeroes Hoppa inte över nollor vid "
> > "disassemblering\n"
>
> Att det handlar om BLOCK med nollor kanske är värdefullt för att
> förstå bättre.
Det får inte plats på raden då... Ja, ja, då blir det
"Hoppa inte över block av nollor vid\n dissasembleringen"
istället. :-)
> > #: readelf.c:351
> > #, c-format
> > msgid "Unable to seek to %x for %s\n"
> > msgstr "Kan inte uppsöka %x i %s\n"
>
> Jag tycker formuleringen "seek ... for" är lite udda. Har du kollat
> att %s verkligen blir det man söker i?
Jajamänsan! Variabeln heter 'reason', så man kan med
anledning av 'for %(reason)' tycka att det borde bli 'på
grund av %s', men senare i samma funktion (get_data()) kommer
'Out of memory allocating %d bytes for %(reason)' och 'Unable
to read in %d bytes of %(reason)'. När man tittar på alla
anrop till get_data() ser man att parametern reason alltid
är namnet på den logiska enhet get_data() ska grabba åt sig,
och med formuleringen 'of %(reason)' har de själva låst sig
till den förutsättningen.
> > #: readelf.c:1085
> > #, c-format
> > msgid "<string table index %3ld>"
> > msgstr "<txt.str.tab.index %3ld>"
>
> Samma kommentar som tidigare om "textsträng". (Om du skippar "text"
> kanske du inte behöver förkorta så mycket, dessutom.)
Jag tycker inte om översättningen 'string'->'sträng'.
Tyvärr kan jag inte motivera varför. Men eftersom det blir så
mycket snyggare med '<strängtabellindex %3ld>' så får det gå,
i just det här fallet. :-)
> Tja, nu får det räcka för den här gången. Men jag återkommer.
Du ska ha stort tack för alla kommentarer.
--
Tommy Pettersson <ptp@lysator.liu.se>
Arkiv genererat av hypermail 2.1.4.