text:
Category talk:TESOL Materials

{|style="width:100%; background:beige;"
 * width="60px"| [[Image:Information_icon.svg|40px]]
 * Welcome to the Talk page for TESOL Materials
 * To leave a message, click on the "+" tab at the top
 * Enter a subject or headline and write your message
 * Click on "Show preview" button below to view your message
 * Click on "Save page" button below to leave your message
 * For further help on using talk/discussion pages go to the Help:Talk page

What's the relationship between TEFL and TESOL, are they the same?
206.73.209.94 05:59, 10 March 2010 (UTC)What's the relationship between TEFL and TESOL, are they the same?

Thanks, Lily
 * }

title: Category talk:TESOL Materials


text: TESOL Materials/New Dynamic English-Module 1:5 (Video Interactions)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text: TESOL Materials

title: TESOL Materials


text:
File:Maramraj seduced-by-darkside.pdf

Used with the WikiU Film School Lesson on how to format a movie script

title: File:Maramraj seduced-by-darkside.pdf


text:
User talk:Mprichardson

Welcome
Hello Mprichardson, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. After you leave a comment on a talk page, remember to sign and date; it helps everyone follow the threads of the discussion. The signature icon in the edit window makes it simple. To get started, you may
 * Take a guided tour and learn to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research activities;
 * Read and help develop our community policies；or
 * Chat with other Wikiversitans on #wikiversity-en.

And don't forget to explore Wikiversity with the links to your left. Be bold, and see you around Wikiversity! Erkan Yilmaz Wikiversity:Chat  07:27, 7 March 2008 (UTC)

title: User talk:Mprichardson


text:
Orbital mechanics

This topic page is for organizing the development of Orbital mechanics content on Wikiversity. If you are knowledgeable in any area Orbital mechanics, feel free to improve upon what you see, we would greatly appreciate your contributions.

Introduction to Orbital mechanics
Orbital Mechanics is a fairly broad category involving the study of orbiting bodies. Most commonly, orbital mechanics refers to astronomical bodies orbiting one another such as planets, asteroids, space debris, artificial satellites and spacecraft, and stars. However, orbital mechanics can, in general, also be taken to mean the interactions on a cosmic scale such as those of black holes, quasars, galaxies, and galactic structures as well as interactions on a quantum scale involving atoms and other elementary particles. However, since entities in these two extreme realms do not typically follow classical orbital dynamics (those driven primarily by gravity) this topic will focus primarily on working with bodies on the first scale mentioned.

Orbital mechanics has its foundation in areas such as physics, dynamics, and advanced mathematics involving differential equations. That being said, it would behoove students to properly educate themselves in at least these three areas before trying to understand much of what is covered in orbital mechanics.

Types of Orbits
Generally speaking, there are four types of orbits that a single body can follow when acted upon by a central body. These four types or orbits each have unique characteristics and applications. They are named after the four conic sections of mathematics. Each one is described in more detail as follows:

Circular Orbits
Circular orbits are the only other kind of orbit in which the orbiting body cannot naturally escape the central body. Circular orbits have an eccentricity of 0. Generally speaking, circular orbits do not exist naturally and are very impractical artificially. Rather, near circular orbits (orbits with eccentricities so close to 0 that they can be assumed circular) are more commonly occurring.

Elliptical Orbits
Elliptical orbits have an eccentricity less than one. These are the most commonly referred to orbits as these orbits describe the motion of a satellite body in a captured orbit around a central body. That is, elliptically orbiting bodies do not naturally escape from their orbit without some external force.

The central body of an elliptical orbit resides at one of the focal points of the ellipse that the orbiting body traces out.

Parabolic Orbits
Parabolic orbital trajectories have an eccentricity exactly equal to 1. Like circular orbits, parabolic orbits are not realistically common. However, they are very useful in that they represent the first escape trajectory of an orbiting body. That is, for an orbiting body to escape its orbit around a central body, it must at least achieve a parabolic orbit. As such, parabolic orbit calculations are very common in problems involving transfer orbits.

Hyperbolic Orbits
Hyperbolic orbits, like parabolic orbits, represent an escape orbit. That is, after orbiting a central body once (at the focal point of the hyperbola) the orbiting body will "slingshot" around the central body and move away from the central body continuously to never return again (unless influenced by some external force). Hyperbolic orbits have an eccentricity greater than one and are the most common type of orbit employed to transfer an orbiting body from one central body to another. For the purposes of orbital trajectory analysis between two central bodies, numerous hyperbolic orbits are often studied and compared to derive an optimal path for the orbiting body (optimization may take into factors such as, but not limited to, fuel consumption, solar heating, debris avoidance, and simplicity of control methods).

Learning projects and resources

 * Orbital mechanics
 * Orbital geometry
 * Search for Orbital mechanics at Wikiversity

Wikimedia

 * Orbital mechanics

title: Orbital mechanics


text:
Ideas in Geometry/Instructive examples/Problem

In city geometry and Euclidean Geometry, a parabola is a set of points such that each of those points is the same distance from a given point, A, as it is from a given line, L. This is a little trickier in city geometry because there are no curved lines.

Question 22 asks you to draw a parabola determined by the point (2,0) and the line y=0. So in this case A from the definition is (2,0) and L is y=0.

The first thing you should do is draw on a coordinate plane the point (2,0) and the line y=0. (Hint: y=0 is a horizontal line that exists along the x-axis) You should notice is that the point (2,0) is on the line y=0. Since the point lies on the line, there is only one point where the point of a parabola can be the same distance from the point (2,0) and the line y=0 and that point is (2,0) because (2,0) is zero distance away from the point (2,0) and the line y=0. This means that the parabola created in this problem is actually just one point: (2,0). The picture looks like this:


text:
BCP/Eranthis hyemalis

Eranthis hyemalis

title: BCP/Eranthis hyemalis


text:
BCP/Eranthis hyemalis/Logs

This page contains recent bloom logs for the plant Eranthis hyemalis (Winter Aconite).

Recent Logs

 * SB Johnny-LM 11:15, 7 March 2008 (UTC)
 * SB Johnny-LM 09:22, 14 March 2008 (UTC)
 * SB Johnny-LM 08:36, 22 March 2008 (UTC)

=====Archived Logs===== (If there are more than 5 signatures under the recent logs heading, move the oldest logs to under this heading (generally leave the 3 most recent).
 * (no archived logs yet)

title: BCP/Eranthis hyemalis/Logs


text:
BCP/Cornus officinalis

Cornus officinalis

title: BCP/Cornus officinalis


text:
BCP/Cornus officinalis/Logs

This page contains recent bloom logs for the plant Cornus officinalis (Japanese Cornel Dogwood).

Recent Logs

 * SB Johnny-LM 11:25, 7 March 2008 (UTC)

=====Archived Logs===== (If there are more than 5 signatures under the recent logs heading, move the oldest logs to under this heading (generally leave the 3 most recent).
 * (no archived logs yet)

title: BCP/Cornus officinalis/Logs


text:
User:Timmdn

Headline text
Staff support in Community Engagement

we offer training fo staff to deign and deliver community service learning

title: User:Timmdn


text:
BCP/Crocus

Crocus

title: BCP/Crocus


text:
BCP/Crocus/Logs

2008 Logs

 * SB Johnny-LM 12:23, 7 March 2008 (UTC)
 * Ngravagna 17:04, 22 March 2008 (UTC)
 * --Juan Pisek 18:27, 22 March 2008 (UTC)
 * mikeu talk 23:14, 22 March 2008 (UTC)
 * --Juan Karlovy Vary 23:03, 23 March 2008 (UTC)
 * SB Johnny-LM 10:56, 4 April 2008 (UTC)
 * Luai lashire 00:57, 10 April 2008 (UTC)
 * --Juan Karlovy Vary 08:27, 21 April 2008 (UTC)

2009 Logs

 * Ngravagna 06:56, 1 March 2009 (UTC)
 * Jomegat 19:27, 25 March 2009 (UTC) (first bloom of the year!)
 * Jomegat 23:54, 3 April 2009 (UTC)
 * Jomegat 03:04, 7 April 2009 (UTC)
 * Jomegat 16:58, 10 April 2009 (UTC)
 * Jomegat 19:43, 14 April 2009 (UTC)
 * Jomegat 16:59, 17 April 2009 (UTC

Recent Logs

 * --Anna reg 18:43, 24 March 2011 (UTC)
 * --Jomegat 15:54, 16 March 2010 (UTC) (first bloom of 2010)

title: BCP/Crocus/Logs


text:
User:Sara F/Gemensam text

Ok, jag börjar med att slänga inmin text här, bara att ändra om, fylla på, korta ner som ni behagar. Var inte blyga!/Sara F 12:52, 7 March 2008 (UTC)

Modersmål och moderskap

Inledning

I denna text har jag utgått från ”The Native Speaker: Myth and reality” av Alan Davies (2003) och (en artikel ur Negotiation of identities in multilingual contexts): ”Mothers and mother tongue: Perspectives on self-construction by mothers of Pakistani heritage” av Jean Mills (2004).

En av de första sakerna som slog mig i läsningen av Davies bok var att det, mig veterligen, inte finns någon term för det som på engelska kallas the native speaker. Det kan översättas med en person som ’talar som en infödd’, eller det som i dagligt tal kallas modersmål, med andra ord en ’ursprungstalare’ eller, som jag hädanefter kommer att skriva, modersmålstalare Davies tar itu med detta komplexa begrepp genom att resonera kring föreställningar om modersmålstalare utifrån skilda teoretiska perspektiv. Han redogör också för termer som ofta, både i vardagligt tal och i forskarsammanhang, används synonymt med modersmål såsom hemspråk (home language), förstaspråk (first language) och dominant språk (dominant language). Jag kommer inte gå in på de skillnader och likheter som finns mellan dessa, utan nöjer mig med att se närmare på begreppet modersmål. Några av frågorna han försöker besvara ur olika synvinklar är vem som kan anses tala ett modersmål? Huruvida alla talar ett modersmål och om det i så fall är att betrakta som det första språket du lär dig som barn? Kan en person ha flera modersmål? Dessa frågor ligger också till grund för denna text.

I mina egna funderingar kring modersmålstalare återkom jag ofta till kopplingen mellan modersmål och mödrar/moderskap och jag saknade en djupare analys av detta i Davies bok. Jag valde därför att studera Jean Mills (2004) artikel närmare: Hon har gjort en studie av flerspråkiga kvinnor i Storbritannien, i syfte att analysera modersmålsdiskurser i relation till kvinnors identitet som mödrar. De tio kvinnorna som deltog i studien var mellan 29 - 43 år. Alla talade flytande engelska, liksom punjabi eller mirpuri och några hade också varierande kompetenser i arabiska och urdu. Fem av kvinnorna var födda här, medan resten kom till Storbritannien som barn och de hade alla egna barn i olika åldrar. Under två års tid intervjuades de av Mills angående deras synpunkter och attityder gentemot deras egen och barnens flerspråkighet. Jag kommer att använder mig av hennes studie för att exemplifiera några av Davies teoretiska resonemang.

Kommenterarer från Jenny I arbetet med min text kring Davies bok använde jag mig först av modersmålstalare som en översättning av native speaker, men detta är en problematisk översättning. Kenneth Hyltenstam och Niclas Abrahamsson använder termen infödda talare (2004:221), vilken kan ses som ett alternativ till modersmålstalare för att komma ifrån problematiken kring moderskapet. Vad innebär det dock att vara infödd? Infödd i vad? Jag tolkar det som att infödandet handlar om att födas in i en språkgemenskap, vilket gör att frågan om moderskapet åter blir aktuellt. Vi kommer således inte infrån infödandet i en språkgemenskap handlar om att födas av en viss förälder/föräldrar. Begreppet infödd talare i en språkgemenskap leder dock till frågan hur stor språkgemenskapen bör vara för att en talare ska bli infödd? Innebär föräldrarnas medlemsskap i en språkgemenskap som infödda talare ett automatiskt medlemskap även för barnet? Jag vill konkretisera problematiken genom ett exempel: Paulo är född i Sverige. Hans mor är född i Peru och pratar spanska, svenska och engelska. Hans far är född i Spanien, men pratade katalonska i hemmet som barn. Fadern pratar även spanska, franska och svenska. I hemmet pratar föräldrarna spanska, katalanska och svenska, men även en del franska som fadern undervisar i. Vilken språkgemenskap föds Paulo in i? Den svenska, spanska, katalanska eller franska? Räcker det med att en förälder pratar ett språk, exempelvis katalanska med barnet för att han ska bli en infödd talare i språket? Eller är det så att det krävs att en större mängd människor runt omkring barnet talar ett visst språk för det ska bli en infödd talare? Ett kriterium som i Paulos fall skulle göra att han enbart kan bli en infödd talare i svenska. Eller är det så att Paulo blir en infödd talare i alla dessa språk eller i en flerspråkig unik språkgemenskap?

Man kan dra en hel del paralleller mellan frågan om infödda talare och modersmålstalare med frågan om medborgaskap.

En moders språk

I Svenska akademins ordbok (SAOB) definieras modersmål som just moderns språk: ”det språk som man som barn har lärt sig tala (eg. av sin moder)”, men också som ”fosterlan¬dets språk, det språk som talas av det folk man tillhör” samt ”ens eget språk” (http://g3.spraakdata.gu.se/saob). I texten som följer kommer jag att återkomma till dessa tre till synes självklara, men i flera avseenden förenklade definitionerna, då jag menar att de ett tydligt sätt redogör för de mest dominerade föreställningarna om modersmål. Själva ordet modersmål är ursprungligen är en sammansättning av två ord, moder och mål (det sistnämnda står i detta sammanhang primärt för tungomål - alltså språk - och inte andra betydelser av mål, även om det inte är svårt att associera det till ett mål mat eller livsmål osv.). Det talas inte om en persons fadersmål  eller föräldramål, vilket pekar på den tydliga kopplingen till modern och de(t) språk som hon talar, som lärs ”from your mother’s knee” som Alan Davies uttrycker det (2003 s 16). Här förstärks tanken om (den biologiska) modern som barnets mest oumbärliga vårdnadstagare, genom att hon också lär barnet dess första språk – det språk som ses som det viktigaste (och kanske enda) som individen kan behärska fullt ut. Svaret på frågan om vi kan ha flera modersmål blir inom ramen för denna föreställning nekande: Då vi bara har en moder kan vi bara ha ett modersmål (Mills 2004 s 166). Här bortses det helt från det faktum att modern kan vara flerspråkig, eller att ett barn kan ha flera mödrar, som exempelvis barn till lesbiska par eller adopterade barn, som talar olika språk. När det gäller barn som adopteras sent i livet och byter både språklig och social och kulturell miljö, kan man fråga sig vilket språk som så småningom skall betraktas som dess modersmål: Det förstaspråk som barnet lärt av den biologiska modern (eller annan vårdnadstagare) eller adoptivförälderns språk? Resonemanget en moder-ett modersmål utgår från att barnet växer upp i en helt enspråkig omgivning, där inga andra personer i barnets närmiljö skulle kunna bidra till att ge barnet fler än ett modersmål. Det förutsätts också att barnets egna unika språk, dess idiolekt, överensstämmer med moderns; att barnet genom att lära sig av moderns sätt att tala också talar likadant (Davies 2003). Med andra ord att modersmål är ett språk som är med eller mindre nedärvt i generation efter generation, i likhet med en viss etnisk, nationell, religiös eller social och kulturell tillhörighet. Att ha ett annat modersmål än sina föräldrar är med detta synsätt närmast att betrakta som en omöjlighet. I skenet av detta är det därför intressant att lyfta fram de döva eller hörselskadade barn som har teckenspråk som modersmål, medan deras hörande föräldrar har lärt sig det sig det först efter att de fått barnet, och därmed har ett annat modersmål. Enspråkiga isolerade miljöer är huvudtaget att betrakta som alltmer ovanliga, flerspråkighet kan i många fall ses som en norm för världens befolkning. I en nation som Sydafrika, med elva officiella språk, växer de flesta barn upp med minst två språk (Bloch & Alexander 2003 s 92). Det handlar inte bara om att de lär sig ett språk till av ex sina jämnåriga vänner vid sidan av det språk som talas av deras föräldrar: Det finns ex barn som först lärt sig zulu av sina nannies innan de lärt sig tala engelska eller afrikaan som föräldrarna (Mills 2004). Dessa språk är inte bara väldigt olika lingvistiskt sett, men den sociala och kulturella identitet som följer med språket skiljer sig också åt. Historiskt sett har det länge funnits en stark koppling mellan rasideologi och språk i Sydafrika och än idag har zulu en stark identitet som inhemskt afrikansk språk medan engelska och afrikaan ses som förtryckarnas och kolonialherrarnas språk (Bloch & Alexander 2003 s 91 f).

Kopplingen till etnicitet, kultur, nationalitet

Den föreställda gemenskapen i nationer som bygger på ett folk, ett land, ett språk (och därmed en kultur) blir alltmer ifrågasatt i och med den tilltagande flerspråkigheten i miljöer och hos enskilda personer (Davies 2003, Anderson….). Ändå kvarstår en närmast romantisk föreställning om modersmålet som fosterlandets språk, ”det språk som talas av det folk man tillhör” som det står i SAOB, och även här kan modern betraktas som en centralfigur. Hon står som bärare av en viss etnicitet, nationalitet eller ’kultur’, vilkens dominerande värderingar, normer och praktiker uttrycks genom språket. Därav kan det förefalla vara av stor vikt, särskilt för marginaliserade minoritetsspråk, att språket och med det en viss form av kulturell gemenskap, förs vidare till nästa generation genom moderns omsorg (Mills 2004 s 165). Detta medför också att en del mödrar beslutar sig för att inte lära barnen vissa språk, eftersom dessa representerar konventionella traditioner och värderingar som de vill förmedla till sina barn. Såsom Mills (2004) beskriver det, är modersmål “often not merely associated with mothers’ role in transmitting a culture, but serves as the embodiment of that culture, ethnicity or sense of nationality”(s 166).Hon menar vidare att modersmål som metafor “carries with it the overtones of mother earth, motherland, a crucial identifier of connectedness, rootedness, and belonging” (Mills s 166). Själva begreppet modersmål kan bli väldigt laddat genom att det inte bara kräver att det ska talas av ens förälder utan också knyter an till ens viss nationell, kulturell och etnisk identitet. Några kvinnor i Mills studie ville inte använda begreppet alls, och talade om hemspråk och förstaspråk istället. En kvinna menade att hon inte hade något modersmål just för att hon kände sig rotlös: ”’Mother tongue’ is like having roots somewhere, having a root in a language, but I don´t think I do” (citerat i Mills s 174). Samtidigt menade hon att det var viktigt att hennes barn visste att de hade rötter i ett annat språk (än det i landet dominerande språket engelska), d v s att de genom ett språk skulle få förståelse och bli förankrade, rotade, i en annan etnisk och kulturell kontext. I denna kontext kan det uppstå s k språkgemenskaper, vilket enkelt uttryckt innebär att en grupp människor kommer överens om gemensamt språkbruk (Davies 2003 s 46) Utveckla ämnet språkgemenskaper?

Det kan också ses som moderns plikt att förse sitt barn med ett ”gott” språk som är länkat till ett välartat uppförande. I Mills studie beklagar sig några av mödrarna över att barnen inte lärt sig hur man språkligt tilltalar äldre på ett respektfullt sätt, och att deras föräldrar och svärföräldrar anklagar dem för att bristande uppfostran. Det anses generellt vara deras ansvar att se till att barnen inte bara har lingvistiska, utan också nödvändiga kulturella och sociala kompetenser för att kunna delta fullt ut och bli erkända av alla inom språkgemenskapen. Ur ett sociolingvistiskt perspektiv, där språkgemenskaper betonas, kan det rentav anses som att mödrarna i detta fall har ’misslyckats’ med att ge barnen ett modersmål?

Hemspråk, vardagsspråk, kvinnospråk eller standardspråk?

Däremot kan det språk som endast eller mestadels talas i en viss domän, i många fall hemmet, få en viss karaktär och en specifik, begränsad vokabulär (Mills 2004 s163). Detta har gett upphov till dels att modersmål kan definieras som hemspråk d v s ett språk som talas hemma – i motsats till det standardiserade språk som talas i det offentliga (se Davies 2003). Eftersom modern som metafor också associeras med hemmet och det privata, och det huvudsakligen förväntas vara den som barnet lär sitt språk av, kan modersmål också förstås som en form av kvinnospråk – ett enklare, vardagligare och mer känslomässigt språk. Tanken om att det skulle finnas ett särskilt kvinnospråk har dock starkt ifrågasatts av feministiska lingvister (se ex Edlund, Erson & Milles 2007): Att en moder talar på ett visst sätt med sitt barn har inget att göra med hennes kön, snarare är det relaterat till hennes sätt att umgås med och vårda barnet (Mills s 164). Däremot uppger många flerspråkiga personer att de upplever sig ha ett särskilt känslomässigt band till det språk de definierar som modersmålet, både i former av starka negativa och positiva känslor. Detta inte ter särskilt märkligt eftersom modersmålet ofta lärs som barn – och därmed är starkt förknippat med ens barndom och uppväxtvillkor. Det resonemang jag hittills fört pekar på att grunden för alla antagande om modersmål är att dess starka förankring i identitetsskapande processer. Modersmålet blir en del av en persons identitet, ens unika sätt att uttrycka sig och kommunicera på - ”ens eget språk”, för att koppla tillbaka till definitionen i SAOB. På så vis konstruerar språk identiteter, såsom för kvinnorna i Mills studie där modersmålet (och deras strävan att lära barnen det) är en viktig del av deras identitet som mödrar. Samtidigt finns föreställningen om en modersmålstalare som behärskar ett språk till fullo, som utövar ett språk som i mångas ögon ses som det mest korrekta och sanna. Att bli accepterad som en modersmålstalare blir något eftersträvansvärt för alla s k andraspråkslärande, särskilt om språket ifråga är det dominerande standardspråket i samhället (Davies 2003). Davies tar exempel på jobbannonser där man söker efter modersmålstalare – här handlar det egentligen inte om att tala ett modersmål, utan att tala ett språk som blivit standardiserat i just det samhället.

Detta tänkte jag utveckla vidare:Ex. Miljonsvenska och Verlan…. Om mitt modersmål ser ut så, är det då att betrakta som ett modersmål fast det inte fast det inte är ett officiellt ’riktigt’ språk….? En annan form av hemspråk är Karins idiolektidé om barn som talar ett internt teckenspråk hemma…

Vem förutom jag själv kan ta sig rätten att avgöra vilket modersmål jag har? Måste jag visa upp en viss lingvistisk kompetens eller räcker det med att jag själv identifierar mig som modersmålstalare? Låt oss titta närmare på en sådan situation:

I Sverige har, enligt grundskoleförordningen 1994:1194,  vissa elever rätt till det som förut kallades hemspråksundervisning men nu benämns som modersmålsundervisning. Kriterierna som ställs upp är att ”en eller båda av elevens vårdnadshavare har ett annat språk än svenska som modersmål och språket utgör dagligt umgängesspråk för eleven”. Detta är dock inte nödvändigt när det gäller elever som talar tornedalsfinska, samiska och romska språk, är adopterade eller ”har ett annat modersmål än svenska”. Det går med andra ord att utskilja i huvudsak två kategorier elever som detta berör: Elever vars vårdnadshavare har annat språk än svenska som de definierar som sitt/sina modersmål, och elever som själva har annat språk än svenska som de definierar som sitt modersmål (minoritetsspråkstalare och adoptivbarn kan möjligen ses som undantag). I båda fallen utgås det från föreställningen om att ett barn bara har ett modersmål, och modersmålsundervisningen får således bara omfatta ett språk per elev. Frågan är hur familjer som är flerspråkiga löser detta problem? På mitten av 1980-talet gjordes en studie som visade att de fall som modern och fadern talade olika språk valdes oftast moderns språk – modersmålet gick s a s före fadersmålet (Natcher & Sirén 1986). Än en gång styrks kopplingen mellan moderskap och modersmål, som är att betrakta som en dominerande diskurs, trots att det finns åtskilliga exempel som tyder på annat.

-

(Ofullständig)

Litteraturlista:

Bloch, Carole & Neville Alexander (2003): “A luta continua! The relevance of the continua of biliteracy to South African multilingual schools”. I Nancy Hornberger (ed): The continua of biliteracy. An	ecological framework for educational policy, research and practice in multilingual settings.

Davies, Alan (2003): The native speaker: Myth and reality.

Edlund, AnnCatrine, Eva Erson & Karin Milles (2007): Språk och kön.

Mills, Jean (2004): Mothers and mother tongue: Perspectives on self construction by mothers of Pakistani heritage. ….Negotiation of identities in multilingual contexts

Natcher, Elias & Sirén Ulla (1986): Modersmål, fadersmål… (ska kolla upp…)

title: User:Sara F/Gemensam text


text:
Configuration Management/SPM

Configuration management (CM) concepts were created by the United States Department of Defence in 50’s. Those concepts were approved and implemented by various management modules and standards. CM is a management discipline as a baseline for other subcategories like Software Configuration Management which is put into practice in software engineering.

CM is the controlled way to manage the development and modifications of systems and products, during their entire life cycle.

In general Configuration Management and Software Configuration Management issues and resolutions are the same, but SCM is concerned with all the things having to do with building and deploying well tested, reproducible software builds. SCM is throughout the whole software development life cycle and concerned to achieve desired results at the end.

To realize it there is a wide range of CM tool vendors that provide an environment, defined methods and processes to support software developers and project managers on a daily basis. This is important because software is deployed in a cycle, and the uptake of this cycle can vary widely and can mean that features that are currently deployed in the field have been significantly changed or rewritten by developers, meaning that bugs found in the field will require developers to revisit old code.

SCM is becoming more adopted and significant due to Capability Maturity Model Integration developed by Software Engineering Institute. Significance in CMMI to achieve level two to five appraisal, CM utilize a great role.

CM System Functionality and Integration
Software Configuration Management could be grouped in the domain of significance that encompasses key functionalities. Software system architecture describing the build-up of the system includes rules and procedures within software application functionality and user interfaces. In distributed environment importance of data representation and communication between distributed objects, protocols and message interchange between client/server applications.

Data representation in software engineering is generally represented as a file system with files and directories to manage data and metadata. Data replication in distributed environment is dealing with repositories, backup systems and client/server applications in SCM. Focus on distributed computing applications, SCM tools treating distributed objects as peer-to-peer applications. Distributing data and metadata is managed synchronized; deadlocks and access rights to the data are applied, particularly in version control.

For application integration there are many tools available in SCM. Support for information exchange between other applications is provided. Development environments are often designed as a tool within a tool. Integrated Development Environments (IDE) often provides additional capabilities for version control besides compilation of the code that can be checked in/out from repositories.

The concept of version management
Version management is the basic function in software configuration management. All of elements should be auto-given specific version label, to ensure it’s unique. It is also a process to identify and track within different system versions. The purpose of version identification is to differ, search, and track system versions, it represents the relationship with versions. Any of one version should be unique and differ from other versions on its functionality and capability. In every one version, the defect should be fixed, or some shortfall will be added or amended.

The access privilege should be configured according with the position and status of the baseline. Generally, before the baseline version, all versions should be locked. If it needs some change on those versions, it should do operation based on the process of the change control.

Advantage of version management

 * Ensure the system can restore or go back to any version in history.
 * Traceability between versions
 * Providing help on finding bugs

Version Models

 * Check In/Check Out Model
 * Composition Model
 * Long Transaction Model
 * Change Set Model

Configuration Selection
Selection of configuration management tools for any software project are driven by a number of factors.
 * Pre-existing solutions
 * Company Culture
 * Availability of solutions
 * Resource constraints

Use of SCM tools are widespread and many organizations will have an established SCM system in place. However in organizations that do not have such and SCM system in place, a procedure along the following lines can be employed:

 * Establish an Evaluation Group
 * Set out Evaluation Criteria and Prioritized Requirements
 * Research and choose tools for evaluation
 * Compare tools and make final decision

CMM and SCM Selection
CMM designates CMM as a key Process Area (KPA) and sets out requirements for planned use of SCM within an organization. These requirements will govern how SCM solutions are chosen in any organization. The factors that will influence the choice of SCM tools are mainly concerned with training and resourcing of both a specific SCM group as well as the everyday users of the SCM system. Procedures are defined by the SCM group that govern the structure and use of the SCM system.

CMM lists activities performed in the KPA which will constrain the types of SCM tool that can be chosen. However almost every SCM tool will meet these requirements. In short while CMM indirectly shapes the type of SCM tool used, it does little to list specific requirements.

Build Management
After development of source code the software is passed on to the software quality team who takes responsibility for system testing. Should any faults be discovered during system tests, the software quality team sends back the source code to the development team for repair. The repaired version comes back to the quality assurance team where the source code is checked again for quality. If the quality is acceptable the source code is then considered controlled system which means that changes have to be agreed on and recorded before being implemented. Every version of accepted source code must be placed under configuration management. These versions are stored for later release into production. The concepts of Configuration Management describe these processes in more detail.

Release Management
Software eventually needs to get released to the end users and this is what the procedure of Release Management is for.

The software being released is linked with the “Build Management” process because the software being released comes from a production build of the Build Management process. This software could be in different forms, e.g. patch, upgrade or full version releases.

During the process of Release Management the software is finalised for release to the end users. Release Management is made up of four parts:

[Source: ]

 * 1) Change Management – version control of changes
 * 2) Build Management – building software under controlled measures
 * 3) Deployment – fully tested then sent to production
 * 4) Incident Management – this includes keeping track of any issues that may arise that would affect production or require the production process to change.

Release Management, while mainly thought of for releasing runtime files, can also be used in releasing related files. Related files are:
 * 1) Configuration Files – specific installation configuration
 * 2) Data Files – for the system to work
 * 3) Installation Program – to help the end users to set-up the program on their machine
 * 4) Documentation – electronic and/or paper documentation to describe the system and its operations, functionality, etc
 * 5) Packaging – logos, boxes, pictures, etc for the release

It is up to the customer to decide whether or not they want to install the release – they may be happy with their current installation.

Issues such as how to release the product (CD, DVD, downloadable, etc), documentation to include, marketing (packaging, etc) need to be decided during the process.

The main benefits of Release Management to companies are increased customer satisfaction (from more efficient release cycles) and reduction of costs.

Workspace Management
Increasing amount of a large scale software projects require workspace managements for groups and individuals. In Configuration Management Workspace Management is a very important module. Workspace Management deals with private isolated workspaces and shared. For multiple developers to work on projects transparently, CM tools should provide transparent environment to developers rather than managing individually, regarding access rights, synchronisation to files check in/out, build/make functionality and file merging, this encompasses concurrent control and development.

Change Management
Changes in software occur throughout the development lifecycle. Those changes can be added functionality, bug fixes, improvements of the module. Change Management deals with these issues to provide standard and efficient methods to implement and trace those changes.

The goal of the Change Management process is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently improve the day-to-day operations of the organization.

Change Management does not predict any changes but it handles the changes that occur during the development and maintenance phase. Traceability is a part of the Change Management. Valuable information may be acquired from that and valuable metrics can be extracted.

Component Concepts
In order to apply configuration management effectively, it’s important to have the fundamental concepts in place. There are 4 main activities to consider:

Identification
The “Identification” process is concerned with uniquely identifying a configuration item and its relation with other configuration items. A configuration item is an item produced in several versions and placed under configuration management. The description of the configuration item which is included while storing the item is called Metadata. Metadata is a database concept that means data about the data stored in a database. Therefore the initial process in configuration management is to identify configuration items and their description in the form of Metadata.

The identification process can be initiated as a result of two main incidents. For example when a project plan includes deliverables in response to the project scope it can be assumed that this deliverable will be designed, developed, tested etc. This deliverable must be placed under configuration management.

On the other hand a change might be required on existing configuration items. Such a change is initiated through a Change Request. The result of such a change is automatically a new version of the existing configuration item and therefore must be placed under configuration management.

Storage
With all deliverable products it is important have a storage system in place so that the products can be accessed and kept safe from damage or loss. This storage system can be any physical implementation, for example in the form of a file server, archived optical media, etc. An important aspect of this storage system is that there is the ability to record registration and release information about the items.

Storage involves three main processes:

In this event the item has reached a state where it’s ready to be placed under configuration management – in other words when it has been approved.
 * Placement in storage from the production/ development

Should the item be required for usage, a release request is initiated to grant permission and distribution of the item.
 * Release from storage for usage

This occurs in the case of the requirement to develop a new version of an existing configuration item. The release from storage back to production is initiated through a Change Request. In this case it is important to have control in place to ensure redundant changes being applied at the same time.
 * Release from storage for production/ development

Change Control
It is not uncommon for configuration items to be prone to change. Business requirements can change or evolve over time or sometimes a configuration item performs different than expected. Changes of products are then necessary to adapt the business requirements. Change control manages Change Requests and actual changes made to products. For configuration items it is important to have a record to trace any change to its predecessor and where, when and by whom the change was made.

Examples of events where Change Control is initiated:
 * A specification problem caught during a walkthrough
 * A coding error found during an inspection
 * An enhancement request from a customer
 * A marketing request for additional features
 * A problem report from a customer
 * A business opportunity, for example a migration of the product to a new platform

Status Reporting
In order to have a clear understanding of the state configuration items and changes being  made to products Status Reporting tools provide the necessary information to manage a product’s development and maintenance in readable manner. Status reports include:
 * Release notes
 * A configuration item list
 * A traceability matrix

Context Management
In complex applications involving detailed workflow and intrinsic relationships between data files, context management tools can shield a user from much of the complexity involved in carrying out a task. Context management tools will effectively track the actions of a user, continuously managing dependencies and versioning for relevant data files as well as storing related worksets as a working context for a given action. The context is persisted and the user can leave and return to a given action as desired. The relevant context will be restored and the user can carry on from where the left off. The benefit to the user is that
 * they do not have to concern themselves with low-level SCM actions for individual files and interdependencies
 * relevant worksets can be represented as a single entity or collection of entities, rather than a collection of files scattered around an SCM storage system
 * work can be paused and resumed as required and it is easy for the user to return to a specific task without having to concern themselves with configuring a specific environment, as the context will take care of that.

Context Management is widely used in medical applications and is a generally useful in assisting workflow.

Contract
A software development process will often require the deliver of certain items based on a given set of inputs and procedures. A contract defines what those inputs are and the process and deliverables for that process item. Inputs and outputs may be configuration items. By following the contract, process is guaranteed, defined outputs are delivered and process is easily measured against contract milestones.

Change Request
Change request manages the work flow required to execute a change request. Evaluators will be identified and assigned for an incoming change. Once evaluated the change will be approved or denied. If approved suitable team members will be assigned. Changes will be carried out and verified before finalizing and qualifying the change. Only then can the change request be finalized.

Life Cycle Model
The life cycle model applies to the means of managing SCM items through the phases of the life cycle of the product and is intrinsically linked with the software development model chosen. The life cycle model for a project using a waterfall process would focus on the transitions from stage to stage, and the handoff and interactions between development, testing, release and production. For an Agile project, the life cycle would need to cater for throw-away prototypes, rapid change and frequent releases.

Change Set
A change set is made up of a difference relationship, the related files and information about changes. A difference relationship is an abstract of the differences between the versions of components.

If changes to a configuration are made, they are recorded in a change set. These change sets can be used to have customised configurations of the software.

The information recorded includes:
 * The changes made to the files in the configuration
 * Why the changes were made (the reason)
 * Who made the changes
 * When the changes were made

The places where the changes are recorded depend on the scope. The scope is defined by the user e.g. fixing a bug, resolving an issue number (from a tracker system), etc.

Each change set is given a specific name. The user selects the change set to apply from the “default” configuration.

The change sets can be based on previous change sets or can be new ones. By using the change sets, users can pick and choose different configurations for their current needs.

System Modelling
System Modelling details how the system is made up (its structure), the different components in it, and the build process of the system.

In System Modelling there is a “family” which is used to keep track of the different versions of a project. This “family” contains a history of all the different versions associated with the date and user that created them.

Jasmine is a system model that is textual in nature. It is modified by the users and tools can use this to do their work. It is described by sets and functions. These sets and functions represent different types of information:
 * 1) Relations between product components – module makeup, dependency of components, order of build, “templates” (description of all relations).
 * 2) Version binding information – notion of a “family” [see above]
 * 3) Construction rules – how components were build / are to be built, what compiler and version was used, arguments for the compiler, etc.
 * 4) Verification rules – are the compiled files correct and valid, etc.

With all the relationships and rules recorded with Jasmine, the tools accessing it can make better assessments on what components would be affected from the result of changing another component.

The integrity of the project is helped by System Modelling because of the way it helps describing the configuration, dependencies, etc.

Subsystem
The idea of a subsystem is the division of a large project into smaller sections. When a user makes changes, then the changes are limited to the subsystem rather than the entire project.

Each subsystem is regarded as a separate project when working with it – it has its own version control system, etc.

Unless specified that components are to be exported in an interface, subsystems cannot access components of other subsystems.

The “Rational” environment can be used to manage subsystems. It does checks like checking to see if the subsystem implements an interface correctly, etc.

The users can select different subsystems and put them together to form a version of the overall application.

Object Pool
The “Domain Software Engineering Environment” (DSEE) can generate objects, which are placed into an “Object Pool” for each of the users to share and use. The objects are generated from the information available from system modelling. Different versions of components with different properties, etc can be generated and placed in the object pool.

Each object in the object pool has metadata associated with it; version, source, etc.

When a user wants to build a system and one part of the system is a custom version, if that custom version has already been generated and placed in the object pool, then that can be used rather than building it again. When the objects expire they are removed from the object pool to save space, processing time, etc.

Attribution
With attribution, a system is defined as a data model in an ERD database. The components of the system are represented as objects and all the relationships between it and the other components are represented in the database. The attributes (name and value pairs) are linked with the objects in the database.

Attributes can be predefined or user-defined. An example of a predefined attribute is “type” which is used to describe if the object is a document, a component, etc)

The dependencies between the components are represented as relationships in the database, e.g. one object is associated with another.

By using attributions, a user can describe a system in an abstracted manor rather than a full configuration of files, data, documents, etc.

Consistency Maintenance
Consistency maintenance is used to check if the configurations are valid. The Configuration Management Assistant (CMA) does the validation and usability checks. Usability checks ensure that the configurations:
 * Have complete configuration
 * Are Unambiguous
 * Are Consistent
 * Lack version skews

By having usability checks, CMA ensures that all component instances are in the configuration and only one instance of the component exists.

When a new configuration is created, CMA uses the information already acquired in the database to check if the new configuration is usable. By doing this, any issues with the configuration can be detected and consistency can remain intact.

Work space
According to the requirement, every developer works in different work space in different develop phase. In private space, developer works on his private branch after get the operation admission. All of his contribution and progress will be present on this private branch version. Except the developer himself, other team members all could not operate any one of data on this private space. This work space is a public space for develop team. The team leader has the privilege to read and write on this work space. Within the team, any of team members only can read on this work space. Public work space is to store the achievement for the whole develop teams. The standard version is provided in this work space as the knowledge base for the whole organization.
 * Private work space
 * Integration work space
 * Public work space

Transparent View
Every team member would be given the READ privilege to do read operation on work space.

ANSI/EIA-649 National Consensus Standard for Configuration Management
This standard is for use in Configuration Management and contains details of CM terminology and a CM process. This process is defined by 5 Configuration Management functions and their underlying fundamental principles.

The standard is there “to maintain consistency between the product definition, the product's configuration, and the CM records.” [Source: “CM Standards, ANSI/EIA-649-1998 and MIL-STD-973 (1992) Relative to CMII (Rev B)]

This standard supersedes the “MIL-STD-973 Configuration Management” standard.

Federal Standard 1037C
This is known as “Telecommunications: Glossary of Telecommunication Terms” and is in the public domain. It was developed and published by the US government.

The document provides a large base of telecommunication terms and definitions for use by US government and international specialists.

In 2001, this standard was replaced by ANSI T1.523-2001, “Telecom Glossary 2000”.

GEIA Standard 836-2002 Configuration Management Data Exchange and Interoperability
GEIA is an acronym for “Government Electronics & Information Technology Association”.

The standard covers exchange of CM data using XML.

“"EIA-836 facilitates the interoperability and exchange of CM data by clearly delineating CM data elements and their relationships, and by providing the information content of CM data exchanges. The level of interoperability between dissimilar systems is determined by trading partner agreement. The extensible markup language (XML) facilitates data sharing and exchange among different systems. EIA-836 provides a set of standard definitions and business objects that can be used by XML frameworks in interfacing the content elements among one or more systems or databases.

EIA-836 is designed to have wide applicability across vertical industries. The process employed to provide access, sharing or exchange, is typically accomplished using one of many available product data management tools or systems, often customized to a specific organizational environment. To be most effective, the capabilities of the process, tools or systems, should embody the CM principles in ANSI/EIA-649 "National Consensus Standard for Configuration Management;" in conjunction with the business objects and data element definitions in EIA-836.” [Source: GEIA website]

This standard is related to the “ANSI/EIA-649 National Consensus Standard for Configuration Management” standard.

IEEE Std. 828-1998 IEEE Standard for Software Configuration Management Plans.
When designing a Software Configuration Management Plan, this standard sets out the minimum required articles needed as well as what activities need to be completed in each part of the product life cycle.

The following information is from the Swiss Association for Quality:

Project Scope: This standard establishes a required format and set of minimum contents for Software Configuration Management plans. It identifies requirements for configuration identification, configuration control, configuration status accounting and reporting, and configuration audits and reviews. It applies to entire life cycle of critical software. It also applies to non critical software and to software already developed. The application of the standard is not restricted to any form, class or type of software. In addition, it will establish a correlation between the content of software configuration management plans as defined in 828 and the content of such plans as defined in IEEE 12207.1, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data by adding an annex which will correlate the assumptions relating to content of the two documents and trace content between subject documentation.

Project Purpose: To achieve harmonization of the content definition for software life cycle process results among the IEEE software engineering standards and with related international standards.

MIL-STD-973 Configuration Management
This was a US Military standard and superseded MIL-STD-480, -481, -482, -483, -1456 and sections of MIL-STD-1521. The standard set out definitive Configuration Management Tasks for US Military contractors to follow. This standard has been discontinued.

The successor to this standard is the "ANSI/EIA-649, National Consensus Standard for Configuration Management" standard.

The following information is from the Swiss Association for Quality:

Configuration Management Planning, Configuration Management Identification, Configuration Control, Configuration Status Accounting, Configuration Audits

This standard defines configuration management requirements which are to be selectively applied, as required, throughout the life cycle of any configuration item (CI). Configuration management requirements for software have been included. Where requirements are common to both hardware and software items they are shown as requirements for CIs, where are not common, they are shown as requirements for computer software configuration items (CSCIs) or hardware configuration items (HWCIs)

This standard established requirements in the following areas:
 * Configuration management plan
 * configuration identification, configuration
 * control and audits
 * interface control
 * engineering release control
 * configuration managements reports/records.

Contracts invoking this standard will specifically identify the appropriate applicable paragraphs and appendixes or portions thereof as defined in the contract work statement depending upon the scope of the program, and the complexity of the item being procured.

Relationship between testing and version control
Testing starts on each new version and ensures the basic function works well on each version (baseline version or fix version). Incremental published version reduces the workload and pressure on testing. On the incremental version, testing will be only focused on basic function and those changed functions or bug fix. Version control provides an easy and comparable way on test result.

Unit Test
Unit test a testing method running by the developer. The developer should make sure his code would work on the daily build. It tests whether the expected result would be gotten by developer themselves.

Smoke Test
Smoke test also calls sanity test. It is a small scope testing work based on the daily build which the developer provides every day. The test purpose is to verify whether the defect is fixed on this build. And it also tests the basic functions on this build, ensure there is no new defect will be produced.

Regression Test
Regression test starts at when CM publishes a new software version. This version should be stable, integrated some new branches, new function from different component teams. This version build comes from many builds which PASSED in its sanity test.

CMMI Configuration Management
CMMI’s Definition of Configuration Management

''“The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software life cycle. Software Configuration Management involves identifying configuration items for the software project, controlling these configuration items and changes to them, and recording and reporting status and change activity for these configuration items”''

CMMI steps for CM

SEI Capability Maturity Model Integration, Version 1.1 for Systems Engineering and Software Engineering (CMMI-SE/SW, V1.1) lists the following practices as instrumental for a CM capability in an organization :
 * 1) Identify the configuration items, components, and related work products that will be placed under configuration management.
 * 2) Establish and maintain a configuration management and change management system for controlling work products.
 * 3) Create or release baselines for internal use and for delivery to the customer.
 * 4) Track change requests for the configuration items.
 * 5) Control changes in the content of configuration items.
 * 6) Establish and maintain records describing configuration items.
 * 7) Perform configuration audits to maintain the integrity of the configuration baselines.

For further reading visit: SEI Configuration Management

Object-Oriented Software Configuration Management
Object oriented software configuration management is centred around the idea that, most SCM tools are centred around a storage model and forces the user to think of their software - which they normally view as class and objects - in terms of files and folders. In the realm of object oriented SCM tools this represents a disconnect between the concept of the architecture and logical structure of the software and file based SCM elements of the software.

Object Oriented SCM tools therefore treat revisions as changes in the logical structure and relationships between classes and objects, rather than simple file level changes that are tracked by simple tagging and labelling. The Molhado Project is an example of an object oriented SCM toolkit for building object oriented SCM software.

title: Configuration Management/SPM


text:
User talk:Xumium

Welcome
Hello Xumium, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. After you leave a comment on a talk page, remember to sign and date; it helps everyone follow the threads of the discussion. The signature icon in the edit window makes it simple. To get started, you may
 * Take a guided tour and learn to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research activities;
 * Read and help develop our community policies；or
 * Chat with other Wikiversitans on #wikiversity-en.

And don't forget to explore Wikiversity with the links to your left. Be bold, and see you around Wikiversity! Erkan Yilmaz Wikiversity:Chat  18:40, 7 March 2008 (UTC)

title: User talk:Xumium


text:
JCL

Welcome to the learning project on JCL!

The following is a suggested list of headings for a learning project. For more information, please read the directions. Please organise the page as you see fit.

Learning Project Summary

 * Project code:
 * Suggested Prerequisites:
 * Time investment:
 * Assessment suggestions:
 * Portal:(List main portal/s here)
 * School:(List main school/s here)
 * Department:
 * Stream
 * Level:
 * Level:

Content summary
Describe this learning project in a sentence or two.

Goals
This learning project aims to...

Learning materials
Add learning materials here. See also the box below.

Readings and other resources
Each project/lesson/activity may have a suggested reading selection. For example:

 * Wikipedia article:
 * Wikibooks textbook:
 * Etc.

Lessons

 * Lesson 1: /.../
 * Lesson 2: /.../

Activities

 * Activity 1
 * Etc.

Tests and Quizzes

 * Quiz 1
 * Quiz 2
 * Test 1
 * Etc.

Subpages
Subpages can be created - using the syntax '/concepts/' (for concepts involved in this learning project & without the quotes).

Active participants
Active participants in this Learning Group

{| width="100%" style="background:#FFFCCF; border:1px solid #DAA520"

Learning materials
Learning materials and learning projects are located in the main Wikiversity namespace (i.e. without any prefix such as 'Topic:' or 'School:'). Simply make a link to the name of the learning resource, lesson, or learning project (these are independent pages in the main namespace, and sometimes subpages when appropriate) and start writing!

You should also read about the Wikiversity:Learning model. Lessons should center on learning activities for Wikiversity participants. Learning materials and learning projects can be used by multiple projects - and you are encouraged to cooperate with other departments that use the same learning resource.

 * }

[[Category:]] <--please include subject name. By default, this page is included in the category with the same name as this page.

title: JCL


text:
User talk:Cicero Oliveira

Welcome
Hello Cicero Oliveira, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. After you leave a comment on a talk page, remember to sign and date; it helps everyone follow the threads of the discussion. The signature icon in the edit window makes it simple. To get started, you may
 * Take a guided tour and learn to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research activities;
 * Read and help develop our community policies；or
 * Chat with other Wikiversitans on #wikiversity-en.

And don't forget to explore Wikiversity with the links to your left. Be bold, and see you around Wikiversity! Erkan Yilmaz Wikiversity:Chat  21:17, 7 March 2008 (UTC)

title: User talk:Cicero Oliveira


text:
Introduction to Swedish/Adjectives

Grammar
Regular Inflection

for long adjectives following kind of bending is used as an alternative:

Irregular Inflection

Example sentences
Vem är räddast? Who is the most scared? Mia är räddare än Moa. Mia is more scared than Moa. En liten hund är ofta rädd för en stor. A small dog is often scared of a big dog. Den lilla hunden är rädd för den stora. The small dog is scared of the big dog.

Example text
Den första bilen

Kalle skulle köpa sin första bil. Han var inte ute efter en stor familjebil, utan tänkte nöja sig med något litet och smidigt. Han hade sett på TV att det var rea på många bilar nu. Bilhandlaren visade runt bland olika modeller: "Den här störst och den där borta är mest miljövänlig..." "Jag vill ha en grön bil", sa Kalle. "I så fall får det bli den som står längst ner i hörnet!", föreslog bilhandlaren. Kalle betalade och körde iväg med sin nya bil.

The first car

''Kalle was going to buy his first car. He wasn't looking for a big family car as he would be ok with something small and handy. On TV, he had seen that there were sales on many cars now. The car dealer was demonstrating various models: "This is the biggest one, and that one over there is the most environment friendly..." "I would like to have a green car", Kalle said. "In that case you should take the one standing far down in the corner!", the car dealer suggested. Kalle paid and went off with his new car.''

Exercises
Please translate into Swedish

1. The car is red.

2. She is more foolish than I am.

3. He is the cutest boy in the class.

4. It is a nice dog.

5. The big house is smaller than the small church.

Please translate into English

6. Den långa tjejen är vackrast i skolan.

7. Betala till den stora killen i hörnet!

8. Han är vackrare nu än då.

9. Hon är ute efter en lång kille.

10. Jag föreslår att du nöjer dig med en bilhandlare.

../Answers to exercises/

title: Introduction to Swedish/Adjectives


text:
Biogeochemical Selectiveness of Cedars Over Metamorphic Rocks of the Escambray Complex, Sancti Spíritus, Cuba

 * /Cover/
 * /Licensing/

Table of Contents

 * /Abstract/
 * /Introduction/
 * /Study Area/
 * /Vegetation/
 * /Conclusions/
 * /Acknowledgement/
 * /References/
 * /List of Tables/


text:
Biogeochemical Selectiveness of Cedars Over Metamorphic Rocks of the Escambray Complex, Sancti Spíritus, Cuba/Cover

BIOGEOCHEMICAL SELECTIVENESS OF CEDARS OVER METAMORPHIC ROCKS OF THE ESCAMBRAY COMPLEX, SANCTI SPIRITUS, CUBA.

Ricardo A. Valls Alvarez Valls Geoconsultant

Special Edition for Wikibooks January 23rd, 2008