Re: gnupg, lite fler kommenterer

From: =?ISO-8859-1?Q?G=F6ran Uddeborg?= (goeran_at_uddeborg.pp.se)
Date: 2000-02-09 22:03:13

> > > #: g10/pkclist.c:588
> > > msgid "         The signature is probably a FORGERY.\n"
> > > msgstr "         Signaturen är sannolikt en FÖRFALSKNING.\n"
> > 
> > "SANNOLIKT" en förfalskning.  De tar då i!  De har väl egentligen
> > inget att motivera den sannolikheten med, förmodar jag, bara brist på
> > indikationer på motsatsen.
> > 
> > Men översättningen som sådan har jag inget att anmärka på.
> 
> Överdriven försiktighet är ett stildrag som kommer igen i många
> meddelanden.

Visst, det har jag insett.  Och jag kan väl också tycka att det passar
för ett program av den här typen.

Men vad jag noterade var att de här påstår det omvända, att signaturen
faktiskt är en förfalskning.  Jag vet inte riktigt i vilken situation
de skriver ut detta.  Men jag har svårt att se hur de skulle kunna ha
täckning för ett sådant påstående.

Men det var mer en observation än något annat.

> > > #: g10/pkclist.c:856
> > > #, c-format
> > > msgid "%s: error checking key: %s\n"
> > > msgstr "%s: fel när nyckeln %s undersöktes\n"
> > 
> > Jag tycker det är lite synd att du behöver flytta in det andra %s:et
> > här.  Man ser lättare vad som är det undersökta objektet när det står
> > efter kolon och i slutet på raden.
> 
> Funderade lite på att byta ut undersöka till kontrollera också, 
> mitt nya förslag:
> 
> msgstr "%s: fel vid kontroll av nyckeln: %s\n"

Det tycker jag låter bra.

> poängen är den att det finns två identiska meddelanden sånär som på
> singularis-/pluralis-skillnaden och ändå skrivs antalet (som i singularis
> bara kan vara == 1) ut som ett %lu istället för literalen 1 vilket jag
> tycker är onödigt.

Ok, nu förstår jag.

> > > #: g10/export.c:165
> > > #, c-format
> > > msgid "key %08lX: not a rfc2440 key - skipped\n"
> > > msgstr "nyckeln %08lX följer inte standarden beskriven i RFC2440 - hoppar över\n"
> > 
> > Du tror inte det räcker med "...följer inte RFC2440 - överhoppad"?
> 
> jag gillar min översättning bättre, eftersom den ger en fingervisning om
> vad det handlar om även om man inte har en aning om vad RFC betyder. 

Jag förstår, och du har kanske rätt i det.

Möjligen skulle du kunna hoppa över "beskriven i"; jag ser det som att
RFC2440 ÄR standarden.  (Antar jag av sammanhanget.  Jag har inte läst
just denna RFC.  En del RFC:er är ju bara resonerande dokument.)

> I båda fallen handlar det om ett antal rader som är en summering
> från aktiviteten vid en nyckelimport och alla dessa rader 
> har jag indenterat så att : kommer under varandra.

Ok.

> > > #. we can't merge secret keys
> > > #: g10/import.c:602
> > > #, c-format
> > > msgid "key %08lX: already in secret keyring\n"
> > > msgstr "nyckel %08lX: finns redan i den hemliga nyckelringen\n"
> > 
> > Hmm, blir det rätt syftning där?  Jag tänker mig att själva nycklarna
> > är hemliga, inte själva nyckelringen.  Men egentligen spelar det
> > kanske ingen roll.  Det är bara som jag tänker mig det.
> 
> det är så finurligt att det finns nyckelringar, en för hemliga och en
> för publika nycklar. Så syftningen både i originalet och översättningen
> är rätt.

Jag vet att det finns två nyckelringar, jag kör traditionell PGP och
de har ju samma system.

Vad jag menade var att jag ser filen .pgp/secring.skr som min
nyckelring för hemliga nycklar.  Däremot är inte existensen av själva
filen/nyckelringen hemlig.

Men frågan är inte viktig.  Vi talar ju om metaforer, och precis vad
det är som är nyckelringen, filen eller dess innehåll, kan man se som
man vill.

> > > #: g10/keyedit.c:565
> > > msgid "q"
> > > msgstr "q"
> > 
> > Det skall inte vara "a" som i "avsluta" här?  Jag bara gissar med
> > ledning av det föregående meddelandet.
> 
> jag är fortfarande av åsikten att en översättning inte skall ta bort
> någon funktionalitet (vilket skulle ske om jag översatte q till a)
> detta trots att jag nu sett att till mutt-översättningen gör just
> det. Har det fattats något policy-beslut i frågan?

Sade du inte i något annat sammanhang att gnupg behöll funktionalitet
oavsett hur man översatte?  Så att den jämförde med både det
oöversatta och det översatta värdet?  Eller missförstod jag något?

Något policy-beslut har vi nog inte tagit.

> 58% av filen kollad, man tackar :)

Fortsättning följer.  Inte just ikväll, dock.  Vi fär se när jag
hinner.

Arkiv genererat av hypermail 2.1.1.