Lokalhistoriewiki:Diskusjonsforum/Arkiv 2008-03 til 2008-05

Sidens innhold er arkivert fra Diskusjonsforumet og låst.
Vennligst ta opp ting vedrørende disse temaene på diskusjonsforumet med en henvisning hit dersom nye spørsmål oppstår.
31. jul 2008 kl. 19:54 Siri Johannessen (Siri J)

Ny server

Tjenesten er i ferd med å bli flyttet fra gammel server, en maskin som brukes til utviklingsjobber generelt og som ikke er en produksjonsserver, og til maskinen som har NLIs ordinære nettsted.

Natt til 29. mars ble artikkelbasene eksportert sammen med billedbasene, og importert på nytt på den nye produksjonsserveren. Etter noen feil og påfølgende feilretting, vi fikk et problem med DynamicPageList som blant annet lager portalene, og en jobb-kø som kom ut av kontroll, denne håndterer en serie automatiske prosesser, så er disse nå fikset og tjenesten fungerer noenlunde normalt. Det kan imidlertid være uoppdagede problemer og disse kan være på de merkverdigste steder. Sjekk rundt, prøv funksjonalitet, og se om noe ikke fungerer som det skal.

Den nye serveren er en produksjonsserver, som i praksis betyr at den har bedre rutiner for backup, feilretting i påkomne tilfeller, raskere nettverk, og lignende. Kort sagt så skal denne være vesentlig bedre for den her typen oppgaver enn demoserveren. Det var aldri planlagt at denne skulle få så stor trafikk som den faktisk fikk.

Hvis det viser seg at produksjonsserveren fungerer slik den er satt opp nå så vil de få ekstra artiklene som ligger på demoserveren bli overført manuelt. Hvis det viser seg at produksjonsserveren har større feil så kan det bli nødvendig med en ny eksport fra demoserveren. Med andre ord så er det fortsatt demoserveren som skal brukes for alminnelig artikkelproduksjon inntil alle er enige om at «nå skifter vi over». Se også pågående diskusjon på Portaldiskusjon:Kaffistova#Status flytting. — John Erling Blad (Jeblad) 29. mar 2008 kl. 21:38 (CET)

Problemer knyttet til gamle navnerom

Det har ligget igjen et mindre antall artikler i noen av de gamle navnerommene. Disse forsvant i flyttingen, og er antatt å ikke være essensielle for det nye nettstedet.

Problemer knyttet til utvidelser

En del utvidelser er ikke aktive fordi den nye serveren mangler underliggende programvare. Det er antatt at dette blir løst i kommende uke.

Følgende utvidelser vil ikke bli flyttet over uten at det identifiseres et behov, eller det uttrykkes ønske om å flytte de over.

Biblio (jeg mener denne bør brukes istedenfor gjør det selv-maler, men den trenger tilpassing)
PDFExport (Antakelig ønskelig å beholde, men ikke i bruk)
PDFBook (Antakelig ønskelig å beholde, men ikke i bruk)
Wikiskin (Åpner for vedlikeholdsproblem ifm med for rabiate lokalportaler)
AntiSpoof (Bør muligens fixes, defunc, har implementasjonsfeil)
KMLExport (Hvis Google skal brukes så bør denne på plass)
Sample (test, ikke overført)
Events (test, ikke overført)
HotData (test, ikke overført)
SyntaxHighlight_GeSHi (avventer installasjon av ekstra software)
Timeline (avventer installasjon av ekstra software)
Lilypond (avventer installasjon av ekstra software)

Problemer knyttet til parseren

Det er et problem med den nye parseren i Mediawiki 1.12 som spesielt slår til i forbindelse med DynamicPageList. Dette er løst ved å bruke en programwareswitch som Brion beskreiv på IRC. Etter å ha satt denne så fungerer DPL. Ulempen er at den nye parseren er en del bedre når det gjelder effektivitet og forutsigelighet. Fordelen med å bruke den gamle parseren utover at dette er den eneste som fungerer med DPL er at alle gamle maler fra Wikipedia fungerer.

Responstider, caching

Installasjonen påviste ingen støttesystemer for caching og serveren er derfor en del treigere enn nødvendig. Hvis respostider blir et problem for oss, eller andre brukere på maskinen, så kan det legges inn ekstra cacheing for foran Apache, i Mediawiki og foran MySQL. Tilsammen bør dette åpne for at serveren kan håndtere 2-5 ganger høyere last.

Switcher for debugging

I forbindelse med feilsøking var det slått på ekstra rapporter for diverse feilmeldinger fra Mediawiki og MySQL. Disse er nå slått av, men om det oppstår problemer så kan de slås på igjen.

Sider med endringer på demoserver siden overføring

Overføring skjedde etter 29. mar 2008 kl. 01:32, og siste endringer var på Portaldiskusjon:Kaffistova – Stryk oppføringer etter hvert som endringer er kopiert til ny server

Toppkategori

Kategorien «Soge» fjernes og erstattes med noe annet. «Lokalhistorie» er antakeligvis ingen god erstatning, så jeg foreslår kort og greit «Rot» for toppen (eventuelt beholde «Kategorier») og så kategorien «Prosjekt» for det som ligger i kategorien «Soge».

Jeg føler at det ikke er en optimal løsning. For de av oss som er datakyndige gir det mening, men de fleste tenker på rot som uryddighet og vil lure på hvorfor i all verden vi har eget navnerom for det vi ikke klarer å holde orden i. Synes Prosjekt er greit som erstatning for Soge-kategorien. Chris Nyborg (Cnyborg) 31. mar 2008 kl. 00:45 (CEST)

Denne gangen er jeg enig med Chris. Om ikke "Rot" fungerer, hva med "Topp" eller noe slikt? Siri Johannessen (Siri J) 31. mar 2008 kl. 02:13 (CEST)

Navnet kan sikkert diskuteres. Uttrykket «rot» eller «rotkategori» er nok mer vanlig i bibliotek– og arkivmiljø enn en skulle tro, men som sagt jeg har ingen sterke meninger om dette. Navnet «kategorier» fungerer forsåvidt, eneste problemet er at kategorien er en kategori og at navnet «kategorier» kan skape en god del forvirring. Kategori «Prosjekt» som erstatning for kategori «Soge» synes jeg virker uproblematisk. — John Erling Blad (Jeblad) 31. mar 2008 kl. 05:57 (CEST)

Henvisninger til «Soge»

«Soge» kan enkelt søkes opp i alle navnerom med søket «Soge». Det må søkes i alle navnerom for å finne alle forekomster. Kopier teskten til en teksteditor og erstatt hver enkelt av forekomstene.

Multilisensiering

Ved å la robotbrukere overstyre lisensieringen av artikler kan vi få til en betydelig og automatisk dynamikk i hvordan lisenser velges og brukes på sider. En robotbruker «Capplen» kan fremtvinge en opphavsmerking med eksklusive rettigheter, mens en robotbruker «Wikipedia (bokmål)» kan fremtvinge merking med GFDL.

Det er flere tilhørende problemer med en slik metode, blant annet at noen lisensieringer er gjensidig ekskluderende. Muligens er alt en trenger en sjekk som verifiserer at sist ankomne robotbruker ikke har lisenskrav som bryter med noen av de tidligere lisenskravene. Det betyr at nye brukere som krever GFDL kan legges til etter at en artikkel er påført dette kravet, mens kreves GFDL og den tidligere er merket med eksklusive rettigheter så kan ikke den senere ankomne robotbrukeren legge stoff til artikkelen. — John Erling Blad (Jeblad) 29. feb 2008 kl. 02:18 (CET)

Foreslår at multilisensiering foregår ved at en lisens legges til utfra brukernes skjønn og knyttet til en brukerid. Hvis en lisens introduseres som ikke allerede er angitt så vil redigeringen komme opp i «preview» og med en advarsel når en bruker legger inn stoffet. Er brukeren en robot bortfaller dette. Lisensen kan påføres via egne robotbrukere slik som «Capplen» hvis det er nødvendig å legge til opphavsrettsmerking for andre enn brukeren selv. — John Erling Blad (Jeblad) 29. feb 2008 kl. 11:42 (CET)

Dette har koblinger mot hvordan forfattere angis. — John Erling Blad (Jeblad) 13. mar 2008 kl. 15:13 (CET)

Bruk av leksikonet - grønne lenker

Det er flere måter å bruke leksikonet, de artiklene som ligger i navnerommet «Leksikon», i de andre artiklene. De er for en stor del små og definerende i formen, og dermed er det veldig attraktivt å bruke de som korte konsise forklaringer på ord.

Det jeg ser for meg er at ord som er beskrevet i leksikonrommet vil fremstå som grønne lenker i andre artikler. Hvis en peker på disse så vil teksten bli vist ved hjelp av AJAX-teknologi, eller hvis en klikekr på de så vil en bli overført til artikkelen på vanlig måte. Hvis ordet lenkes opp så blir det ikke lagd noen slik automatisk grønn lenke.

Dette gjør at ganske mye stoff blir selvforklarende, uten at brukerne trenger å legge særlig mye arbeid i dette, og uten at de trenger å vite i detalj hva leksikonrommet inneholder. — John Erling Blad (Jeblad) 20. feb 2008 kl. 11:58 (CET)

Jeg tror ikke det er aktuelt med visning av teksten i leksikonartiklene når man svever over lenken. For å få bruke stoffet er noen av kriteriene at det skal gjengis på sider i separat navnerom med tydelig merking av at det er underlagt opphavsrett og ikke fritt materiale, samt at det skal være tydelig at Cappelen forvalter rettighetene. En sveveboks vil normalt ikke kunne fylle de kravene. Grønne lenker ville derimot antagelig være en fordel, uten at det har blitt presentert for Cappelen. Akkurat leksikonet er en litt uheldig arena for eksperimentering nå, ettersom Cappelens jurister vurderer det hele, så for mye endringer nå kan skape problemer. Chris Nyborg (Cnyborg) 20. feb 2008 kl. 12:47 (CET)

Det vil uansett kreve en del jobb å få de inn i egne bokser, da den underliggende koden mangler. Selv det å gjenkjenne hva av teksten som potensielt kan bli en grønn lenke er en betydelig jobb. Når det gjelder merking med opphavsrett for slikt stoff så er det uproblematisk å få på merkingen, det er bruken av stoffet som er et problem. Svevebokser, eller hva de skal kalles, er faktisk fordelaktig for de vil ikke åpne for at stoffet er redigerbart i samme grad som en ordinær artikkel. På den andre siden så blir det muligens problemer med hva som oppfattes som selvstendig stoff. — John Erling Blad (Jeblad) 20. feb 2008 kl. 12:53 (CET)

Det er det at det skal være selvstendig stoff i eget navnerom jeg tenker på. Det viktigste nå er å i det hele tatt få en avtale på plass, og den prosessen baserer seg på det vi har vist Cappelen. Muligens kan det lages en fin løsning etterhvert, men jeg er litt redd for å forsinke hele prosessen nå hvis vi er for kreative. Chris Nyborg (Cnyborg) 20. feb 2008 kl. 17:46 (CET)

Jeg tviler på at vi evner å kunne gjøre noe av dette før tidligst om flere måneder, og da er rammene uansett lagt for hva vi kan eller ikke kan. Et sterkt argument for å gjøre noe slikt er derimot at plasseres artiklene i et eget navnerom, og det er like lett å lenge til Wikipedia som til disse så tviler jeg på at de vil bli brukt i nevneverdig grad. De må gjøres mer attraktive og/eller enklere å bruke enn lenking til Wikipedia. — John Erling Blad (Jeblad) 20. feb 2008 kl. 18:09 (CET)

Jeg har tenkt en del på dette, og jeg begynner å bli mer og mer sikker på at dette er en god måte å bruke dette leksikonet. Antakelig er det ikke en god løsning å gjøre lenkene grønne, for dette lager problemer i og med at den normale navigeringen blir brutt. Et alternativ er at lenkene merkes på en alternativ måte som kan brukes samtidig som den ordinære rød–/blåmerkingen av lenker, for eksempel ved å gi lenkene en bakgrunnsfarge, et bakgrunnsbilde eller ved å understreke ordene på noen måte. Jeg tror det er mest fornuftig med en stiplet understreking fordi dette signalerer en delvis lenke.

For å unngå å forstyrre den normale navigeringen så brukes en modifier key (shift, alt eller lignende) for å angi at en ønsker å navigere til denne artikkelen. Dermed vil en vanlig bruker aldri komme direkte til denne artikkelen fra artikkelteksten, den vil kun fremstå som en utvidet beskrivelse av lenka. Fordi forsøk på å redigere teksten gjør at brukeren må til leksikonets navnerom, og der er teksten merket og beskyttet, så mener jeg det er tydelig nok for brukerne at disse artiklene er spesielle.

Presentasjonen av teksten må være kort og konsis, dette er forutsetningen for at dette skal fungere, og med minst mulig ekstra merking. Teksten skal være ren for å fungere optimalt i denne rollen. Lisensmerking og lignende hører hjemme i navnerommet for leksikonet. Inne i dette navnerommet er artiklene merket med opphav og lisens, og ikke minst kategorisert. På grunn av merking og kategoriseringen så kan det i dette navnerommet ligge andre lignende oppslagsverk som brukes på samme vis.

Teksten Leksikon:Abildgård fungerer i en slik kontekst, mens teksten i Leksikon:Geitbåter ikke fungerer. Det betyr i korte trekk at formen fra det eksisterende leksikonet må beholdes på en mest mulig leksikalsk form, og at artikler fra dette ikke kan brukes på samme måte.

Teksten plasseres i lenkas title attributt, og det legges på nødvendige ekstra mekanismer for å formatere denne på en god måte. Hvis det oppdages at nettleseren er av en type som ikke støtter dette på en god måte så reformateres teksten og plasseres i et eget flytende lag.

Jeg mener dette gjør det mulig å få en langt mer omfattende bruk av leksikonet, og skaper en reell merverdi ved å inkludere dette. Det vil også skape et reelt ønske om å utvide, forbedre og komplettere dette. Hvis vi ikke gjør noe for å aktivt bruke dette så er jeg redd for at dette over tid vil bli erstattet av artikler i hovedrommet. Ved å gjøre det på denne måten bruker vi materialet slik det er best egnet, ved å forklare begreper i artikler slik et leksikon vanligvis brukes. — John Erling Blad (Jeblad) 13. mar 2008 kl. 12:09 (CET)

Mht understrekning av lenker - ha de ulike egne brukerinnstillingene i bakhodet når vi planlegger dette, slik at det som legges fast her ikke gjøres til intet når en bruker velger å la lenkene feks understreke. Stiplet understreking er en god idé da. Siri Johannessen (Siri J) 13. mar 2008 kl. 12:32 (CET)

Robotbrukere

For å forenkle kreditering av eksterne kollektive systemer slik som Wikimedia sine prosjekter, foreslår jeg at vi lager en løsning hvor import av artikler foretas via spesielle fjernstyrte roboter. Dette gjør at artikkelen for eksempel blir kreditert «Wikipedia (bokmål)» eller «Wikipedia (nynorsk)».

Vi kan også gå et skritt videre og si at en administrator kan skrive inn et merke i artikkelen som henviser til en revisjon på det aktuelle prosjektet. Dermed slipper vi helt unna bruk av referansemalene. Dette forutsetter at slike roboter med marginale redigeringer ikke fjernes fra bidragslista.

En ytterligere utvidelse er å gjøre det mulig med oppdateringer fra eksterne prosjekter. Dette er noe mer komplekst, men nokså trivielt å få til.

Slike robotbrukere kan identifiseres ved at de gis en egen rolle i grensesnittet for brukerrettighetskontroll. Dermed kan det angis en begrensing på hvem som kan autentisere slike robotbrukere. Brukeren kan etter at rollen er satt fjernstyres av brukere som er autorisert for å gjøre slik fjernstyring. Disse vil da få en spesialside hvor de angir den eksterne siden som skal importeres, hvoretter robotbrukeren vil hente inn denne og anføre seg selv som bruker i historikken. — John Erling Blad (Jeblad) 29. feb 2008 kl. 01:54 (CET)

Inntil videre har jeg lagt inn lenke til revisjonen i redigeringsforklaringen, noe jeg også har vist de andre Fredriikstadfolkene hvordan virker. Det var den enkleste entydige muligheten som ikke kan slettes ved et uhell, som her på (Henrik Ibsens gate Siri Johannessen (Siri J) 4. mar 2008 kl. 10:01 (CET)

Lenking på bidragsyters brukernavn

Det er mulig, og antakelig ønskelig, å lenke til bidragsyternes brukersider. Navnet fremkommer nederst på artikkelsidene og det er helt uproblematisk å implementere en metode for å legge på lenking til brukersidene.

Det er både fordeler og ulemper med slik lenking. Hovedsakling er ulempen en økt fokusering på hvem som har skrevet artikkelen, viktigste fordel er at det blir enklere or lesere å identifisere skribenter de fester tiltro til. Det er også en fordel ved at lesere kan gjenkjenne skribenter fra lokalmiljøet.

På Wikipedia er det antatt at lenking mellom navnerom er en uting, spesielt lenking til brukernes egne sider. I dette tilfellet er ikke lenkingen en del av artikkelteksten, men en del av lenkingen som skapes av brukergrensesnittet.

Jeg mener slik lenking er enkel, effektiv og relativt uproblematisk. — John Erling Blad (Jeblad) 28. feb 2008 kl. 23:45 (CET)

Jeg støtter en slik lenking; det gjør det mye enklere for uerfarne brukere å finne frem. Chris Nyborg (Cnyborg) 29. feb 2008 kl. 00:43 (CET)

Noen spesiell grunn til at denne ligger gjemt på selve portalen i steden for på portaldiskusjonen? Siri Johannessen (Siri J) 29. feb 2008 kl. 00:45 (CET)

Portalen fungerer i dette tilfellet som fellesforumet. Diskusjonssidene har jeg tenkt å løse på samme måte som på et par andre wikier hvor diskusjoner triller av diskusjonssiden og blir borte når sidene blir for store. Det finnes ingen robotarkivering, tråder som skal arkiveres må legges i tråder. Boten på engelsk arkiverer til en underside etter en uke og sletter etter to. Historikken til undersiden vil da fungere som en oversikt over tidligere slettede tråder. Om dette gjelder for alle diskusjoner er jeg usikker på, men det bør gjelde for diskusjonssiden for kaffistova. Kanskje sider med slik sletteautomatikk kan merkes, og kanskje de bør ha en oversikt over slettede diskusjoner.

Dette er bare en av flere måter å løse problemet knyttet til community-diskusjoner som vokser over alle bredder. Vi kan godt ta en mer omfattende diskusjon på metodevalg. Uansett må vi vel finne ut om dette er måten å gjøre ting på eller om vi skal velge en helt annen løsning. Det tar tid å skrive rydde og arkiveringsboter fra scratch, så det er ikke gitt at de mest elegante løsningene er realiserbare! — John Erling Blad (Jeblad) 29. feb 2008 kl. 01:30 (CET)

Ok, jeg stusset fordi jeg tilfeldigvis så denne komme forbi i siste endringer - og ikke via den vanlige lenken som jeg har på følgelisten. Siri Johannessen (Siri J) 29. feb 2008 kl. 01:35 (CET)

Vi trenger noe bedre grenseoppgang på hva som havner i tråder og hva som havner på diskusjonssiden. Ellers er «Siste kaffistova» kjekk, men jeg lurer på om denne bør ligge på portalen og ikke i venstremargen. — John Erling Blad (Jeblad) 29. feb 2008 kl. 02:00 (CET)

Lenking opprettet på brukernavn. — John Erling Blad (Jeblad) 29. feb 2008 kl. 11:06 (CET)

Endring av «Mest lest»

Boksen «Mest lest» på portalsidene bruker verdier for totalt mest lest, som er kontinuerlig akkumulerende. En temporært mest lest er antakeligvis mer aktuelt og mer korrekt, men støttes ikke av programvaren.

Det er flere måter å løse problemet med «Mest lest». En ekstern bot er en mulighet, en annen er å lage en utvidelse av databasen slik at temporær leseaktivitet tas vare på. Det første vil gi kode som kan gjenbrukes på Wikipedia, mens det siste gir en mer elegant løsning for denne wikien. Det er også mulig med en mellomløsning hvor en utvidelse av databasen beholder noen få tidligere verdier av leseaktiviteten slik at det er mulig å hente ut «Lest siste time», «Lest siste døgn», «Lest siste uke» og «Lest siste måned». Disse referer seg til en leseperiode løpende over et gitt antall timer. På bakgrunn av en del tidligere analyser av Wikipedia vil jeg tro at leseaktivitet over en uke er det mest aktuelle. — John Erling Blad (Jeblad) 21. feb 2008 kl. 11:29 (CET)

Jeg tror det er viktig at det blir en tidsbegrenset løsning. Ellers vil listen ikke gjenspeile endringene som skjer her etterhvert; de som er tidlig ute vil få forsprang som det er veldig vanskelig å ta igjen, og det kan virke demotiverende for noen som starter opp en ny portal og håper å se sine artikler på listen. Chris Nyborg (Cnyborg) 29. feb 2008 kl. 00:47 (CET)

Jeg er helt enig, men det må gjøres noe implementasjon for å få dette til å fungere på en strømlinjeformet måte. — John Erling Blad (Jeblad) 29. feb 2008 kl. 01:22 (CET)

Det er jo ikke noe stress. Synes forøvrig at det er fint om Wikipedia kan gjenbruke det, men vi må prioritere å gjøre denne wikien så god som mulig. Chris Nyborg (Cnyborg) 29. feb 2008 kl. 01:27 (CET)

ModSecurity2

For å bedre sikkerheten på serveren vil det bli installert en utvidelse ModSecurity2. Denne vil gi uvidete muligheter for å se hva som skjer på serveren hvis noen prøver på et innbrudd, i tillegg til at systemet bedrer muligheten for å avvise innbrudd automatisk.

Systemet er av de mest brukte for å øke sikkerheten i webapplikasjoner, og kan ses på som en «brannmur for servere». For en server hvor det skjer en betydelig og kompleks aktivitet, og flere av de involverte mangler grunnleggende kunskaper om sikker programmering, er det helt essensielt å bruke generiske metoder for å bedre sikkerheten. Ved at sikkerheten økes på denne måte vil det bli mulig å la enkelte brukere få en begrenset mulighet til å direkte endre filer.

Under installasjon av utvidelsen kan serveren bli mer enn normalt ustabil, men det er ventet at dette vil være forbigående. — John Erling Blad (Jeblad) 28. feb 2008 kl. 13:01 (CET)

Benk på vollane

Underprosjektet for Gamlebyen i Fredrikstad er i gang med artikkelproduksjon, og har hatt sitt første miniseminar i Bergen for prosjektets deltagere. Det mistenkes at de også skriver på brukermanualer, noe som er sterkt etterspurt.

Skribentene Anette [], Siri og Trond skriver så blekket spruter, og er de første som har begynt å bruke diskusjonssiden til portalen som samlingssted. Dette gjør at fellesdiskusjonene er lette å finne, samtidig som de unngår å fylle Kaffistova med småprat.

De blir også de første som beskriver bystrukturer så mange av problemene de støter på må beskrives slik at senere ankomne kan dra nytte av de erfaringene som blir gjort. -- John Erling Blad (Jeblad)

Sett av kategorier for portaler

Kategorier som brukes for utvalg av artikler for portaler byr på problemer. Categorymatch fungerer dårlig, og en bedre metode bør lages som gir færre feil, fleksibilitet ved vanskelige kategorier og mer automatikk for å fange opp typiske avvik.

For å gå rundt disse problemene har jeg lagd noen maler og forsøkt å bruke dette på noen portaler. Malene, og bruken, baserer seg på at det er noen distinkte fellestrekk som går igjen. Subjekter kategoriseres inn i kategorier relatert til kommuner og til fylker, hvis de da ikke er abstrakte eller gjelder hele landet. For eksempel brukes «Personer i kommune» og «Kirker i fylke». Hvis noe kategoriseres på kommunenivå er det fordi dette har tilstrekkelig lokalitet eller fordi mengden oppføringer blir for stor til at en overordnet geografisk tilhørighet fungerer. Legg merke til at to aspekter ved et subjekt kan kategoriseres med tilhørighet på to forskjellige nivåer, for eksempel så kan en person være i «Ordførere i fylke» og «Personer i kommune».

En portal for en kommune har lokalitet slik at alle oppføringer i kategorier for kommunen tas med, og oppføringer i selve kommunekategorien. Dette løses generelt med en mal {{tl|kommune}} som sjekker om aktuelle kategorier finnes, og om de finnes så inkluderes de i et sett for den angitte kommunen. Det er også mulig å angi et fylke til denne kategorien, og da vil preposisjoner brukes i relasjon til fylket.

Eksempel for {{kommune|Sør-Aurdal}}

<div class="toccolours">{{kommune|Sør-Aurdal}}</div>

Hvis vi går ett nivå opp til landskap/distrikt så oppfatter jeg dette som en aggregering av alle kommuner i området. Dette gir et stort, men noenlunde håndterbart antall kategorier.

Eksempel for {{Valdres}}

<div class="toccolours">{{Valdres}}</div>

På fylkesnivå finnes det egne kategorier med lokalitet på dette nivået. Dette kan utnyttes for å begrense omfanget av listene. En del artikler vil kun ha oppføring i en kommunekategori, men de fleste subjekter vil ha en ekstra tilhørighet på fylkesnivå eller ha en tematisk tilhørighet i en emneportal. At noen ramler ut på dette nivået er derfor ikke kritisk.

Settet av kategorier på fylkesnivå lages dermed utfra oppføringer i fylkesvise kategorier. Dette vil da omfatte slikt som «Kirker i fylke» og «Ordførere i fylke». Malen for å lage disse settene er {{tl|fylke}}.

Eksempel for {{fylke|Oppland}}

<div class="toccolours">{{fylke|Oppland}}</div>

(For øyeblikket er det lagt til kommunekategorier for å fylle portalen)

På samme måte som for landskap/distrikt blir da regionportalene en aggregering av alle fylker i området. På dette nivået vil det bli svært vanskelig å håndtere individuelle underkategorier i kommuner, men ved å bruke det tidligere skiftet fra kommunenivå til fylkesnivå blir dette håndterbart.

Eksempel for {{Austlandet}}

<div class="toccolours">{{Austlandet}}</div>

På hele landet skifter vi igjen metode, og her brukes ikke kategoriseringer som utvalgskriterium på samme måten. Her tar vi utgangspunkt i hele hovedrommet og unngår dermed problemet med store lister av kategorier.

For meg ser dette ut som en farbar vei, noen som ser alvorlige problemer noe sted? Ulempen er at det oppstår et skjult tematisk skifte mellom landskap/distrikt og fylke, men vil ikke en leser forvente slike skift i fokus? — John Erling Blad (Jeblad) 23. feb 2008 kl. 10:11 (CET)

En ulempe er at improviserte kategorier vil gjøre at artikler i disse faller ut. En kategori Kategori:Bagn Bygdesamling vil skape en slik situasjon. Artikler i en slik topic må kategoriseres i Kategori:Museer i Oppland og Kategori:Sør-Aurdal kommune uavhengig av om dette tilsynelatende er dobbeltkategorisering. — John Erling Blad (Jeblad) 23. feb 2008 kl. 11:39 (CET)

Det ser ut som det skjer noe kategorisering på varierende nivå i tillegg til landskap/distrikts -nivå. Dette gjør at det kan være aktuelt å introdusere noen mellomliggende maler. Istedenfor å kalle {{kommune|kommunenavn}} direkte på portalsiden så kan denne kalles via en mal {{kommunenavn}}. Denne malen kaller så foranstående mal i tillegg til eventuelle spesialkategorier for denne kommunen. Tilsvarende lages det en mal {{distrikt|distriktsnavn}} som brukes i en mal {{distriktsnavn}} og som også har spesialkategorier for distriktet i tillegg til de vanlige kommunekategoriene, det vil si de en når med {{kommune|kommunenavn}}. På fylkesnivå gjøres det samme, men kommuner byttes ut med distrikter. — John Erling Blad (Jeblad) 23. feb 2008 kl. 12:16 (CET)

Etter endringer blir det foranstående eksemplet for kommune

Eksempel for {{Oppland}}

<div class="toccolours">{{Oppland}}</div>

Fortsatt relativt håndterbart. — John Erling Blad (Jeblad) 23. feb 2008 kl. 13:07 (CET)

Feil på databasen

Vi fikk en fatal feil på databasen på grunn av en disk som fikk problemer. Det ble rapportert en merkelig feil som dukket opp etter omstart av maskinen, og da hang databasen en tid før den plutselig friskmeldte seg selv. Dette pågikk over noen dager før problemene ble fatale midt under en demo Marianne hadde for Skedsmo kommune.

Fordi feilen pågikk en tid, og den deretter forsvant, ble det antatt at feilen var i en tabell i databasen. Selve databasemotoren klarte en tid på en eller annen måte å rydde i problemet, men selve oppryddingen tok tid. Etter at denne ryddejobben er gjort klarer Mediawiki å koble seg til databasen. Årsaken var feil på en disk som hadde lesefeil, og etter noen dager klarte ikke databasemotoren å rydde og problemet ble permanent.

Feilen ble lokalisert til en disk, og selv om den var relativt full så var det ikke dette som var problemet. Disken hadde en skade som de innebygde analysemekanismene ikke klarte å finne før den stress-testet disken. For de som kjenner til det så har moderne harddisker noe som kalles S.M.A.R.T, som skal påvise når en disk begynner å få problemer med helbreden. Dette systemet rapporterte at disken var frisk og rask, hvis det ikke ble kjørt en omfattende test. Da påviste systemet at det var feil flere steder på disken. Det finnes flere metoder og systemer som skal hindre at fatale feil skal skje på en disk, og en av de viktigste er diskens egen interne reorganisering som skal hindre at risikable sektorer inne på disken blir brukt. Dette forutsetter skriveaktivitet i det utsatte området, men i en database hvor data skrives en gang og ikke oppdateres, slik som i Mediawiki, så vil dataene bli liggende på samme stedet inntil det plutselig oppstår en fatal lesefeil.

For å gjøre situasjonen enda værre så var det også feil på sikkerhetskopien som ble tatt når problemene oppstod. Når dette ble oppdaget ble demoversjonen som ble lagd for møtet med FAD siste fungerende sikkerhetskopi. Denne demoversjonen ble da «livbåten» om alt annet feilet.

Harddisken har feil flere steder, og det helt store problemet er at den har fått feil i to områder midt inne i databasen. Mellom disse er det et stort sort hull. For å prøve å redde mest mulig data ble flere programmer sjekket, blant annet foremost og magicrecovery, uten at disse kunne brukes. Disse programmene er bedre til å finne tvilsomme bilder enn historiske artikler i en database. Etter en del leting kom jeg over et verktøy lagd av noen i det som kalles Gnu-prosjektet, og verktøyet ddrecovery klarte å rekonstruere mesteparten av databasefila. Deretter klarte databasemotoren å reparere den rekonstruerte fila, og denne er nå eksportert som en standard sql-fil.

Så langt ser det ut som størrelsen på dumpet er riktig, det er på noe over 100MB, det inneholder datoer frem til februar-mars og virker umiddelbart korrekt. Det er kun noe fra da maskinen hadde problemer de siste dagene som er borte, pluss ca 4-5KB av noe som sannsynligvis er i kanten på "hullet". Det siste tilsvarer ett par små artikler med noen få revisjoner. Hvis noen klarer å finne en artikkel med feil så kan vi antakeligvis påvise hva som mangler og hente det fra FAD-demoen. Noen endelig bekreftelse på om alt er komplett får vi ikke før nettstedet er på lufta og alt er sjekket.

Tjenestens databaser er flyttet til en ny disk på 500GB, så der skal det være plass nok. Den gamle halter videre som systemdisk fordi en full reinstallering vil gi for mye nedetid. Den vil få en provosert reorganisering i løpet av kvelden 8. mars. Dette er en prosess hvor disken får en mulighet til å reorganisere sektorene og legge dataene på sikre steder. Dette vil bare berøre filer knyttet til selve operativsystemet.

Og så langt ser det bra ut? — John Erling Blad (Jeblad) 8. mar 2008 kl. 17:16 (CET)

Automatiske interwikilenker

Det er mulig å lage en form for automatiske interwikilenker som bruker en ekstern wiki hvis en intern side mangler. I enkleste versjon består dette av at det genereres en lenke til et eksternt nettsted hvis den interne siden mangler, uten ytterligere test. I en mer avansert utgave sjekkes det i tabeller for å se hvor siden eventuelt finnes.

Det er flere fordeler med en slik løsning, blant annet at artikler kan få lenket opp forklaringer som ellers har liten relevans for lokalhistorie. For eksempel så vil omtale av et gammelt kraftverk ha relevans, mens det neppe er like relevant å forklare hva som er prinsippene bak en Kaplanturbin, Francisturbin og Peltonturbin.

For å redusere kompleksiteten til problemet, hvis søkesettet er alle oppføringer om et begrep i alle wikier så blir omfanget ekstremt, så begrenses kontrollene til lenker som ikke finnes i den lokale wikien. Disse sammenlignes med en vedlikeholdt tabell over titler i andre wikier som publiserer slike oversikter, og som er av en akseptabel kvalitet. Lenkene vil, om de finnes, bli lyseblå som en ordinær interwikilenke. De kan i tillegg påføres merking med et etterfølgende favicon som indikerer hvor lenken går. — John Erling Blad (Jeblad) 20. feb 2008 kl. 13:37 (CET)

Ser spennende ut, men jeg har en innvending: En av styrkene med en wiki er at man legger røde lenker til ting man vil skrive om selv eller vil at andre skal skrive om. Hvis dette gjøres automatisk vil det vel fort bli slik at det blir høyere terskel for uerfarne brukere for å starte på nye artikler, fordi man i utgangspunktet blir geleidet til en eksterne wiki. Eksemplene dine er gode, turbintyper og denslags blir oftest for detaljert her, men det krever stor omhu i utvalget som kommer inn på lister over artikler. Chris Nyborg (Cnyborg) 20. feb 2008 kl. 17:49 (CET)

Jeg har noen av de samme tankene, men det ser ut som om dette er noe som er hot og diskuteres på andre wikier. Dermed tror jeg det er aktuelt å ha en formening om hva vi skal mene om det. Den største ulempen er at det kan hindre nyskriving av aktuelt stoff. Den desidert største fordelen er at en unngår å bli en konkurrent til rene leksika, og kan isteden spisse aktiviteten mot original forskning. — John Erling Blad (Jeblad) 20. feb 2008 kl. 18:00 (CET)

Malen «thumb» og plassering av bildet

Det er litt vanskelig å plassere bilder optimalt i infobar via malen «Thumb». Inntil videre er dette slått av. Hvis det er mulig å komme opp med en pålitelig metode for plassering av bildet så kan det eventuelt reintroduseres.

Problemet med malen «Thumb» kommer av at plassering i infobar følger rekkefølgen for elementer i teksten, noe som gjør at plassering av bildet blir suboptimal. (Fremmedlandsk for ravende gal) For å slå av visning av bildet på artikkelsider kan align=none brukes. Antakeligvis bør hele metodikken rundt plassering av slike bilder gjennomgås, og forenkles.

En idé er å kunne bruke en ordinær bildelenke, men om den angir «thumb» så omskrives denne på portalsider. Dette løser problemet med den avvikende formen. Det neste er hvordan bildet skal plasseres i en eventuell infoboks. En tanke er noe ala et magic word slik som {{IMAGE}}. Denne har en tabell over alle bilder og kan brukes for å sette inn slike på bestemte plasser. Fordi dette som oftest er en tabell av flere bilder så kan det angis en indeks {{IMAGE:''n''}}. Hvis et bilde identifiseres av {{IMAGE}} så vil det kun brukes der det eksplisitt blir angitt. Portalsider vil ikke bruke {{IMAGE}} og dermed vil bildet vises. Bruken av {{IMAGE}} vil ha store likhetstrekk med <ref> og <references> slik at en del kode kan rappes fra Cite.pm eller omskrives på bakgrunn av denne. — John Erling Blad (Jeblad) 21. feb 2008 kl. 12:43 (CET)

Redigering for uregistrerte

Muligheten til å redigere for uregistrerte gikk nettopp ut, så heretter må alle registrere seg. Det er mulig å gi litt forskjellig rettighet i forskjellige navnerom, slik at uregistrerte for eksempel kan skrive på diskusjonssider.

Det har hele tiden vært planlagt at alle skulle være registrert for å redigere, men de nødvendige endringene har ikke blitt gjort i de underliggende konfigurasjonsfilene. Disse endringene er nå gjort og dermed bortfaller muligheten for å redigere for uregistrerte. Registrer en bruker og logg inn så vil du fortsatt kunne redigere. — John Erling Blad (Jeblad) 20. feb 2008 kl. 13:52 (CET)

Utvidet referanseløsning

Jeg har startet et arbeid for å lage en utvidet referanseløsning. Dette ligger på Wikipedia:no:Bruker:Jeblad/Ref2_og_lenkebot. Noe bakgrunn er på Wikipedia:Dyplenking til samarbeidende tjenester. Det har i det siste vært ytret ønske om mer omfattende lenking til og fra Wikipedia, og hvis det er mulig å få til en finansiering av utviklingsjobben så vil det bli lagd en slik utvidet løsning.

En noe bedre form på omfattende referanselister er vist i Bruker:Jeblad/test2. Istedenfor å få en omfattende tekstblokk inne i den løpende teksten er den trukket ut å plassert innenfor <references> -taggene. Dette passer bedre når en bruker store maler som «Kilde bok» som brukes på bokmålspedia, og når en gjenbruker de samme referansene flere ganger. Når referansene brukes som fotnoter er det antakeligvis bedre å plassere de inne i teksten. — John Erling Blad (Jeblad) 1. feb 2008 kl. 02:41 (CET)

Nytt utseende

Kaffistova har blitt flyttet og har fått nytt utseende. Akkurat nå er det veldig likt Tinget på Wikipedia; grunnen er at det viktigste var funksjonalitet, og ikke utseende i første omgang. Flott om flere blir med på å sette særpreg på siden, enten ved å gjøre endringer selv eller ved å komme med tips til noen med wikierfaring. Praktiske konsekvenser av dette er at nye brukere ikke trenger å forholde seg til merking med <onlyinclude> og at alle endringer på Kaffistova kommer med i overvåkingslisten til de som følger med siden. Chris Nyborg (Cnyborg) 24. apr 2008 kl. 22:16 (CEST)

Søking i Leksikon

Slik det er satt opp nå går søkemotoren ikke automatisk gjennom navnerommet Leksikon: Man kommer dit hvis man taster inn Leksikon:artikkelnavn og treffer rett på, men det er ikke fritekstsøk. Det kunne kanskje være en fordel å ha det som standard, ettersom leksikonet vil dekke en del begreper som det kan ta år og dag før vi får dekket i hovednavnerommet. Det er mulig for hver enkelt bruker å sette sine preferanser på dette, og man kan velge det etter at man har søkt og så kjøre søket på nytt, men det er mindre brukervennlig enn å ha det som standard. Ulempen er at kreves noe mer av hvert søk, som dermed også vil ta noe lenger tid. Chris Nyborg (Cnyborg) 1. mai 2008 kl. 00:33 (CEST)

Endringer i kommuneinfoboksen

Det virker fornuftig å endre kommuneinfoboksn, {{Infoboks kommune}}, slik at den svarer bedre til målsetning for lokalhistoriewiki.no. I første omgang har jeg lagt til et parameter, sammenslåing, hvor man kan legge inn lenker til kommuner som har blitt innlemmet i / slått sammen med kommunen man skriver om (se Gjøvik kommune og Vestby kommune, hvor de er lagt inn). Det kan også tenkes at det er andre ting som er fornuftige å ha med; her er det bare å komme med forslag.

Det er også noen ting som går den andre veien. Hvem som er ordfører / byrådsleder nå er i historisk sammenheng en nokså tilfeldig opplysning. En lenke til Liste over ordførere i x kommune er mer praktisk. Jeg foreslår derfor at hele politikkseksjonen fjernes, og at det i stedet ordnes så lenke til ordførerliste kommer opp automatisk hvis den eksisterer (krever at navnene på slike lister er standardisert, men det bør de uansett være, og jeg kan legge mulighet for manuell overstyring hvis det er noe helt spesielt. Chris Nyborg (Cnyborg) 26. mai 2008 kl. 17:50 (CEST)

Enig! Jeg lurer på om en burde hatt et parameter for tidligere navn da en del kommuner vel kan ha historiske navn som er endret. --Nina Aldin Thune (Nina) 26. mai 2008 kl. 18:14 (CEST)

Godt forslag. Det blir nok en del tilfeller hvor det er tvil om hva som er riktig å gjøre, fordi endring av navn kan være knyttet til sammenslåing der ingen av kommunene skulle «få overtak». Men i noen tilfeller er det en veldig grei opplysning. Legger det inn i boksen, og legger det inn på Horten kommune som er et godt eksempel. Oslo og Trondheim er andre kjente eksempler. Chris Nyborg (Cnyborg) 26. mai 2008 kl. 19:12 (CEST)

Bare sånn teknisk for de med liten erfaring med maler: Det er veldig enkelt å legge til et parameter (en linje); den vil bare være usynlig i de artiklene hvor den ikke er tatt i bruk. Det er mer kronglete å fjerne ting, men ikke verre enn å gå gjennom alle artikler som bruker malen og fjerne de linjene som skal bort.

Også: Det er ikke tatt stilling til utseendet her, bare innholdet. Vi må gå gjennom hvordan infoboksene skal se ut, og den som ligger på Nidarosdomen er mange enige om at er en pen boks. Det er flere elementer som skal tilpasses litt, og kanskje lager vi den litt bredere enn den på Nidarosdomen for at standarden skal kunne romme mange bruksområder, men ikke så bred som boksen er i dag. Chris Nyborg (Cnyborg) 26. mai 2008 kl. 19:20 (CEST)

Mer historieorienterte kommuneinfobokser er helt i tråd med hva vi på NLI ønsker oss. Vi har jo også tilgang til en database med detaljerte opplysninger om sammenslåinger/delinger fra "tidenes morgen", inkludert navneendringer, som jeg håper det vil være mulig å dra nytte av. I tillegg til det dere har nevnt, kan jo slikt som grunnleggelsesår, befolkningsutvikling, lenke til historiske kart være interessante opplysninger. --Marianne Wiig 27. mai 2008 kl. 11:11 (CEST)

Jeg lagde et ekstra infobokselement, {{Infoboks hel rad}}. Denne setter inn tekst sentrert over begge spalter. Dersom man ønsker det mot marg kan posisjon overstyres med parameteret align. Denne er nå tatt i bruk for å automatisk legge inn lister over ordførere. Den leter etter «Ordførere i navn». Dette betyr at alle ordførerlister enten må ha slikt navn, eller at de må ha omdirigering til slikt navn. Jeg har selv også brukt formen «Liste over ordførere i navn», men det virker helt unødvendig å ha med liste over. Fordelene med å ikke ha det er at det er en mer intuitiv tittel for de uten wikipedia-erfaring, det er en kortere tittel å taste inn i søkefelt, den dukker opp på rett alfabetisk plass i artikkellister og ikke minst inviterer den til å lage noe mer enn en liste, ettersom det er et glimrende sted å kombinere en liste med korte biografiske opplysninger med lenker til lengre artikler om de enkelte. Ofte er ikke lesere så interessert i å vite alt om de enkelte ordførere at de vil bla seg gjennom titalls artikler, men de ønsker å få vite noen grunnleggende opplysninger. Det er også en god invitasjon til de som sitter på greie kilder over slikt men ikke har nok opplysninger til å opprette artikler om hver enkelt. Vi kan lage en mønsterartikkel for dette.

Når det gjelder historiske kart er det enkelt å lage lenke til det ved hjelp av samme infobokselement.

Grunnleggelsesår legges det inn felt for nå.

Befolkningsutvikling er jeg usikker på, og vil gjerne ha noen tanker om hvordan det skal presenteres. Kanskje er ikke boksen det beste stedet for det, og da kan vi i stedet lage en standardtabell som det er lett å legge inn i artikkelen og lett å legge inn data i for brukere som er uvant med å lage tabeller. Skal vi ha det i boksen kan vi risikere at det blir mange linjer for enkelte kommuner, så det må avgrenses på en eller annen måte. En mulighet er å sette noen faste år, f.eks. befolkning 1801, 1875, 1900, 1940, 1950, 1980, 2000 – dvs. et utvalg år med folketellinger. Men samtidig er det aktuelt å få med data for år med kommunesammenslåinger. Det må også settes en standard for historiske data: Hvordan definerer man 1801 hvis det skal med (prestegjeld fungerer ofte greit, ettersom kommunegrensene ofte følger dem, men det er unntatt), og hva skal man oppgi som historiske data (dagens kommune med alle tidligere kommuner sammenlagt, eller datidens kommune med det navnet; sistnevnte løsning gir et helt annet bilde enn førstnevnte). Særlig den siste problemstillingen fører til at jeg heller mot at dette er mer stoff for en separat tabell der ting kan forklares enn en infoboks hvor data helst skal være selvforklarende. Chris Nyborg (Cnyborg) 27. mai 2008 kl. 20:40 (CEST)