Re: binutils-2.14rel030712

Författare: Tommy Pettersson (ptp_at_lysator.liu.se)
Datum: 2004-10-08 17:45:53

|   #: objcopy.c:1088
|   #, c-format
| N msgid "%s: garbage at end of line %d"
| N msgstr "%s:%d skräp i slutet på raden"
| N 
|   #: objcopy.c:1091
|   #, c-format
| N msgid "%s: missing new symbol name at line %d"
| N msgstr "%s:%d nytt symbolnamn saknas"
| N 
|   #: objcopy.c:1101
|   #, c-format
| N msgid "%s: premature end of file at line %d"
| N msgstr "%s:%d ofullständigt slut på filen"

Göran Uddeborg:
> Du ändrar stil här.  Vad är anledningen?  Det skulle väl fungerat med
> t.ex. "... i slutet på rad %d" på svenska.

Jag:
> Det är lättare att tolka fil:rad med reguljära uttryck.
> Många program kan även känna igen sådan utdata automatiskt
> och öppna filer på rätt rad med en gång.  Jag kanske
> skulle felrapportera till gnu att de borde ändra i originalet.

Göran Uddeborg:
> Jag tycker som jag tyckte ovan, rapportera först och be att få
> orginalet ändrat.  När det är gjort kan du följa efter med
> översättningen.

Tomas Gradin:
> Ja, och inte "förbättra" texten på det sättet utan deras godkännande. Det är
> inte självklart att de tycker att maskinell läsbarhet går före mänsklig
> läsbarhet.

Ni har förstås rätt.  Jag ändrar till följande:

  msgid "%s: premature end of file at line %d"
  msgstr "%s: ofullständigt filslut på rad %d"

  msgid "%s: missing new symbol name at line %d"
  msgstr "%s: nytt symbolnamn saknas på rad %d"

  msgid "%s: garbage at end of line %d"
  msgstr "%s: skräp i slutet på rad %d"

Jag ska även lämna ett förslag till gnu om en ändring
av meddelandena.



|   #: dllwrap.c:508
|   msgid "   --dry-run              Show what needs to be run\n"
| G msgstr "   --dry-run              Gör inget annat än att visa vad som måste köras\n"
| N msgstr ""
| N "   --dry-run              Gör inget annat än att visa vad som måste köras\n"

Göran Uddeborg:
> Varför tillägget "Gör inget annat än att"?

Jag:
> Namnet på flaggan --dry-run förmedlar information om att
> inget "riktigt" kommer att utföras, och jag ville få med
> den informationen i översättningen.

Göran Uddeborg:
> Men det är ju samma sak på engelska, och där har de valt att inte ha
> med det förtydligandet.
> 
> Om du tycker att meddelandet behöver förändras så bör du skicka
> synpunkten till författaren.  När (om) han ändrar orginalet så kan du
> ändra din översättning.

Tomas Gradin:
> Du borde skriva "visa vad som kommer att köras" eller något liknande i
> stället.

Jag tycker inte det är samma sak på engelska.  --dry-run
skulle på svenska bli --torrkör, --tomkör eller
--kör-i-tomme.  Dry-run är "med" i den engelska versionen,
så de behöver inte upprepa att det är en tomkörning i
förklaringen, men eftersom jag inte kan ändra flaggan till
--kör-i-tomme och resultatet blir mer än att programmet
visar vad som behöver köras -- det låter dessutom bli att
köra det --, så blir jag tvungen att utöka förklaringen
på något sätt.

Ett 'endast' hade löst problemet, men då uppkommer en
tvetydighet: kommer programmet endast visa vad som behöver
köras, eller kommer det att visa endast vad som behöver
köras.  Både 'behöver' och 'kommer att' antyder visserligen
att det kanske inte är en riktig körning, men jag tycker
att det känns lite otäckt att trycka på enter om jag inte
är säker på att programmet verkligen låter bli.

Vad sägs om följande nya version:

  msgid "   --dry-run              Show what needs to be run\n"
  msgstr "   --dry-run              (Tomkör) Visa vad som kommer att köras\n"



| N "     --prefix-alloc-sections <prefix>\n"
| N "                                   Add <prefix> to start of every allocatable\n"
| N "                                     section name\n"
| N "     --prefix-alloc-sections <prefix>\n"
| N "                                   Börja varje allokerbar-sektions namn med\n"
| N "                                      <prefix>\n"

Göran Uddeborg:
> Här vill jag också ha bort bindestrecket i översättningen, men här
> skall det vara ett blanktecken istället.  "... allokerbar sektions
> ..." alltså.

Jag:
> Jag är inte helt insatt i vad programmet gör.  Är sektionen
> (oavsett sort) allokerbar, eller är det en sektion av sorten
> 'allokerbar' -- alltså med allokerbar data i sig?  Jag får
> försöka ta reda på det.

Göran Uddeborg:
> Det finns flera sorters sektioner, och en del av dem är allokerbara.
> Vanliga namn på sådana är .text, .data, .bss.  Det är de sektioner som
> är allokerbara som får ett nytt namn vid den här operationen.

Då tar jag bort bindestrecket.



Så var det de svåra bitarna kvar då:


|   #: objcopy.c:2856
|   msgid "byte number must be less than interleave"
| G msgstr "bytenummer måste vara mindre än antalet byte i intervallet"
| N msgstr "byte-nr måste vara mindre än antalet byte i intervallet"

Göran Uddeborg:
> Hmm, det står "interleave", inte "interval".  Men det kanske ändå är
> bäst översättning, jag har inget bra förslag.

Jag:
> Programmet filtrerar ut _endast_ en byte ur staplade
> "intervall", fast man kan välja vilken byte (mätt från
> intervallens början) som ska kopieras.  Det arrangerar
> alltså inte om samtliga byte till en un-interleaved ordning.

Göran Uddeborg:
> Ja, jag läste också på och såg att det var så.

Jag:
> Jag vet inte varför och vad det ska vara bra för

Göran Uddeborg:
> Nej, det kan man ju undra! :-) Men när jag läste på såg jag
> kommentaren att "This option is useful for creating files to program
> ROM . It is typically used with an srec output target."  Det är alltså
> tänkt när man skall skriva övre byten till ett ROM, undre till ett
> annat, och sedan (antagligen) läsa båda parallelt.

Jag:
> och vad
> 'interleave' heter på svenska,

Göran Uddeborg:
> Det är ofta svåröversatt.  När det handlar om bildskärmar talar man
> ofta om sammanflätning, men det passar nog inte så bra i det här fallet.

Jag låter det vara 'intervall' tills något bättre
uppenbarar sig.



Jag:
> Jag ändrade alla översättningar av 'align(ment)' från
> 'jämn gräns' till 'linjer(a/ing)', men jag vet inte om det
> blev bättre.  Motiverade åsikter och förslag är välkomna.

Jan D:
> Varför inte anpassning eller gräns/storleksanpassning?
> "Sätt sektionens gränsanpassning".

Tomas Gradin:
> Hmm, jag håller med om att "jämn gräns" inte blev så bra. Det är inte 
> begripligt helt enkelt.
> 
> Men linjering? Jag tänker på linjerat papper :-)
> 
> Kanske "justering" i stället?

Justering har hoppat upp i mina tankar till och från,
men det kan bli förväxlat med 'adjust'; i många långa
flaggor används 'adjust' när ett värde ska ökas eller
minskas med ett angivet antal positioner.  Men vänster-
och högerjusterad text används som termer inom typografin,
och där är betydelsen rätt lik 'align'.  'Just' fungerar
även som förkortning om man är familjär med de typografiska
termerna.

Enbart 'anpassning' blir inte så bra med tanke på
förväxlingen med andra anpassningar, men 'gränsanpassning'
beskriver å andra sidan väldigt bra vad som menas.
Problemet är hur det ska förkortas, för det är i förkortad
form i tabellhuvuden som det nästan uteslutande används.
'Gran' eller 'GrAn' blir inte så bra, men 'Grns' skulle
kanske fungera.

Kan man gissa att "a - ligne" är bildat enligt "på - linje"?
Det är verkligen inte samma sak som linjerad.  (Jo, jag
tänker också på linjerat papper.)  Jag kan ju hitta på det
nya ordet 'alinjera' (i verbform).  (Det finns tydligen redan,
men som namnet på en aboriginstam, och betyder då "norra".)
Då skulle förkortningen i tabellerna bli 'Alnj', vilket är
totalt obegripligt eftersom man inte kan gissa på ett ord som
"inte finns".  Eller skulle man ändå begripa?  Det är ju
rätt likt 'Algn' och påminner en del om "alajnmänt".

Christian använder 'justera' i översättningen av ld, och
samstämmighet är ju då ett bra argument för att välja
justera framför likvärdiga översättningar.

Jag känner mig väldigt obeslutsam, men går nog tillbaks till
'Just(ering)' i tabellhuvudena, som jag hade från början,
men byter även tidigare 'jämn gräns' (nyligen 'linjering')
till 'justering' i meddelandena.



Då så!  http://81.216.50.98/binutils-2.14rel030712.sv.po
är uppdaterad.  Vill någon se en ny podiff så hojta.
Jag väntar till måndag kväll med att skicka in filen ifall
någon vill opponera sig ytterligare mot något.


-- 
Tommy Pettersson <ptp@lysator.liu.se>

_______________________________________________
sv mailing list
sv@li.org
http://lists.alt.org/mailman/listinfo/sv

Arkiv genererat av hypermail pre-2.1.8.