Lokalhistoriewiki:Diskusjonsforum

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

• Kristiansand stiftamt‎ [1]
• Christiansand stiftamt‎ [2]
• Vardøhus amt‎ [3]
• Tingvoll kommune‎ [4]
• 1890‎ [5]
• 1839‎ [6]
• Fredrikstad festning‎ [7]
• 1565‎ [8]
• Kaffistova:Ny server‎ [9]
• Hans Siewers‎ [10]
• Romsdals amt‎ [11]
• Portaldiskusjon:Kaffistova‎ [12]
• Brukerdiskusjon:Olve Utne‎ [13]
• MediaWiki:Sitenotice‎ [14]
• MediaWiki:Common.css‎ [15]

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.

Norsk historisk leksikon. Kultur og samfunn ca. 1500 – ca. 1800 Hovedside  | Forord  | Forkortelser  | Forfattere  | Artikler  | Kilder og litteratur

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)