Hva er LMS, og når trenger virksomheten et slikt system?

Et LMS er ikke en mappe med presentasjoner og en liste i et regneark. Når påmelding, gjennomføring og gyldighetstid skal dokumenteres, begynner systemet å lønne seg — og ellers er det en dyr ekstradel.

Tenk deg en delt mappe med sju presentasjoner, to videoer og en instruks som heter «endelig_versjon_2_rettet.pdf», og ved siden av den et regneark der HR-rådgiveren krysser av for hvem som har sett hva; hva er LMS godt for i en slik situasjon? Så lenge bedriften har tjue ansatte og kurset er ett, fungerer ordningen helt greit og koster ingenting, og derfor har ingen hastverk med å endre den. Den bryter sammen først den dagen noen spør om akkurat den personen faktisk fikk den årlige repetisjonen i fjor, og det eneste svaret du har, er en rad i et regneark som ingen kan bekrefte og hvem som helst kunne ha skrevet over. En læringsplattform, eller et LMS, er programvare med én alvorlig oppgave: å gjøre den raden om til en oppføring som har opphav, dato og forfatter.

Hva er LMS, og hva blir det oftest forvekslet med

En læringsplattform gjør fire ting: den melder folk på kurs, leverer innholdet, kontrollerer at det er tilegnet, og lagrer oppføringen om hva som skjedde. Den første og den fjerde er grunnene til at systemet faktisk blir kjøpt, mens den andre og den tredje er de man snakker om i demoene, fordi de er lettere å vise fram på en skjerm. Tar du oppføringen ut av denne listen, sitter du igjen med et fillager med et penere grensesnitt, og av dem har virksomheten din etter alt å dømme minst to fra før.

Nettopp derfor er et LMS verken en videoplattform, et webinarverktøy eller en markedsplass for kurs, selv om alle tre viser læringsmateriell like godt eller bedre. Videoplattformen vet at filen ble spilt av; den vet ikke at den ble spilt av en person som skulle ha gjennomført akkurat det kurset innen en bestemt dato, at det skjedde på andre forsøk, og at det hele må tas om igjen om ett år. Forskjellen ligger ikke i funksjonslisten man sammenligner i et anbudsskjema, men i spørsmålet systemet klarer å svare på om to år, når ingen av dem som var med fra begynnelsen, jobber i virksomheten lenger.

Ordet «plattform» villeder mer enn det hjelper her, for det brukes både om systemer som fører opp plikter og om systemer som tilbyr fritt valgt innhold, og begge deler selges av de samme folkene. Den praktiske delelinjen er likevel enkel, og den holder i alle tilfeller: bestemmer noen andre hva du skal lære, og kontrollerer noen at du gjorde det, er det en læringsplattform. Velger du selv, og følger ingen med, er det et bibliotek. Begge kan være nyttige samtidig, men bare den første svarer på spørsmålet fra en revisor, og det er nettopp det spørsmålet som pleier å ende i et prosjekt.

Etterspørselen etter en slik oppføring er verken norsk eller ny, og den er ikke liten: i første kvartal 2025 hadde 16 % av innbyggerne i EU mellom 16 og 74 år tatt et nettkurs i løpet av de tre foregående månedene, ifølge tall fra Eurostat, så selve det å lære foran en skjerm overrasker ingen lenger. Det som overrasker, er hvor sjelden en virksomhet klarer å si hvilket av disse kursene som var obligatorisk, hvilket som ble fullført, og hvor lenge resultatet er gyldig — for det er nettopp de tre spørsmålene systemet løser, og nettopp dem ingen stiller før den første kontrollen.

Når det virkelig trengs: dokumentasjon, ikke bekvemmelighet

De fleste virksomheter havner hos en læringsplattform ikke fordi opplæringen er blitt vanskeligere, men fordi det er blitt dyrt å dokumentere den. Arbeidsmiljøloven § 3-2 krever at arbeidstakeren gjøres kjent med ulykkes- og helsefarer i arbeidet og får «den opplæring, øvelse og instruksjon som er nødvendig», uten å sette noe fast intervall for gjentakelse. Der risikoen er høy, setter myndigheten rytmen i stedet: DSBs veiledning til forskriften om sikkerhet ved arbeid i og drift av elektriske anlegg regner kravet som oppfylt «dersom dette gjentas en gang årlig», og slår fast at det ikke skal gå mer enn tolv måneder mellom hver opplæring. Så lenge folkene er få og fristen er én, holder du dette i hodet eller i kalenderen; med to hundre ansatte og ulike startdatoer blir det en oppgave der feil ikke lenger er mulig, men uunngåelig.

EUs rammedirektiv om arbeidsmiljø, 89/391/EØF, gjelder også her gjennom EØS-avtalen og er i hovedsak gjennomført i arbeidsmiljøloven med forskrifter. Det krever opplæring ikke bare ved ansettelse, men også ved omplassering eller endrede arbeidsoppgaver, ved innføring av nytt arbeidsutstyr og ved endring av teknologien. Hver av disse hendelsene skaper en ny frist for en ny gruppe mennesker, og det er denne kombinatorikken, ikke innholdet i kursene, som begynner å kreve et system — fristene faller ikke sammen, gruppene overlapper, og ingen av dem starter 1. januar. I regulerte yrker ligger terskelen enda lavere: en statsautorisert revisor skal etter revisorloven § 5-1 gjennomføre minst 120 timer relevant etterutdanning i løpet av de tre foregående kalenderårene, minst 90 av dem som strukturert opplæring, og Finanstilsynet venter en samlet kronologisk oversikt over timene — noen må altså telle dem og kunne legge dem fram.

Hvor utbredt behovet er, sier også noe om størrelsen: i 2020 tilbød 67,4 % av virksomhetene i EU med ti eller flere ansatte etter- og videreutdanning til de ansatte, ifølge Eurostat, altså snakker vi ikke om et sjeldent tilfelle, men om flertallet; spørsmålet er bare hvordan hver enkelt av dem fører det opp. Derfor lyder den ærlige grunnen til å innføre et LMS som regel lite romantisk: du trenger å vite hvem som er lært opp, når det skjedde, hvor lenge det er gyldig, og hva som skjer neste kvartal — og du trenger å vite det uten å ringe en kollega som akkurat da har ferie. Finnes ikke det spørsmålet, og kommer ingen til å stille det med det første, løser systemet et problem du ikke har, og det er den eneste typen prosjekt som ikke lar seg redde med en god innføring.

Når det ikke trengs, og hvorfor det sjelden blir sagt

Internkontrollforskriften § 5 sier at internkontrollen «skal dokumenteres i den form og det omfang som er nødvendig på bakgrunn av virksomhetens art, aktiviteter, risikoforhold og størrelse», og den formuleringen er viktigere enn den ser ut. Regelverket krever en oppføring, ikke programvare, og en signaturliste med dato er en fullverdig oppføring som står seg i en kontroll akkurat like godt som et skjermbilde fra et system. For femten personer, ett kurs og én frist i året legger en læringsplattform til vedlikehold, versjonsoppdateringer og enda et sted å logge seg inn, men den legger ikke til et eneste svar du manglet fra før.

Vi anbefaler heller ikke en læringsplattform når virksomheten ennå ikke har innhold, og det er det vanligste tilfellet der prosjektet bør utsettes. Et tomt system er ingen investering i framtiden, men en utgift som venter på at noen skal finne tid til å skrive kursene — og den tiden pleier ikke å dukke opp etter lansering, like lite som den gjorde før. Det er billigere og raskere å skrive tre kurs i tekst og video først, spre dem slik du klarer i dag, se hvilke av dem folk faktisk bruker, og først deretter kjøpe et sted å legge dem. Gjort i motsatt rekkefølge ender prosjektet oftere med en plattform som har to kurs og ingen faste brukere.

Det tredje tilfellet der svaret er nei, er når det egentlige behovet ikke er opplæring, men svar. Leter de ansatte ikke etter et kurs, men etter et bestemt punkt i et internt dokument — hvordan de skal håndtere en konkret kundesak, hva prosedyren er i en gitt situasjon — løser ikke en læringsplattform det, for den er bygd for sekvensiell gjennomgang med en prøve til slutt, ikke for et raskt oppslag midt i arbeidet. Da hjelper søk i bedriftens egne dokumenter bedre, noe vi har skrevet om separat i artikkelen om RAG-løsninger for bedriftsdokumenter — de to systemene ser forvirrende like ut i en demo, fordi begge har søk og begge har virksomhetens eget innhold, men de løser helt ulike problemer og erstatter derfor sjelden hverandre.

Hva systemet faktisk fører opp

Oppføringen er stedet der læringsplattformer skiller seg mest fra hverandre, og samtidig det man ser minst på i demoene, fordi det ser kjedelig ut. Påmeldingen svarer på hvem kurset gjaldt for; gjennomføringen svarer på hvor langt personen kom; fullføringen bekrefter at vilkårene ble oppfylt; gyldighetstiden sier hvor lenge alt dette står seg. Den fjerde mangler oftest i de billige systemene, og det er nettopp den du kommer til å trenge hver dag, for på den hviler både påminnelsene, resertifiseringen og rapporten til ledelsen.

I praksis betyr det at systemet må klare å skille «så videoen» fra «besto prøven», og begge fra «gyldig til», og klare det i én visning framfor i tre rapporter. Lagrer det bare det første, er det en aktivitetslogg og ikke et kompetanseregister, og i en kontroll dokumenterer det ikke annet enn at en fil ble åpnet. Be om å få se en konkret person i demoen — én med ett kurs bestått, ett forfalt og ett der gyldigheten er gått ut — og se etter hvor lett det er å skille de tre tilstandene fra hverandre uten en forklaring ved siden av.

Den andre delen som ofte misforstås, er at en læringsplattform ikke er et personalsystem og aldri kommer til å bli det. Den vet om kurs og resultater, mens stilling, avdeling og ansettelsesdato kommer fra et annet sted, og det er nettopp den integrasjonen som avgjør om påmeldingen skjer automatisk eller for hånd. Må en nyansatt meldes på kursene manuelt, er systemet ikke innført ferdig — da har det bare flyttet det samme arbeidet fra regnearket til et nyere grensesnitt, og om et år spør noen igjen hvorfor listene ikke stemmer.

Oppføringen har også en side man tenker sjeldnere på: dataene oppstår gjerne utenfor selve systemet. Foregår deler av opplæringen i et eksternt verktøy — en simulator, en språkplattform, produsentens eget kursmiljø — er spørsmålet om resultatet derfra kommer tilbake til oppføringen din automatisk, eller om noen skriver det inn for hånd. Det er nettopp det LTI finnes for: standarden kobler et eksternt verktøy inn uten egen innlogging og henter vurderingen tilbake, og i Moodle heter aktiviteten på norsk rett og slett Eksternt verktøy. Derfor er det verdt å be om mer enn navnet på standarden i en anskaffelse, nemlig hvilke deler av den leverandøren har innført, og hvordan det er testet.

Standardene som avgjør om du kan gå

Spørsmålet som ser teknisk ut i starten av prosjektet og viser seg å være kommersielt tre år senere, er dette: hvem eier innholdet og oppføringene hvis du bestemmer deg for å bytte plattform. Svaret ligger ikke i et kontraktspunkt om utlevering av data, men i formatene innholdet og oppføringene faktisk lagres i. SCORM er det eldste av dem og fortsatt den mest utbredte måten å pakke et kurs på slik at det kan legges inn i et annet system; xAPI er et nyere lag som ikke beskriver en pakke, men hendelser — hvem som gjorde hva, med hvilket resultat — og lagrer dem i et eget lager som kalles LRS, en learning record store.

Her ligger det en nyanse du ikke finner i salgspresentasjonene, og som de siste årene har endret hele måten spørsmålet står på: ADL Initiative — programmet i det amerikanske forsvarsdepartementet som skapte SCORM og publiserte xAPI — er lagt ned, og GitHub-organisasjonen deres, som GitHub har bekreftet som eier av adlnet.gov, opplyser: «The ADL Initiative has been shut down.» Det betyr ikke at SCORM plutselig slutter å virke, for formatet er publisert og systemene leser det videre, men det betyr at det ikke lenger står en aktiv forvalter bak merkenavnet. Datamodellen som SCORM-kjøretiden hviler på, er og blir likevel en IEEE-standard: IEEE 1484.11.1-2022 er gjeldende og ble publisert 15. april 2022.

xAPI har gått motsatt vei: den er standardisert som IEEE 9274.1.1-2023 og publisert 6. oktober 2023, altså finnes det en forvalter, og oppføringer laget i dette formatet er lesbare også om produktet skiftes ut. Den tredje standarden det er verdt å be om ved navn, er LTI, som kobler et eksternt verktøy inn uten egen innlogging, og 1EdTech avsluttet støtten for alle versjoner før LTI 1.3 etter 30. juni 2021 — svaret «vi støtter LTI» uten et versjonsnummer er derfor ikke lenger et svar. Til flytting av et helt kurs finnes Common Cartridge, og nettopp den er det verdt å be om en demonstrasjon av framfor å diskutere.

Hvorfor «støtter standarden» ikke er det samme som «virker»

Navnet på en standard i en spesifikasjon og standardens oppførsel i et konkret system er to forskjellige ting, og det beste eksempelet ligger offentlig i Moodles egen dokumentasjon, altså kontrollerbart uten hjelp fra noen leverandør. Der står det at Moodle støtter SCORM 1.2 og består ADLs samsvarstester for den, men at Moodle ikke støtter SCORM 2004. Et høyere versjonsnummer betyr her ikke bedre støtte — det betyr ingenting før det er kontrollert — og en leverandør som ikke sier dette, enten vet det ikke eller regner med at du ikke sjekker.

Av dette følger en praktisk prøve som ikke koster noe, tar omtrent en time og sier mer enn noen referanse: ta ett ekte kurs i det formatet innholdet ditt allerede finnes i i dag, og be om å få det lastet opp i et testmiljø under demoen, ikke etter at kontrakten er signert. Er svaret at det gjøres i løpet av innføringen, har du allerede fått svaret, og det er den billigste informasjonen du kommer til å skaffe deg i hele prosjektet. Det samme gjelder eksporten: be om å få kurset ut igjen og lagt inn i et annet system, for nettopp den operasjonen kommer til å trengs i hastverk en gang.

Påstandene fra leverandøren om samspill kan også kontrolleres helt uavhengig av leverandøren selv. 1EdTech vedlikeholder den offentlige oversikten TrustEd Apps over produkter som har bestått sertifiseringen, og sier tydelig at et produkt som ikke står der, enten ikke har bestått den eller har en sertifisering som er utløpt. Fem minutter i den oversikten sier mer enn femti lysbilder, og det er praktisk talt den eneste kilden på dette feltet som ikke er publisert av selgeren selv. Står ikke produktet der, er det ennå ikke et forbud mot å kjøpe, men et spørsmål det er verdt å få svar på skriftlig.

Den samme forsiktigheten gjelder versjonsnumre, som gjerne leses som et kvalitetsmål. LTI 2.0 ser etter tallet nyere ut enn 1.3, men 1EdTech fører den opp nettopp blant de tidligere versjonene støtten ble avsluttet for, og et tilbud der dette nummeret er nevnt som en fordel, lover i praksis en foreldet forbindelsesmåte som ingen vedlikeholder lenger. Mangler versjonsnummeret helt i tilbudet, er det verdt å be om det skriftlig, for dette er én linje som senere avgjør om integrasjonen mot det neste verktøyet tar en time eller blir et eget prosjekt.

LMS og LXP: hva er forskjellen

I samtaler om læringssystemer dukker forkortelsen LXP før eller siden opp, og den fortjener en forklaring, for den veier mindre enn den høres ut som. Et LMS går ut fra at virksomheten bestemmer hva hver enkelt skal lære, og fører opp gjennomføringen; LXP betegner en tilnærming der den som lærer, velger innholdet selv mens systemet anbefaler, og tyngdepunktet flyttes fra plikt til interesse. Som en forskjell i vektlegging er den ekte og av og til nyttig — ved frivillig kompetanseheving er plikthåndtering virkelig ikke hovedsaken, og en liste over påtvungne kurs står heller i veien der.

Det forskjellen ikke har, er en standardiseringsorganisasjon eller en teknisk grense noen kunne kontrollere. Begrepet ble lansert offentlig i september 2018 av HR-teknologianalytikeren Josh Bersin som hans eget påfunn, og siden da har det først og fremst blitt brukt til å dele opp markedet. Praktisk betyr det at to produkter med samme merkelapp kan være like ulike som hvilke som helst to produkter uten den, og at en sammenligning etter kategorinavn ikke sier noe om hva du får — i anbudsskjemaet blir denne kolonnen dermed en tom rubrikk med en overskrift som gir en følelse av trygghet, uten å uttrykke et eneste kontrollerbart krav.

Det er verdt å sammenligne etter det som blir liggende i databasen når demoen er over. Oppføringslaget begge kategoriene viser til, er standardisert — xAPI er IEEE 9274.1.1-2023 — og nettopp det avgjør om du om tre år kan si hva folk lærte, også dersom produktet da er et annet. Nevner leverandøren kategorinavnet oftere enn formatet oppføringene skal lagres og hentes ut i, handler samtalen om markedsføring, og det er verdt å si høyt allerede i møtet.

Praktisk kontrollerer du dette med to spørsmål som kan stilles i hvilken som helst demo. Det første: hva bestemmer at en gitt person skal gjennomføre et gitt kurs innen en gitt dato, og hvor er den beslutningen synlig i systemet. Det andre: i hvilket format lagres oppfyllelsen av denne plikten, og hvordan hentes den ut igjen dersom produktet byttes. Er svaret på det første at systemet anbefaler, men ikke pålegger, sitter du — uansett hva kategorien heter — med et bibliotek, og plikthåndteringen må løses et annet sted.

Der læringsplattformen slutter og et annet system begynner

Grensen som oftest blir overtrådt i slike prosjekter, går mellom læringsplattformen og det studieadministrative systemet eller personalsystemet. Den første forvalter kurs, det andre forvalter mennesker: opptak, kontrakter, grupper, stillinger og status. Man kan legge inn en liste over personer i læringsplattformen, og derfor oppstår fristelsen til å bruke den som register også — og nettopp den fristelsen skaper en situasjon der to ulike versjoner av sannheten om hvem som fortsatt er ansatt, og i hvilken avdeling, lever side om side.

Det praktiske prinsippet er ett, og det er enkelt: et menneske opprettes der mennesket opprettes i virksomheten, og i læringsplattformen kommer det bare inn. Ligger de ansatte i personalsystemet, kommer påmeldingen til kursene derfra, mens læringsplattformen leverer resultatet og fristen tilbake. Er ikke denne flyten definert allerede i kravene, blir den nesten alltid løst med et månedlig regneark som noen setter sammen for hånd — og det er akkurat det samme regnearket som hele prosjektet startet med.

Det samme gjelder kursbevis og dokumenthåndtering: læringsplattformen kan utstede et bevis for bestått kurs, men den er ikke et arkivsystem, og langtidsbevaring med rettslig betydning hører som regel hjemme der kontraktene og vedtakene allerede ligger. Derfor trekkes grensen mellom de to systemene i starten av prosjektet, ikke den dagen noen krever den for første gang. Gjøres det i tide, blir listen over integrasjoner kortere og billigere; gjøres det ikke, dukker det opp et krav om et år som ingen har planlagt, og som budsjettet allerede er brukt opp på.

Av dette følger også hvordan rapportene bør vurderes, de som i en anskaffelse gjerne står aller sist. En rapport er bare nyttig hvis den svarer på et spørsmål noen faktisk kommer til å stille — hvor mange i denne avdelingen som har oversittet den obligatoriske opplæringen, og når gyldigheten går ut for hver av dem — og ikke på hvor mange kurs som ble åpnet denne måneden. Får systemet personalstrukturen fra personalregisteret, er en slik rapport én spørring; får det den ikke, er den et regneark noen setter sammen for hånd hver måned av to uttrekk.

Moodle som eksempel, ikke som anbefaling

Når samtalen kommer til konkrete produkter, er Moodle nesten alltid navnet som faller først så snart noen sier «åpen kildekode», og derfor er det verdt å slå fast hva det faktisk er før meningene begynner. Moodle er en læringsplattform som utvikles og vedlikeholdes av Moodle Pty Ltd, og den er fritt tilgjengelig under GPL-lisensen. Det betyr at kildekoden er åpen og at selve programvaren ikke koster noe, men det betyr ikke at alt rundt den er fritt å bruke: GPL gjelder koden, mens navnet Moodle og logoene er varemerker som krever skriftlig forhåndssamtykke fra eieren for kommersiell bruk.

For den praktiske beslutningen betyr vedlikeholdsrytmen mer enn lisensen, for det er den som avgjør budsjettet de neste årene. Moodle publiserer en utgivelseskalender med to store versjoner i året — i april og i oktober — og vedlikeholdsutgivelser annenhver måned; hver store versjon får tolv måneders generell støtte, en vanlig utgivelse sikkerhetsrettinger i inntil atten måneder, mens en LTS-utgivelse får inntil trettiseks. Etter denne kalenderen planlegger du penger og folk, for en versjon som har mistet støtten, er ikke lenger et spørsmål om smak, men om sikkerhet, og det pleier å komme på et ubeleilig tidspunkt.

Det finnes også krav som treffer infrastrukturen, og som er verdt å kontrollere før noen lover noe: Moodle 5.2 krever minst PHP 8.3.0 og én av PostgreSQL 16, MySQL 8.4, MariaDB 10.11.0 eller Microsoft SQL Server 2019. Og én ting til bør du vite før du leser imponerende utbredelsestall: statistikken som publiseres på moodle.org, kommer fra nettsteder som har registrert seg frivillig, og viser derfor størrelsen på fellesskapet, ikke en målt markedsandel. Ved siden av dette finnes Moodle Workplace, som bare er tilgjengelig gjennom sertifiserte partnere, og det er et annet produkt med en annen anskaffelsesvei.

Ingenting av dette skal oppfattes som en anbefaling om å velge nettopp dette systemet, for det riktige svaret avhenger av hvor mange mennesker, hvor mange kurs og hvor mange frister du faktisk har. Moodle står her som eksempel fordi det er åpent og dokumentasjonen er offentlig, altså kan hver eneste påstand om det kontrolleres uten mellomledd — og det er den egenskapen man måler enhver kandidat mot, også et lukket produkt med dokumentasjonen gjemt bak et innloggingsskjema.

Det som koster mer enn lisensen

Er lisensen gratis, går budsjettet et annet sted, og det er langt bedre å se det før prosjektet enn midt i det. Den største posten er nesten alltid innholdet: å lage kursene, spille inn video, sette opp prøvene og vedlikeholde det samme innholdet senere, når prosedyrene eller regelverket endrer seg. Den nest største er migrering, dersom noe allerede finnes — gamle Moodle-versjoner, kurs i et annet system, deltakerhistorikk som må tas vare på fordi fristene fortsatt løper og dokumentasjonen for dem fortsatt trengs.

Den tredje posten er integrasjoner og innlogging, og her skiller kravene her i landet seg fra generelle lister: pålogging med Feide, den nasjonale innloggingsløsningen for utdanning og forskning som Sikt drifter, og som nevner nettopp læringsplattformer blant tjenestene den er laget for, eller ID-porten og BankID der brukerne ikke hører til utdanningssektoren — i tillegg til kobling mot det studieadministrative systemet eller personalsystemet og felles pålogging for hele virksomheten. Den fjerde posten, den man ser sjeldnest i planene, er vedlikeholdet etter lansering: versjonsoppdateringer etter kalenderen over, sikkerhetskopiering, brukerstøtte og en liten, men uavbrutt strøm av endringer. Om hvordan vi regner på slike prosjekter og i hvilken rekkefølge vi gjør dem, har vi skrevet separat på siden om utvikling og vedlikehold av Moodle LMS.

Før en samtale med hvilken som helst leverandør er det verdt å lese det vi har samlet i artikkelen om de vanligste feilene når du bestiller utvikling, for i prosjekter med læringssystemer gjentar de seg nesten uendret: uklart omfang, ukontrollert eksport og en antakelse om at innholdet blir til av seg selv. Vil du at noen leser situasjonen din og sier om et system i det hele tatt er riktig svar her, kan du skrive til oss — av og til er det ærligste svaret at det du allerede har, holder, og at pengene er bedre brukt på innhold enn på plattform.

Den femte posten, som det er verdt å kontrollere særskilt i et norsk miljø, er språket. Moodle-fellesskapet har oversatt systemet til mer enn 120 språk, men hvor fullstendig oversettelsen er, varierer fra språk til språk, og det er offentlig synlig i Moodles eget oversettelsesmiljø, altså kontrollerbart før beslutningen. For norsk kommer det i tillegg at systemet føres opp i mer enn én variant — bokmål og nynorsk hver for seg — og at de to ikke er like komplette. I praksis betyr det at enkelte sjeldnere brukte skjermbilder kan stå på engelsk selv når grensesnittet ellers er norsk, og at valget mellom en fullstendig oversettelse og mangelen på en er ditt, ikke en tilfeldighet — men bare hvis du kontrollerer det i tide.