Re: 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 asmodean@lka.nu