Re: textutils-kommentarer

From: Göran Uddeborg (göran_at_uddeborg.pp.se)
Date: 1997-04-02 20:28:36

>      Sender:   Peter Antman <peter.antman@abc.se>
> 
> > > "  -3              suppress lines unique to both files\n"
> > > "  -3              skriv ej rader som är unika för båda filerna\n"
> > 
> > "unika för båda filerna"
> > 
> > Konstig formulering. 
> 
> Håller med, men vad ska man skriva? Förmodligen bara "skriv ej unika rader"

Kanske "skriv ej rader (som är) gemensamma för båda filerna".

"Skriv ej unika rader" förstår jag inte.  Det är väl inte samma sak?

> > > msgid ""
> > > "suppressing non-delimited lines makes sense\n"
> > > "\tonly when operating on fields"
> > > msgstr ""
> > > "att undertrycka ej avskiljda rader är endast rimligt\n"
> > > "när man arbetar på fält"
> > 
> > Förmodligen har man tabulatorn i orginalet för att markera att det är
> > en fortsättningsrad så du bör nog behålla det.
> 
> Jo, fast det är det enda meddelandet som är formaterat på det sättet. En bugg i
> orginalet?

Jag har för mig att jag såg något mer, men jag kanske minns fel.  Det
var inte många, det håller jag med om.  Å andra sidan var det kanske
inte så många meddelanden som sträckte sig över flera rader.

Men som sagt, inget hindrar att du tar kontakt med författaren när du
upptäcker konstigheter eller inkonsekvenser.  Orginalmeddelandena kan
i allmänhet förbättras.

> > > "  -i, --initial       do not convert TABs after non whitespace\n"
> > > "  -i, --initial       konvertera inte TABs om det ej föregås av
> > > mellanrum\n" 
> > 
> > Det där blir lite missvisande.  Flaggan gör att enbart inledande
> > sekvenser av mellanslag och tabulatorer konverteras, men att
> > eventuella tecken efter första icke-blanktecknet får vara kvar.  Med
> > blanktecken menas här mellanslag och tabulator.
> 
> Så här?
> "  -i, --initial       konvertera inte TABBAR efter icke-blanktecken"

Det är nog bättre.  Det kan fortfarande missförstås som "omedelbart
efter", men jag kommer inte på något bättre som inte blir väldigt
långt.  Orginalet har samma svaghet.

> > > "  -j FIELD          (obsolescent) equivalent to `-1 FIELD -2 FIELD'\n"
> > > "  -j FÄLT          (Obsolet) likvärdigt med \"-1 FÄLT -2 FÄLT\"\n"
> > 
> > "Obsolet" är väl svengelska. 
> Nja. Ur SAOL:
> obsolet (-e´t) n. = adj. föråldrad, ur bruk.

Det står det visst!  Jag får ge mig.  (Även om jag fortfarande tycker
det låter fult.)

> > > "  -d   same as -t u2, select unsigned decimal shorts\n"
> > > "  -d   samma som -t u2, välj osignerade korta decimaler\n"
> > 
> > "osignerade korta decimaler" skulle jag inte förstått.  "\"short\"
> > decimalt utan tecken" kanske; "short" är ju en term från språket C
> > här.
> 
> Hm, du menar att man inte får översätta då? Då borde detsamma gälla nästa
> också. Så väl som -i, -l, -o.
> Kör så här: "osignerade decimala korta"

Nej, jag menar inte att man inte får översätta.  Jag vill bara ha en
översättning som jag tror skulle förstås.  Och då försöker jag bedöma
om jag själv skulle förstått.

Ännu ett förslag:  "teckenlösa korta decimalt".  Då kanske man skall
skriva "skriv" istället för "välj".

> Efter en koll i källkoden verkar det åtminstone för mig som om det i själva
> verket handlar om ett felmeddelande när bufferten ska tömmas. Att detta alltså
> inte lyckas.

Jag instämmer i din tolkning av koden.


> 	  error (0, errno, _("flushing file"));
> 
> Någon som har något att säga om detta? Borde det inte stå "error flushing file"
> eller mer korrekt och på svenska "fel vid tömning av buffert"

Om det skall stå "error" eller inte beror lite på vad "error" gör.
Jag kan tänka mig att den skriver ut programnamnet (vem som meddelar)
följt av ett kolon, tredje argumentet ("flusing file", vad som den
försökte göra) och ytterligare ett kolon, och sedan berättar vad som
gick fel baserat på "errno".  I så fall vore "bufferttömning" en
vettig översättning.  Men kolla error-funktionen för säkerhets skull.

> I editeringsläge är dessa rader inte för långa: om det vra det som var
> problemet.

Ja, det var det jag menade.  Jag måste räknat fel.

> > > #: src/tr.c:358
> > > #, c-format
> > > msgid "Usage: %s [OPTION]... SET1 [SET2]\n"
> > > msgstr "Användning: %s [FLAGGA]... SET1 [SET2]\n"
> > 
> > SET -> MÄNGD kanske?
> 
> Nja, egentligen borde det väl vara tecken eller något liknande. I den gamla
> manualen står string1 och string2

"Mängd av tecken" är antagligen närmast vad som avses i orginalet
skulle jag tro.  Strikt talat är "mängd" fel eftersom det rör sig om
ordnade sekvenser.

Arkiv genererat av hypermail 2.1.1.