Re: [DOC-SV] Termlista

GT> En liten lista här då... Mest självklara grejer på den då men ändå den
GT> kanske kan komma till avändning för någon. Vi kanske borde bygga på den 
GT> så den blir lite mer användbar och komma överens om vissa översättningar 
GT> och sen jobba efter den? (En tanke bara)

GT> Sen hur är det med exemplen, de skall också översättas va?

GT> Array                   Vektor
GT> Argument                Argument
GT> Boolean                 Boolesk
GT> Callback                ???
GT> Class                   Klass
GT> Constant                Konstant
GT> Constructor             Konstruktor
GT> Control structure       Kontrollstrukturer
GT> Defined                 Definierad
GT> Escape                  ???
GT> Expression              Uttryck
GT> Float                   Flyttal
GT> Function                Funktion
GT> Integer                 Heltal
GT> Method                  Metod
GT> Null                    Null
GT> Object                  Objekt
GT> Operator                Operator
GT> Operator Preedence      Operatorprioritet
GT> Predefine               Fördefiniera
GT> Predefined              Fördefinierad
GT> Reference               Referens
GT> Resource                Resurs
GT> String                  Sträng el. Textsträng
GT> Scope                   Räckvidd
GT> Syntax                  Syntax
GT> Type                    Typ
GT> Undefine                ???
GT> Undefined               Odefinierad
GT> User-define             Användardefinierad
GT> Variable                Variabel

GT> ---

GT> Regards
GT> Gustav Tiger

Gustav,

Ja, det mesta i listan är rätt standard, men det finns vissa grejer
som jag vill kasta lite ljus på. Vissa av de nedanstående punkterna
behandlar artifakter som antagligen endast var stavfel / slarvfel i
din lista, men bara för att vara glasklar...

(1) Boolean <<-->> Boolesk

Det stämmer iofs att en boolean är en boolesk variabel, men det borde
snarare vara Boolean <<-->> Boolesk variabel. "Boolean" är mer ett
substantiv, man pratar om en boolean på samma sätt som om en Integer.
Det "är" en boolean. "Boolesk" är en egenskap.

(2) String <<-->> Sträng eller Textsträng

"Text" är lite underförstått när det handlar om strängar och det är
enklare att nämna typen av sträng endast när det inte är en
textsträng än att hela tiden förklara vilken sorts sträng det handlar
om.

(3) Scope <<-->> Räckvidd

Räckvidd eller synlighet, vilket som egentligen. Räckvidd är väl
antagligen vad programmeringsböcker skulle skriva, och synlighet är
vad facklitteratur i mjukvaruutveckling (vilken inte nödvändigtvis är
programmeringsinriktad) skulle skriva.

(4) Undefine <<-->> ???

Det finns egentligen inget bra svenskt ord för detta, men om man bara
ska gå på vad "händelsen" undefine betyder så skulle "avdefiniera"
vara det bästa, även om också det låter relativt illa.

(5) User-define <<-->> Användardefinierad

Antar att du menar "User-defined" här.

(6) Control structure <<-->> kontrollstrukturer

Antar att du menar "Control Structures" här.

(7) Escape <<-->> ???

"Escape" är ett ovanligt svårt ord att översätta till någonting
generellt. Översättningen beror nämligen väldigt mycket på i vilken
situation det skall översättas. Det enda tillfälle jag kan komma på
just nu när du skulle behöva översätta "Escape" är när det handlar om
ex "escaping all special characters in a string". I det fallet kanske
översättningen borde bli "kringgå" eller "runtgå", men även de låter
fel. Det finns helt klart bättre översättningar.

(8) Callback <<-->> ???

Inga förslag för tillfället gällande "Callback". Skall återkomma om
jag kommer på någonting fyndigt =D

Angående översättningar av programmeringsexempel så anser jag, precis
som jag tror Jome fortfarande gör, att de inte bör översättas. En
diskussionsfråga egentligen, men tänk på följande:

{ENG}

$ARRAY["$FIRST"]

Rent intuitivt skulle man kanske vilja översätta det ovan med

{SV}

$VEKTOR["$FÖRSTA"]

Svenska tecken som å, ä och ö hör egentligen inte hemma i
programmeringsexemplen, och att översätta det ovan med

{SV}

$VEKTOR["$FIRST"]

skulle göra hela den svenska dokumentationen, såsom den är, att bli
väldigt inkonsistent. Av detta skäl anser jag att
programmeringsexempel inte bör översättas. Jag pratar endast för mig
själv förstås, men man får nästan utgår från att man låter koden prata
för sig själv.

Kommentarer i dessa exempel är iofs en annan sak.

Hälsningar,

Andreas Nilsson
[email protected]