Fix non UTF-8 encoding using "iconv -f latin1"

CVS version numbers

norwegian/Bugs/Access.wml: 1.8 -> 1.9 
norwegian/Bugs/Developer.wml: 1.11 -> 1.12 
norwegian/Bugs/otherpages.inc: 1.1 -> 1.2

3 files changed, 197 insertions, 197 deletions

diff --git a/norwegian/Bugs/Access.wml b/norwegian/Bugs/Access.wml
index 28ba0261e48..233795217d4 100644
--- a/norwegian/Bugs/Access.wml
+++ b/norwegian/Bugs/Access.wml
@@ -1,4 +1,4 @@
-#use wml::debian::template title="Debians feilrapportsystem – adgangsmåter" NOHEADER=yes NOCOPYRIGHT=true
+#use wml::debian::template title="Debians feilrapportsystem Рadgangsm̴ter" NOHEADER=yes NOCOPYRIGHT=true
 #use wml::debian::translation-check translation="1.20"
 # Oversatt til norsk av Tollef Fog Heen
 # Oppdatert av Peter Karlsson <peterk@debian.org>
@@ -9,19 +9,19 @@
 
   <p>
     Hver melding mottatt av eller sendt fra feilrapporteringssystemet
-    blir logget og gjort tilgjengelig på flere måter.</p>
+    blir logget og gjort tilgjengelig på flere måter.</p>
 
   <p>
-    Hovedmåten å se på feilrapportene er å via nettsidene.  Se
+    Hovedmåten å se på feilrapportene er å via nettsidene.  Se
     skjemaene hos <a href="./">feilrapportsystemets hovedside</a>
     hos <code>http://bugs.debian.org/</code>.</p>
 
   <p>
     En <a href="server-request">eposttjener</a> kan sende
-    feilrapporter som ren tekst etter forespørsel.  For å bruke den,
+    feilrapporter som ren tekst etter forespørsel.  For å bruke den,
     send en epost med ordet <code>help</code> som eneste innhold til
     <code>request@bugs.debian.org</code> (tittelfeltet i eposten blir
-    ignorert), eller les instruksjonene på
+    ignorert), eller les instruksjonene på
     <a href="server-request">World Wide Web</a> eller i filen
     <code>bug-log-mailserver.txt</code>.</p>
 
@@ -30,12 +30,12 @@
   <p>
     Hver lukket feilrapport er arkivert 28 dager etter at den siste
     meldingen til den er mottatt og lagret.  Dette betyr at det ikke
-    lenger er mulig å få adgang til den ved hjelp av
+    lenger er mulig å få adgang til den ved hjelp av
     <code>control</code>- og <code>service</code>-robotene.
     Imidlertid er rapportene fortsatt tilgjengelig for gjensyn.</p>
 
   <p>
-    Du kan søke gjennom feilrapport-arkivet ved hjelp av
+    Du kan søke gjennom feilrapport-arkivet ved hjelp av
     <a href="./">nettskjemaer</a> hos
     <code>http://bugs.debian.org</code>. Velg "lukkede
     feilrapporter".</p>
@@ -46,10 +46,10 @@
 
 # FIXME: Sjekkes (peterk), hele denne delen
 
-<h2>Adgang til rå feildata</h2>
+<h2>Adgang til rå feildata</h2>
 
 <p>
-Om du vil få tak i den rådata som brukes av feilrapportsystemet kan du
+Om du vil få tak i den rådata som brukes av feilrapportsystemet kan du
 speile den med rsync fra bugs-mirror.debian.org.
 De relevante modulene er bts-spool-db (for den aktive feildatabasen),
 bts-spool-archive (for feilrapporter som har blitt stengt og dermed er
@@ -57,14 +57,14 @@ arkivert), og bts-spool-index (for feilindeksfilene).
 </p>
 
 <p>
-Når dette skrives er den aktive databasen omkring 2,5GB og den arkiverte
-databasen omkring 10GB. Hvis du kun trenger et eksempel for testbruk bør du
-overveie å kun laste ned en del av den aktive databasen framfor alt sammen.
+NÃ¥r dette skrives er den aktive databasen omkring 2,5GB og den arkiverte
+databasen omkring 10GB. Hvis du kun trenger et eksempel for testbruk bør du
+overveie å kun laste ned en del av den aktive databasen framfor alt sammen.
 </p>
 
 <p>
-Vi ber deg ikke tro på *.status-filene i feildatabasen, siden disse ikke
-lenger er i bruk, kun er med av kompatibilitetshensyn, og kommer til å bli
+Vi ber deg ikke tro på *.status-filene i feildatabasen, siden disse ikke
+lenger er i bruk, kun er med av kompatibilitetshensyn, og kommer til å bli
 fjernet en gang i framtiden.
 Bruk *.summary-filene isteden.
 </p>
diff --git a/norwegian/Bugs/Developer.wml b/norwegian/Bugs/Developer.wml
index a15aa32d1c7..8e38be8a458 100644
--- a/norwegian/Bugs/Developer.wml
+++ b/norwegian/Bugs/Developer.wml
@@ -7,35 +7,35 @@
   <h1>Utviklerinformasjon om feilrapportsystemet</h1>
 
   <p>
-    Feilrapporter blir først sendt som en vanlig e-post til
-    <code>submit@bugs.debian.org</code>.  Rapporten får deretter et
+    Feilrapporter blir først sendt som en vanlig e-post til
+    <code>submit@bugs.debian.org</code>.  Rapporten får deretter et
     nummer, en kvittering blir sendt til innsenderen og rapporten blir
     videresendt til <code>debian-bugs-dist</code>.  Hvis innsenderen
     inkluderte en <code>Package</code>-linje, og utvikleren for pakken
-    er kjent så sendes det en kopi til utvikleren også.</p>
+    er kjent så sendes det en kopi til utvikleren også.</p>
 
   <p>
-    <code>Subject</code>-feltet vil få lagt til
+    <code>Subject</code>-feltet vil få lagt til
     <code>Bug#</code><var>nnn</var><code>:</code> og
-    <code>Reply-To</code> settes slik at den inkluderer både
+    <code>Reply-To</code> settes slik at den inkluderer både
     innsenderen og <var>nnn</var><code>@bugs.debian.org</code>.</p>
 
   <hrline />
 
   <ul>
     <li><a href="#closing">Lukke feilrapporter</a></li>
-    <li><a href="#followup">Oppfølgingsmeldinger</a></li>
+    <li><a href="#followup">Oppfølgingsmeldinger</a></li>
     <li><a href="#severities">Alvorlighetsgrader</a></li>
     <li><a href="#tags">Merkelapper for feilrapporter</a></li>
     <li><a href="#forward">Informere om at du har videresendt en
 	feilrapport</a></li>
-    <li><a href="#owner">Endre eierskap på feilrapporter</a></li>
+    <li><a href="#owner">Endre eierskap på feilrapporter</a></li>
     <li><a href="#maintincorrect">Feilangitte pakkeutviklere</a></li>
-    <li><a href="#requestserv">Gjenåpne, tildele og endre på
+    <li><a href="#requestserv">Gjenåpne, tildele og endre på
 	feilrapporter</a></li> 
-    <li><a href="#subscribe">Abonner på feilrapporter</a></li>
+    <li><a href="#subscribe">Abonner på feilrapporter</a></li>
     <li><a href="#subjectscan">Mer eller mindre avlegs
-	tittelfeltsøk</a></li> 
+	tittelfeltsøk</a></li> 
     <li><a href="#x-debian-pr">Avlegs <code>X-Debian-PR:
 	  quiet</code>-egenskap</a></li> 
   </ul>
@@ -45,9 +45,9 @@
   <h2><a name="closing">Lukke feilrapporter</a></h2>
 
   <p>
-    Debians feilrapporter skal lukkes når feilen er rettet. Problemer
+    Debians feilrapporter skal lukkes når feilen er rettet. Problemer
     i pakkene kan kun anses som rettet etter at en pakke som innholder
-    rettelsen på feilen er lastet inn i Debian-arkivet.</p>
+    rettelsen på feilen er lastet inn i Debian-arkivet.</p>
 
   <p>
     Vanligvis er de eneste personene som kan lukke en feilrapport
@@ -55,17 +55,17 @@
     rapporten var sendt inn mot. Det finnes unntak til denne regelen,
     eksempelvis for feilrapporter som er sendt inn mot ukjente pakker eller
     visse generelle pseudo-pakker. Hvis du er i tvil, ikke lukk
-    feilrapporter uten å spørre om råd i e-postlisten debian-devel.</p>
+    feilrapporter uten å spørre om råd i e-postlisten debian-devel.</p>
 
   <p>
-    Feilrapporter lukkes ved å sende en e-post til
+    Feilrapporter lukkes ved å sende en e-post til
     <var>nnn</var><code>-done@bugs.debian.org</code>. Kroppen av
-    meldingen må inneholde en forklaring av hvordan feilen ble fikset.
+    meldingen må inneholde en forklaring av hvordan feilen ble fikset.
   </p>
 
   <p>
     Med en e-postene du har mottatt fra feilrapportsystemet er alt du
-    trenger å gjøre for å lukke en feilrapport å svare på meldingen i
+    trenger å gjøre for å lukke en feilrapport å svare på meldingen i
     e-postleseren din, og endre <code>To</code>- eller
     <code>Til</code>-feltet til 
     <var>nnn</var><code>-done@bugs.debian.org</code> i stedet for
@@ -75,48 +75,48 @@
 
   <p>Der det er anvendelig vennligst angi en <code>Version</code>-linje i 
     <a href="#Reporting#pseudoheader">pseudo-headeren</a> av din melding
-    når du lukker en feilrapport. Slik vet feilrapportsystemet hvilken 
+    når du lukker en feilrapport. Slik vet feilrapportsystemet hvilken 
     utgivelse av pakken som inneholder en rettelse av feilen.</p>
 
   <p>
     Personen som lukker feilrapporten, den som sendte den inn, og
-    e-postlisten <code>debian-bugs-closed</code> vil hver få en melding om
+    e-postlisten <code>debian-bugs-closed</code> vil hver få en melding om
     endring av status i feilrapporten. Innsenderen og e-postlisten
-    vil også motta innholdet av meldingen som ble sendt til
+    vil også motta innholdet av meldingen som ble sendt til
     <var>nnn</var><code>-done</code>.</p>
 
 
-  <h2><a name="followup">Oppfølgingsmeldinger</a></h2>
+  <h2><a name="followup">Oppfølgingsmeldinger</a></h2>
 
   <p>
     Feilrapportsystemet vil inkludere innsenderen's adresse og
     feilrapportsadressen
     (<var>nnn</var><code>@bugs.debian.org</code>) i
-    <code>Reply-To</code>-feltet når feilrapporten videresendes til
+    <code>Reply-To</code>-feltet når feilrapporten videresendes til
     pakkeutvikleren. Merk at disse er to adskilte adresser.</p>
 
   <p>
-    Om en utvikler ønsker å svare på en feilmelding kan de rett og
-    slett svare på e-posten i samsvar med <code>Reply-To</code>-feltet.
+    Om en utvikler ønsker å svare på en feilmelding kan de rett og
+    slett svare på e-posten i samsvar med <code>Reply-To</code>-feltet.
     Dette vil <strong>ikke</strong> markere feilrapporten som lukket.</p>
 
   <p>
-    Feilrapportsystemet tar i mot meldingen på
+    Feilrapportsystemet tar i mot meldingen på
     <var>nnn</var><code>@bugs</code>, videresender den til
     pakkeutvikleren, arkivere svaret sammen med resten av loggene for
     den feilrapporten, og sende dette sammendraget til
     <code>debian-bugs-dist</code>.</p>
 
   <p>
-    Ved å sende en melding til 
+    Ved å sende en melding til 
     <var>nnn</var><code>submitter@bugs.debian.org</code> vil 
     kun sendte en e-post til innsenderen av feilrapportern, og
     plassere en kopi i feilrapportsystemet. Meldingen vil ikke 
     bli sendt til pakkeutvikleren.</p>
 
   <p>
-    Hvis du ønsker å sende en oppfølgingsmelding som ikke er passende
-    for <code>debian-bugs-dist</code> så kan du gjøre det ved å sende
+    Hvis du ønsker å sende en oppfølgingsmelding som ikke er passende
+    for <code>debian-bugs-dist</code> så kan du gjøre det ved å sende
     til <var>nnn</var><code>-quiet@bugs.debian.org</code> eller
     <var>nnn</var><code>-maintonly@bugs.debian.org</code>.
     Epost til <var>nnn</var><code>-quiet@bugs.debian.org</code> blir lagret i
@@ -128,13 +128,13 @@
 
   <p>
     <em>Ikke</em> bruk <q>svar til alle</q> eller <q>followup</q> dersom du ikke
-    har til hensikt å vesentlig redigere på mottakerlisten. Pass spesielt på at
-    du ikke sender oppfølgingsmeldinger til
+    har til hensikt å vesentlig redigere på mottakerlisten. Pass spesielt på at
+    du ikke sender oppfølgingsmeldinger til
     <code>submit@bugs.debian.org</code>.</p>
 
 
   <p>
-    For mer informasjon om linjer til å dempe ACK-meldinger og hvordan sende
+    For mer informasjon om linjer til å dempe ACK-meldinger og hvordan sende
     kopier ved bruk av feilrapportsystemet, se 
     <a href="Reporting">Instruksjoner for feilrapportering</a>.</p>
 
@@ -143,10 +143,10 @@
   <p>
     Feilrapportsystemet lagrer en alvorlighetsgrad sammen med hver
     feilrapport. Denne settes til <code>normal</code> til vanlig, men
-    kan overstyres, enten ved å ha en <code>Severity</code>-linje i
-    pseudo-hodet på eposten når den sendes inn (se
+    kan overstyres, enten ved å ha en <code>Severity</code>-linje i
+    pseudo-hodet på eposten når den sendes inn (se
     <a href="Reporting#pseudoheader">instruksjonene for
-    feilrapportering</a>), eller ved å bruke
+    feilrapportering</a>), eller ved å bruke
     <code>severity</code>-kommandoen med <a
     href="#requestserv">kontrolltjeneren</a>.</p>
 
@@ -156,29 +156,29 @@
     <dl>
       <dt><code>critical</code> (kritisk)</dt>
       <dd>
-	en feil som får annen ubeslektet programvare på systemet
-	(eller hele systemet) til å slutte å fungere, eller forårsaker
-	alvorlig datatap, eller lager et sikkerhetshull på systemer
+	en feil som får annen ubeslektet programvare på systemet
+	(eller hele systemet) til å slutte å fungere, eller forårsaker
+	alvorlig datatap, eller lager et sikkerhetshull på systemer
 	der pakken installeres.</dd>
       
 
       <dt><code>grave</code> (graverende)</dt>
       <dd>
-	gjør pakken det er snakk om helt eller for det meste
-	ubrukelig, forårsaker datatap eller lager et sikkerhetshull
+	gjør pakken det er snakk om helt eller for det meste
+	ubrukelig, forårsaker datatap eller lager et sikkerhetshull
 	som gir tilgang til kontoene til brukerne som bruker pakken.</dd>
 
       <dt><code>serious</code> (alvorlig)</dt>
       <dd>
-	et alvorlig brudd på Debians retningslinjer (det vil si, pakken bryter
-	mot et <q>må</q> eller <q>påkrevd</q>-krav) eller, i følge
-	pakkeutvikleren, gjør pakken uegnet for utgivelse.</dd>
+	et alvorlig brudd på Debians retningslinjer (det vil si, pakken bryter
+	mot et <q>må</q> eller <q>påkrevd</q>-krav) eller, i følge
+	pakkeutvikleren, gjør pakken uegnet for utgivelse.</dd>
 
 
       <dt><code>important</code> (viktig)</dt>
       <dd>
-	en feil som har gjør at pakken ikke virker skikkelig, uten å
-	gjøre den fullstendig ubrukelig.</dd>
+	en feil som har gjør at pakken ikke virker skikkelig, uten å
+	gjøre den fullstendig ubrukelig.</dd>
 
       <dt><code>normal</code> (vanlig)</dt>
       <dd>
@@ -187,13 +187,13 @@
 
       <dt><code>minor</code> (liten)</dt>
       <dd>
-	et problem som ikke påvirker pakkens nytteverdi, og som
-	sannsynligvis er trivielt å rette.</dd>
+	et problem som ikke påvirker pakkens nytteverdi, og som
+	sannsynligvis er trivielt å rette.</dd>
 
-      <dt><code>wishlist</code> (ønske)</dt>
+      <dt><code>wishlist</code> (ønske)</dt>
       <dd>
-	for spørsmål om nye funksjoner og feil som er vanskelige å
-	rette på grunn av designvalg.</dd>
+	for spørsmål om nye funksjoner og feil som er vanskelige å
+	rette på grunn av designvalg.</dd>
     </dl>
 
   <p>
@@ -211,63 +211,63 @@
 
   <p>
     Hver rapport kan ha null eller flere merkelapper angitt. Disse
-    blir vist både i listen over feilrapporter på pakkens egen side, 
-    og på den fullstendige feilrapportloggen.</p>
+    blir vist både i listen over feilrapporter på pakkens egen side, 
+    og på den fullstendige feilrapportloggen.</p>
 
   <p>
-    Merkelapper kan settes ved å bruk en <code>Tags</code>-linje i
-    pseudo-linjen når feilen meldes inn (se <a
+    Merkelapper kan settes ved å bruk en <code>Tags</code>-linje i
+    pseudo-linjen når feilen meldes inn (se <a
     href="Reporting#pseudoheader">instruksjoner for
-    feilrapportering</a>), eller ved å bruke
+    feilrapportering</a>), eller ved å bruke
     <code>tags</code>-kommandoen til <a
     href="#requestserv">kontrolltjeneren</a>.
     Separer flere merkelapper med komma, mellomrom eller begge.
   </p>
 
-  <p>Nåværende merkelapper er:
+  <p>Nåværende merkelapper er:
 
     <dl>
       <dt><code>patch</code> (lapp)</dt>
       <dd>
-	En lapp eller en annen enkel prosedyre for å rette feilen er
+	En lapp eller en annen enkel prosedyre for å rette feilen er
 	inkludert i feilrapporten. Hvis det er en lapp tilgjengelig,
-	men den ikke retter feilen ordentlig eller forårsaker et annet
+	men den ikke retter feilen ordentlig eller forårsaker et annet
 	problem skal ikke denne merkelappen brukes.</dd>
 
-      <dt><code>wontfix</code> (kommer ikke til å rettes)</dt>
+      <dt><code>wontfix</code> (kommer ikke til å rettes)</dt>
       <dd>
-	Denne feilen kommer ikke til å bli rettet.  Dette kan skyldes
-	at man har valgt en av to likeverdige måter å gjøre noe på og
-	utvikleren og innsenderen foretrekker to forskjellige måter,
-	fordi endring av oppførselen vil forårsake andre, verre
+	Denne feilen kommer ikke til å bli rettet.  Dette kan skyldes
+	at man har valgt en av to likeverdige måter å gjøre noe på og
+	utvikleren og innsenderen foretrekker to forskjellige måter,
+	fordi endring av oppførselen vil forårsake andre, verre
 	problemer for andre, eller av andre grunner.</dd>
 
       <dt><code>moreinfo</code> (mer informasjon trengs)</dt>
       <dd>
-	Denne feilen kan ikke rettes før mer informasjon blir gjort
-	tilgjengelig. Feilrapporten kommer til å bli lukket dersom ny
-	informasjon ikke kommer i løpet av noe tid (et par måneder).
+	Denne feilen kan ikke rettes før mer informasjon blir gjort
+	tilgjengelig. Feilrapporten kommer til å bli lukket dersom ny
+	informasjon ikke kommer i løpet av noe tid (et par måneder).
 	Denne merkelappen er for feilrapporter av typen <q>Dette virker
 	ikke!</q>. Hva virker ikke?</dd>
 
       <dt><code>unreproducible</code> (ikke reproduserbar)</dt>
       <dd>
-	Denne feilen kan ikke reproduseres på utviklerens system.
-	Assistanse fra tredjepart er nødvendig for å diagnostisere
+	Denne feilen kan ikke reproduseres på utviklerens system.
+	Assistanse fra tredjepart er nødvendig for å diagnostisere
 	problemet.</dd>
 
       <dt><code>help</code> (hjelp)</dt>
-        <dd>Utvikleren trenger hjelp for å fikse denne feilen.</dd>
+        <dd>Utvikleren trenger hjelp for å fikse denne feilen.</dd>
 
-      <dt><code>pending</code> (i kø)</dt>
-        <dd>En løsning på denne feilen har blitt funnet og en opplasting
+      <dt><code>pending</code> (i kø)</dt>
+        <dd>En løsning på denne feilen har blitt funnet og en opplasting
 	    vil bli gjort snarlig.</dd>
 
       <dt><code>fixed</code> (rettet)</dt>
       <dd>
 	Denne feilen er rettet eller jobbet seg rundt (ved en
 	opplasting av pakken av en annen utvikler enn den som er
-	ansvarlig for den, f.eks), men problemet må fremdeles løses av
+	ansvarlig for den, f.eks), men problemet må fremdeles løses av
 	utvikleren.  Denne merkelappen erstatter den gamle <q>fixed</q>
 	alvorlighetsgraden.</dd>
 
@@ -275,27 +275,27 @@
       <dd>
 	Denne rapporten beskriver et sikkerhetsproblem i en pakke
 	(f.eks feil rettigheter som gir tilgang til data som ikke skal
-	være tilgjengelig; bufferoverflyt som kan gi uautorisert
+	være tilgjengelig; bufferoverflyt som kan gi uautorisert
 	tilgang til systemet, etc). De fleste sikkerhetsrelaterte
-	feil bør også ha alvorlighetsgrad critical eller grave.</dd>
+	feil bør også ha alvorlighetsgrad critical eller grave.</dd>
 
-      <dt><code>upstream</code> (oppstrøms)</dt>
+      <dt><code>upstream</code> (oppstrøms)</dt>
       <dd>
-	Denne rapporten gjelder oppstrømsdelen av pakken.</dd>
+	Denne rapporten gjelder oppstrømsdelen av pakken.</dd>
 
       <dt><code>confirmed</code> (bekreftet)</dt>
       <dd>
-	Utvikleren har sett, forstått og generelt sett er enig med
+	Utvikleren har sett, forstått og generelt sett er enig med
 	at det er en feil, men har ikke fikset det. (Bruk av denne
 	merkelappen er valgfri; den er til hovedsaklig for utviklere
-	som behandler store mengder av åpne feilrapporter.)</dd>
+	som behandler store mengder av åpne feilrapporter.)</dd>
 
-      <dt><code>fixed-upstream</code> (fikset oppstrøms)</dt>
+      <dt><code>fixed-upstream</code> (fikset oppstrøms)</dt>
       <dd>
-	Feilen har blitt fikset hos en utvikler oppstrøms, men er
+	Feilen har blitt fikset hos en utvikler oppstrøms, men er
 	fortsatt ikke inkludert i pakken (for hva enn grunn: kanskje
-	det er altfor komplisert å anvende i en eldre versjon eller
-	altfor liten til å være verdt bryet).</dd>
+	det er altfor komplisert å anvende i en eldre versjon eller
+	altfor liten til å være verdt bryet).</dd>
 
       <dt><code>fixed-in-experimental</code> (fikset i eksperimentell)</dt>
       <dd>
@@ -305,17 +305,17 @@
       <dt><code>d-i</code></dt>
       <dd>
 	Denne feilen er relevant til utviklingen av debian-installer. Det
-	er forventet at denne vil bli brukt når feilen påvirker utvikling 
-	av installasjonsprogrammet, men ikke når feilen er innsendt mot en
-	pakke som påvirker installasjonsprogrammet direkte.</dd>
+	er forventet at denne vil bli brukt når feilen påvirker utvikling 
+	av installasjonsprogrammet, men ikke når feilen er innsendt mot en
+	pakke som påvirker installasjonsprogrammet direkte.</dd>
 
       <dt><code>ipv6</code></dt>
       <dd>
-	Denne feilen påvirker Internet Protocol version 6.</dd>
+	Denne feilen påvirker Internet Protocol version 6.</dd>
 
       <dt><code>lfs</code></dt>
       <dd>
-	Denne feilen påvirker støtte for store filer (over 2 gigabytes).</dd>
+	Denne feilen påvirker støtte for store filer (over 2 gigabytes).</dd>
 
       <dt><code>l10n</code></dt>
       <dd>
@@ -332,74 +332,74 @@
       <dt><code>sarge</code></dt>
       <dd>
 	Dette er en merkelapp til sarge-utgaven, og har to innvirkninger.
-	Når denne blir satt på en feilrapport kan feilen kun påvirke sarge
-	(men det kan påvirke andre utgaver hvis andre merkelapper for utgavene
-	er satt) men andre normale merkelapper gjelder også. Feilen burde ikke
-	bli arkivert før den har blitt fikset i sarge.</dd>
+	Når denne blir satt på en feilrapport kan feilen kun påvirke sarge
+	(men det kan påvirke andre utgaver hvis andre merkelapper for utgavene
+	er satt) men andre normale merkelapper gjelder også. Feilen burde ikke
+	bli arkivert før den har blitt fikset i sarge.</dd>
 
       <dt><code>sarge-ignore</code></dt>
       <dd>
-	Denne utgavelseskritiske feilrapporten skal bli ignorert for å gi ut
+	Denne utgavelseskritiske feilrapporten skal bli ignorert for å gi ut
 	sarge. <strong>Denne merkelappen skal kun bli brukt av utgavelsesansvarlig;
 	ikke sett denne selv uten eksplisitt autorisasjon fra dem.</strong></dd>
 
       <dt><code>etch</code></dt>
       <dd>
 	Dette er en merkelapp til etch-utgaven, og har to innvirkninger.
-        Når denne blir satt på en feilrapport kan feilen kun påvirke etch
-        (men det kan påvirke andre utgaver hvis andre merkelapper for utgavene
-        er satt) men andre normale merkelapper gjelder også. Feilen burde ikke
-	bli arkivert før den har blitt fikset i etch.</dd>
+        Når denne blir satt på en feilrapport kan feilen kun påvirke etch
+        (men det kan påvirke andre utgaver hvis andre merkelapper for utgavene
+        er satt) men andre normale merkelapper gjelder også. Feilen burde ikke
+	bli arkivert før den har blitt fikset i etch.</dd>
 
       <dt><code>etch-ignore</code></dt>
       <dd>
-	Denne utgavelseskritiske feilrapporten skal bli ignorert for å gi ut
+	Denne utgavelseskritiske feilrapporten skal bli ignorert for å gi ut
         etch. <strong>Denne merkelappen skal kun bli brukt av utgavelsesansvarlig;
         ikke sett denne selv uten eksplisitt autorisasjon fra dem.</strong></dd>
 
       <dt><code>lenny</code></dt>
       <dd>
 	 Dette er en merkelapp til lenny-utgaven, og har to innvirkninger.
-	 Når denne blir satt på en feilrapport kan feilen kun påvirke lenny
-         (men det kan påvirke andre utgaver hvis andre merkelapper for utgavene
-	 er satt) men andre normale merkelapper gjelder også. Feilen burde ikke
-	 bli arkivert før den har blitt fikset i lenny.</dd>
+	 Når denne blir satt på en feilrapport kan feilen kun påvirke lenny
+         (men det kan påvirke andre utgaver hvis andre merkelapper for utgavene
+	 er satt) men andre normale merkelapper gjelder også. Feilen burde ikke
+	 bli arkivert før den har blitt fikset i lenny.</dd>
 
       <dt><code>lenny-ignore</code></dt>
       <dd>
-	Denne utgavelseskritiske feilrapporten skal bli ignorert for å gi ut
+	Denne utgavelseskritiske feilrapporten skal bli ignorert for å gi ut
         lenny. <strong>Denne merkelappen skal kun bli brukt av utgavelsesansvarlig(e);
         ikke sett denne selv uten eksplisitt autorisasjon fra dem.</strong></dd>
 
       <dt><code>squeeze</code></dt>
       <dd>
 	Dette er en merkelapp til squeeze-utgaven, og har to innvirkninger.
-        Når denne blir satt på en feilrapport kan feilen kun påvirke squeeze
-        (men det kan påvirke andre utgaver hvis andre merkelapper for utgavene
-        er satt) men andre normale merkelapper gjelder også. Feilen burde ikke
-        bli arkivert før den har blitt fikset i squeeze.</dd>
+        Når denne blir satt på en feilrapport kan feilen kun påvirke squeeze
+        (men det kan påvirke andre utgaver hvis andre merkelapper for utgavene
+        er satt) men andre normale merkelapper gjelder også. Feilen burde ikke
+        bli arkivert før den har blitt fikset i squeeze.</dd>
 
       <dt><code>squeeze-ignore</code></dt>
       <dd>
-	Denne utgavelseskritiske feilrapporten skal bli ignorert for å gi ut
+	Denne utgavelseskritiske feilrapporten skal bli ignorert for å gi ut
         squeeze. <strong>Denne merkelappen skal kun bli brukt av utgavelsesansvarlig(e);
         ikke sett denne selv uten eksplisitt autorisasjon fra dem.</strong></dd>
 
       <dt><code>sid</code></dt>
       <dd>
 	Dette er en merkelapp til sid, og har to innvirkninger.
-        Når denne blir satt på en feilrapport kan feilen kun påvirke sid
-        (men det kan påvirke andre utgaver hvis andre merkelapper for utgavene
-        er satt) men andre normale merkelapper gjelder også. Feilen burde ikke
-	bli arkivert før den har blitt fikset i sid.</dd>
+        Når denne blir satt på en feilrapport kan feilen kun påvirke sid
+        (men det kan påvirke andre utgaver hvis andre merkelapper for utgavene
+        er satt) men andre normale merkelapper gjelder også. Feilen burde ikke
+	bli arkivert før den har blitt fikset i sid.</dd>
 
       <dt><code>experimental</code></dt>
       <dd>
 	Dette er en merkelapp til experimental, og har to innvirkninger.
-        Når denne blir satt på en feilrapport kan feilen kun påvirke experimental
-        (men det kan påvirke andre utgaver hvis andre merkelapper for utgavene
-	er satt) men andre normale merkelapper gjelder også. Feilen burde ikke
-        bli arkivert før den har blitt fikset i experimental.</dd>
+        Når denne blir satt på en feilrapport kan feilen kun påvirke experimental
+        (men det kan påvirke andre utgaver hvis andre merkelapper for utgavene
+	er satt) men andre normale merkelapper gjelder også. Feilen burde ikke
+        bli arkivert før den har blitt fikset i experimental.</dd>
 
     </dl>
 
@@ -407,10 +407,10 @@
     Meningen av de siste 8 distribusjonsspesifikke merkelappene
     har endret seg i det siste; merkelappen -ignore ignorerer 
     feilen for videre testing. Merkelappene for utgivelse indikerer
-    at aktuelle feilrapporter ikke skal bli arkivert før det har blitt
+    at aktuelle feilrapporter ikke skal bli arkivert før det har blitt
     ordnet i settet av utgivelser angitt. Merkelappen for utgivelse
-    skal også indikere at feilrapporten er kun betenkt en feil i det
-    settet med utgivelser angitt (med andre ord så er feilen 
+    skal også indikere at feilrapporten er kun betenkt en feil i det
+    settet med utgivelser angitt (med andre ord så er feilen 
     <strong>ikke tilstede</strong> i utgivelser hvor merkelappen for
     utgivelsen ikke er satt i feilrapporten).
   </p>
@@ -418,10 +418,10 @@
   <p>
     Merkelappene for utgivelser burde <strong>ikke</strong> bli brukt
     hvis rett angivelse av versjonen til feilrapporten ville utgjort
-    nødvendig effekt, siden de krever manuelle tillegg og fjerning. 
-    Hvis du er usikker på om en merkelapp for utgivelser er nødvendig,
+    nødvendig effekt, siden de krever manuelle tillegg og fjerning. 
+    Hvis du er usikker på om en merkelapp for utgivelser er nødvendig,
     kontakt Debian sine administratorer for feilrapportsystemet (BTS)
-    (<email "owner@bugs.debian.org">) eller utgivelseslaget for råd.
+    (<email "owner@bugs.debian.org">) eller utgivelseslaget for råd.
   </p>
 
   <h2>
@@ -429,55 +429,55 @@
       feilrapport</a></h2> 
 
   <p>
-    Når en Debian-utvikler videresender en feilrapport til utvikleren
+    NÃ¥r en Debian-utvikler videresender en feilrapport til utvikleren
     av den orginale kildekoden som gav opphav til Debian-pakken, skal
-    dette lagres i feilrapportsystemet som følger:</p>
+    dette lagres i feilrapportsystemet som følger:</p>
 
   <p>
-    Pass på at <code>Til</code>-feltet på meldingen kun har
-    adressen(e) til forfatteren(e). Legg både personen som
+    Pass på at <code>Til</code>-feltet på meldingen kun har
+    adressen(e) til forfatteren(e). Legg både personen som
     rapporterte feilen, 
     <var>nnn</var><code>-forwarded@bugs.debian.org</code>,
     og <var>nnn</var><code>@bugs.debian.org</code> i
     <code>Cc</code>-feltet.</p>
 
   <p>
-    Be forfatteren om å bevare <code>Cc</code>-feltet til
-    <var>nnn</var><code>-forwarded@bugs</code> når de svarer slik at
+    Be forfatteren om å bevare <code>Cc</code>-feltet til
+    <var>nnn</var><code>-forwarded@bugs</code> når de svarer slik at
     feilrapportsystemet lagrer svaret deres sammen med den
     opprinnelige rapporten. Disse meldingen er kun lagret, ikke sendt
-    videre; for å sende en melding som normalt, send den til
-    <var>nnn</var><code>@bugs.debian.org</code> også.
+    videre; for å sende en melding som normalt, send den til
+    <var>nnn</var><code>@bugs.debian.org</code> også.
 </p>
 
   <p>
-    Når feilrapportsystemet får en melding på adressen
-    <var>nnn</var><code>-forwarded</code> så vil den merke den
+    Når feilrapportsystemet får en melding på adressen
+    <var>nnn</var><code>-forwarded</code> så vil den merke den
     aktuelle feilrapporten med at den har blitt videresendt til
-    adresse(ne) i<code>Til</code>-feltet på meldingen den får,
+    adresse(ne) i<code>Til</code>-feltet på meldingen den får,
     med mindre den allerede er merket som videresendt.
   </p>
 
   <p>
-    Do kan også endre på <q>forwarded to</q>-informasjonen ved å sende
+    Do kan også endre på <q>forwarded to</q>-informasjonen ved å sende
     meldinger til
     <a href="server-control"><code>control@bugs.debian.org</code></a>.
   </p>
 
-  <h2><a name="owner">Endre eierskap på feilrapport</a></h2>
+  <h2><a name="owner">Endre eierskap på feilrapport</a></h2>
   
   <p>
-    I tilfeller der personen som er ansvarlig for å fikse en feil 
+    I tilfeller der personen som er ansvarlig for å fikse en feil 
     ikke er en tilegnet utvikler for en assosierte pakken (for 
-    eksempel hvis pakken er utviklet av et lag), så kan det være
-    nyttig å rapportere dette i feilrapportsystemet. For å hjelpe
+    eksempel hvis pakken er utviklet av et lag), så kan det være
+    nyttig å rapportere dette i feilrapportsystemet. For å hjelpe
     med dette kan hver feilrapport valgfritt ha en eier.</p>
 
   <p>
-    Eieren kan bli sett ved å angi en <code>Owner</code>-linje i
-    pseudo-hodet når en feilrapport en innsendt (se
+    Eieren kan bli sett ved å angi en <code>Owner</code>-linje i
+    pseudo-hodet når en feilrapport en innsendt (se
     <a href="Reporting#pseudoheader">instruksjoner for feilrapportering</a>),
-    eller ved å bruke <code>owner</code> og <code>noowner</code>-kommandoene
+    eller ved å bruke <code>owner</code> og <code>noowner</code>-kommandoene
     med <a href="#requestserv">kontrolltjeneren</a>.
   </p>
 
@@ -487,113 +487,113 @@
     Hvis den ansvarlige for en pakke er oppgitt feil, er dette
     vanligvis fordi pakkeansvarlig har skiftet nylig, og den nye
     ansvarlige har ikke lastet opp en ny versjon av pakken med endret
-    <code>Maintainer</code>-felt i kontrollfilen. Dette blir rettet på
-    når pakken lastes opp; alternativt kan de arkivansvarlige
-    overstyre angitt pakkeansvarlig for en pakke manuelt, særlig gjelder 
-    dette dersom det ikke forventes at pakken kommer til å bli lastet 
+    <code>Maintainer</code>-felt i kontrollfilen. Dette blir rettet på
+    når pakken lastes opp; alternativt kan de arkivansvarlige
+    overstyre angitt pakkeansvarlig for en pakke manuelt, særlig gjelder 
+    dette dersom det ikke forventes at pakken kommer til å bli lastet 
     opp snarlig. Kontakt <code>override-change@debian.org</code> for 
     endringer.
   </p>
 
 
-  <h2><a name="requestserv">Gjenåpne, tilegne og endre på feilrapporter</a></h2>
+  <h2><a name="requestserv">Gjenåpne, tilegne og endre på feilrapporter</a></h2>
 
   <p>
-    Det er mulig å tilegne feilrapporter til andre pakker, gjenåpne
-    rapporter som ikke skulle vært lukket, endre på informasjonen om
-    hvor (hvis) feilrapporten er videresendt, endre på alvorlighetsgrad 
-    og titler på feilrapporter, sette eierskap, slå sammen og ta 
+    Det er mulig å tilegne feilrapporter til andre pakker, gjenåpne
+    rapporter som ikke skulle vært lukket, endre på informasjonen om
+    hvor (hvis) feilrapporten er videresendt, endre på alvorlighetsgrad 
+    og titler på feilrapporter, sette eierskap, slå sammen og ta 
     fra hverandre feilrapporter og angi versjoner av pakker der feilen ble
-    funnet og i hvilken det er fikset. Dette gjøres ved å sende epost til
+    funnet og i hvilken det er fikset. Dette gjøres ved å sende epost til
     <code>control@bugs.debian.org</code>.
   </p>
 
   <p>
-    <a href="server-control">Formatet på disse meldingene</a> er
-    beskrevet i et annet dokument tilgjengelig på WWW, eller i filen
+    <a href="server-control">Formatet på disse meldingene</a> er
+    beskrevet i et annet dokument tilgjengelig på WWW, eller i filen
     <code>bug-maint-mailcontrol.txt</code>. En ren tekstutgave kan
-    anskaffes ved å sende <code>help</code> til adressen over.
+    anskaffes ved å sende <code>help</code> til adressen over.
   </p>
 
-  <h2><a name="subscribe">Abonnere på feilrapporter</a></h2>
+  <h2><a name="subscribe">Abonnere på feilrapporter</a></h2>
   
   <p>
-    Feilrapportsystemet tillater også innsendere, utviklere og andre
-    interesserte tredjeparter å abonnere på individuelle feilrapporter.
-    Denne funksjonen kan bli brukt av de som ønsker å holde et øye med en
-    feilrapport, uten å måtte abonnere på en pakke gjennom 
+    Feilrapportsystemet tillater også innsendere, utviklere og andre
+    interesserte tredjeparter å abonnere på individuelle feilrapporter.
+    Denne funksjonen kan bli brukt av de som ønsker å holde et øye med en
+    feilrapport, uten å måtte abonnere på en pakke gjennom 
     <a href="http://packages.qa.debian.org">PTS</a>.
     Alle meldinger som er mottatt gjennom <var>nnn</var><code>@bugs.debian.org</code>,
     er sendt til abonnenter.
   </p>
 
   <p>
-    Abonnere på en feilrapport kan bli gjort ved å sende en e-post til
+    Abonnere på en feilrapport kan bli gjort ved å sende en e-post til
     <var>nnn</var><code>-subscribe@bugs.debian.org</code>. Tittelen og
-    kroppen til e-posten blir ignorert av feilrapportsystemet. Når en melding
-    har blitt behandlet vil brukeren få en bekreftelsesmelding som de er
-    nødt til å svare på før de får tilsendt meldinger som er relatert til
+    kroppen til e-posten blir ignorert av feilrapportsystemet. NÃ¥r en melding
+    har blitt behandlet vil brukeren få en bekreftelsesmelding som de er
+    nødt til å svare på før de får tilsendt meldinger som er relatert til
     feilrapporten.
   </p>
   
   <p>
-    Det er også mulig å avslutte et abonnent på en feilrapport.
-    For å avslutte abonnentet må man send en e-post til
+    Det er også mulig å avslutte et abonnent på en feilrapport.
+    For å avslutte abonnentet må man send en e-post til
     <var>nnn</var><code>-unsubscribe@bugs.debian.org</code>. Tittelen
-    og kroppen på e-posten er igjen ignorert av BTS. Brukerene vil få
-    tilsendt en bekreftelse som de må svare på hvis de ønsker å 
-    avslutte abonnentet på feilrapporten.
+    og kroppen på e-posten er igjen ignorert av BTS. Brukerene vil få
+    tilsendt en bekreftelse som de må svare på hvis de ønsker å 
+    avslutte abonnentet på feilrapporten.
   </p>
 
   <p>
     Som standard vil adressen som blir funnet i <code>Fra</code>-feltet
-    blir abonnenten. Hvis du ønsker å abonnere en annen adresse til en
-    feilrapport så må du endre på måten du abonnerer på. Dette tar følgende
+    blir abonnenten. Hvis du ønsker å abonnere en annen adresse til en
+    feilrapport så må du endre på måten du abonnerer på. Dette tar følgende
     form:
     <var>nnn</var><code>-subscribe-</code>\
     <var>localpart</var><code>=</code>\
     <var>example.com</var><code>@bugs.debian.org</code>.
     Det eksempelet ville sendt <code>localpart@example.com</code> som en
-    abonneringsmelding til feilrapport <var>nnn</var>. Alfakrøll blir endret
-    til å være et erlik-tegn (<code>=</code>). På samme måte tar en avslutning
-    på abonnentet form <var>nnn</var><code>-unsubscribe-</code><var>localpart</var>\
+    abonneringsmelding til feilrapport <var>nnn</var>. Alfakrøll blir endret
+    til å være et erlik-tegn (<code>=</code>). På samme måte tar en avslutning
+    på abonnentet form <var>nnn</var><code>-unsubscribe-</code><var>localpart</var>\
     <code>=</code><var>example.com</var><code>@bugs.debian.org</code>.
     I begge tilfeller vil tittelen og kroppen av e-posten bli videresendt til e-postadressen
     angitt for bekreftelse.
   </p>
 
-  <h2><a name="subjectscan">Mer eller mindre avlegs tittelfelt-søk</a></h2>
+  <h2><a name="subjectscan">Mer eller mindre avlegs tittelfelt-søk</a></h2>
 
   <p>
     Meldinger som kommer til <code>submit</code> eller
     <code>bugs</code> og hvis tittelfelt starter med
     <code>Bug#</code><var>nnn</var> blir behandlet som om de hadde
-    blitt sendt til <var>nnn</var><code>@bugs</code>. Dette er både
-    av hensyn til bakoverkompatibilitet og for å hindre at
-    oppfølginger på feilrapporter havner som nye feilrapporter ved en
+    blitt sendt til <var>nnn</var><code>@bugs</code>. Dette er både
+    av hensyn til bakoverkompatibilitet og for å hindre at
+    oppfølginger på feilrapporter havner som nye feilrapporter ved en
     feil (f.eks at noen har brukt svar til alle).</p>
   
   <p>
     Meldinger sendt til <code>maintonly</code>, <code>done</code>,
-    <code>quiet</code> og <code>forwarded</code> behandles på en
-    tilsvarende måte.</p>
+    <code>quiet</code> og <code>forwarded</code> behandles på en
+    tilsvarende måte.</p>
 
   <p>
     Meldinger som kommer til <code>forwarded</code> og
     <code>done</code> &mdash; uten feilrapportnummer i adressen &mdash;
-    eller tittelfeltet blir lagret under <q>junk</q> (søppel) og bevart i noen
+    eller tittelfeltet blir lagret under <q>junk</q> (søppel) og bevart i noen
     uker, men ellers ignorert.</p>
 
 
   <h2><a name="x-debian-pr">Avlegs <code>X-Debian-PR: quiet</code>-egenskap</A></h2>
 
   <p>
-    Tidligere kunne man unngå at feilrapportsystemet videresendte
-    innkommende meldinger til <code>debian-bugs</code> ved å legge til
-    en <code>X-Debian-PR: quiet</code>-linje i hodet på eposten.</p>
+    Tidligere kunne man unngå at feilrapportsystemet videresendte
+    innkommende meldinger til <code>debian-bugs</code> ved å legge til
+    en <code>X-Debian-PR: quiet</code>-linje i hodet på eposten.</p>
 
   <p>
-    Denne linjen blir nå ignorert. Send i stedet meldingen til
+    Denne linjen blir nå ignorert. Send i stedet meldingen til
     <code>quiet</code> eller <var>nnn</var><code>-quiet</code> (eller
     <code>maintonly</code> eller
     <var>nnn</var><code>-maintonly</code>).</p>
diff --git a/norwegian/Bugs/otherpages.inc b/norwegian/Bugs/otherpages.inc
index e25252efb4a..0aa9359c249 100644
--- a/norwegian/Bugs/otherpages.inc
+++ b/norwegian/Bugs/otherpages.inc
@@ -3,12 +3,12 @@
 <ul>
   <li><A href="./">Forsiden til feilrapportsystemet.</A>
   <li><A href="Reporting">Hvordan rapportere feil.</A>
-  <li><A href="Access">Komme til loggene på annet måter enn via web.</A>
+  <li><A href="Access">Komme til loggene på annet måter enn via web.</A>
   <li><A href="Developer">Bruksansvisning for utviklere.</A>
   <li><A href="server-control">Informasjon om hvordan man jobber med
   feilrapporter via epost.</A>
   <li><A href="server-refcard">Referansekort for epost-tjeneren.</A>
-  <li><A href="server-request">Etterspør feilrapporter via epost.</A>
+  <li><A href="server-request">Etterspør feilrapporter via epost.</A>
 # <li><A href="db/ix/full.html">Komplett liste over ikke rettede og
 #  nye feilrapporter.</A>
 # <li><A href="db/ix/packages.html">Pakker med rapporter om feil.</A>