On 2 Apr, Göran Uddeborg wrote:
>> 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".
Va? Var det inte precis tvärtom? "Skriv ej rader som inte är gemensamma
för båda filerna"
>
> "Skriv ej unika rader" förstår jag inte. Det är väl inte samma sak?
Jo, det är det väl. Bara väl kort.
>
>> > > 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.)
Och jag har i min tur gett mig i ett tidigare brev.
>
>> > > " -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.
Bra.
>
>> 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.
>
--
---------------------------------------------------------
Peter Antman | Svenska Linux:
Journalist, Writer and Linux-user. | www.abc.se/
peter.antman@abc.se | ~m9339/linux/
www.abc.se/~m9339/ Fax: ++46-8-845085 |
---------------------------------------------------------
Arkiv genererat av hypermail 2.1.1.