Lokalhistoriewiki:Diskusjonsforum

Fra lokalhistoriewiki.no
Sideversjon per 24. apr. 2008 kl. 19:54 av Cnyborg (samtale | bidrag) (rydding pågår)
Hopp til navigering Hopp til søk

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:KaffistovaStryk 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

Mal:ForumVed å 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

Mal:ForumDet 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 «Abildgård (gammelnorsk apaldrsgarðr, m., egentlig eplehage), frukthage. Jamfør aldegård.
Historisk leksikon.jpg
Norsk historisk leksikon. Kultur og samfunn ca. 1500 – ca. 1800
Hovedside  | Forord  | Forkortelser  | Forfattere  | Artikler  | Kilder og litteratur
Copyright
Denne artikkelen, med evt tilhørende illustrasjoner, er hentet fra Norsk historisk leksikon 2. utgave, 3. opplag (2004), og er beskyttet av opphavsrett. Den publiseres på lokalhistoriewiki.no etter avtale med Cappelen Damm forlag. Formateringen er tilpasset wikipublisering og forkortelser er skrevet helt ut, men teksten er ellers ikke endret i forhold til den trykte utgaven av oppslagsverket. Videre bruk av tekst eller illustrasjoner forutsetter avtale med Cappelen forlag.

» 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)