Lokalhistoriewiki-samtale:Diskusjonsforum

Fra lokalhistoriewiki.no
Hopp til navigering Hopp til søk
Her kan du snakke om selve diskusjonsforumet! Det finnes tilsvarende samtalesider for de fleste artikler i wikien. Ting som har med artiklene å gjøre tas opp på hver enkelt artikkels samtaleside. Der vil det som oftest fremgå hvem som følger opp disse.
Arkiv

Bildepolitiet

Jeg har en liten politiaksjon med bilder nå. Bilder som havner i Kategori:Bilder uten lisens må fikses før vi går ut offentlig, slik at alt er ryddig og klart. Helst bør det meste være ryddet før presentasjonen for departementet. Det havner nok noen flere bilder i kategorien, jeg har ikke gått gjennom absolutt alt. Det er også grunn til å være varsom med å bruke bilder som ikke kan lastes opp under fri lisens. Det er ikke tatt noen endelige avgjørelser, men det har hele tiden vært en tanke i prosjektet at stoffet skal kunne gjenbrukes lokalt uten at brukerne skal måtte bekymre seg om opphavsrettslige problemer. Vi må nok se på noen spesielle løsninger der, men det er greit å ha ting på plass før vi bruker for mange slike bilder. Chris Nyborg (Cnyborg) 19. feb 2008 kl. 23:34 (CET)

Jeg tror jeg kan riste en liste ut av ermet som blir automatisk vedlikeholdt og som lister alle bilder uten lisens. — John Erling Blad (Jeblad) 20. feb 2008 kl. 10:00 (CET)

Portal Hjelp

Et første utkast er oppe og igang. Jeg regner med det blir en del diskusjon om hvordan den skal struktureres. — John Erling Blad (Jeblad) 20. feb 2008 kl. 10:01 (CET)

Har begynt på en litt mer lavtersklet brukermanual som vil komme i tillegg til / istedenfor en del av de eksisterende sidene. Kommer tilbake med mer info. Siri Johannessen (Siri J) 20. feb 2008 kl. 10:15 (CET)
En slik brukermanual tror jeg med fordel kan gis en prominent lenking fra hjelpeportalen. Kanskje den bør stå fast som første artikkel. — John Erling Blad (Jeblad) 20. feb 2008 kl. 10:25 (CET)
Tror det vil være bra å dele dette opp i brukermanualer og stilmanualer. Idag er dette blandet i en og samme manual. Intuitivt ville jeg ikke lett etter basis-howto's i en stilmanual...
Stilmanualene bør gi holdepunkter mht "hvordan setter jeg opp en artikkel med malverk" mens brukermanualene gir en basis mht "hvordan virker denne wikien og hvordan legger jeg en lenke (f.eks)".
Brukermanualene vil jeg legge opp slik at den fungerer for folk uten wikierfaring så de kommer inn og kan komme igang på egen hånd, samt at de vet veien til mer informasjon. De som er mer drevne på wiki kan da hoppe over disse i første omgang, og gå rett på stilmanualene.
Dette er etter min mening en noe mer logisk inndeling og navngiving, siden jeg regner med at en del av brukerne kan være nye i forhold til wiki-konseptet og ha behov for en noe mer basisinnføring i hvordan ting virker. Siri Johannessen (Siri J) 20. feb 2008 kl. 11:10 (CET)

Portal Kaffistova

Jeg har tidligere drodlet på en portal som har samme funksjon som Kaffistova, men som er basert på portal-teknikker istedenfor å ha alt i en lang remse. For å få til dette, og for at brukere skal slippe å kategorisere sine bidrag, så må hele Kaffistova, eller hva den blir kalt, legges i et eget navnerom. Fordi flytting mellom navnerom er litt problematisk må navnet som velges være et som er akseptabelt og informativt, og som kan brukes i lang tid. Navnet Kaffistova er hentet fra samisk wp der de bruker Gáffestohpu, og ganske mange likte det.

Hvis det opprettes en side i et navnerom, for eksempel Kaffistova, så vil denne legges til på en slik portalside. Det er noen alternative strategier for organisering av siden En er å liste siste nye tråd øverst og med de siste tråder med svar nedenunder. Jeg tror ikke jeg får hindret dobbeltoppføringer. En annen er å bare liste tråder etter når de opprettes, og med viktige tråder låst øverst. Etter hvert vil det kunne bli mange slike. En tredje er å bruke den øverste til en nyhetsbulletin mens de nederste er mer forumorienterte.

Ticker som er lista ute til høyre kan med fordel liste alle de siste trådene, eventuelt alle de siste innleggene. Hva tråder som er mest lest tror jeg er uinteressant, men det kan være at en temporær listing av mest lest er aktuell, da dette kan rulle inn gamle debatter om de igjen blir aktuelle. — John Erling Blad (Jeblad) 20. feb 2008 kl. 10:24 (CET)

Det er også aktuelt å kategorisere stoff slik at det er enklere å finne frem i gamle diskusjoner. Ikke minst ideutkast, metoder, regler, spørsmål (faq) osv. — John Erling Blad (Jeblad) 20. feb 2008 kl. 10:35 (CET)
Portalen blir hetende Portal:Kaffistova inntil videre. Tilsvarende heter navnerommet «Kaffistova». — John Erling Blad (Jeblad) 20. feb 2008 kl. 10:42 (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. — John Erling Blad (Jeblad) 20. feb 2008 kl. 13:52 (CET)

Hjelp!

Hvem har lagt inn pop-upen som hver gang en side endres manifesterer seg og minner meg om at "Proofread: undefined"? Siri Johannessen (Siri J) 21. feb 2008 kl. 18:30 (CET)

Oppfrisk nettleserens mellomlager. Det snek seg ut en test for debugging av boksider. I Mozilla/Safari/Konqueror; hold nede Shift mens du klikker på Reload (eller trykk Ctrl-Shift-R). I Internett Explorer; trykk Ctrl-F5. I Opera; trykk F5. — John Erling Blad (Jeblad) 22. feb 2008 kl. 12:38 (CET)

Bruker-/Stilmanualer

Ser at de er fordelt over to ulike navnrom, hvor praktisk er dette? Vil det ikke være bedre å samle disse i ett navnrom? Siri Johannessen (Siri J) 22. feb 2008 kl. 11:55 (CET)

Jeg mener alt som er «manualer» kan flyttes til hjelperommet. Det som er regler og annet definerende stoff beholdes i prosjektrommet. Jeg har en vag formening om at prosjektrommet trenger noe høyere grad av beskyttelse enn hjelperommet. Det står en notis om dette på diskusjonssiden til Portal:Hjelp. Muligens kan en som første oppføring på denne siden ha en grunnleggende introduksjon for nybegynnere. — John Erling Blad (Jeblad) 22. feb 2008 kl. 12:42 (CET)
Om ingen protesterer, flytter jeg alle manualsidene fra Lokalhistorie: til Hjelp: i løpet av kvelden. Vurderer også å endre rekkefølgen på lenkene i Mal:Brukermanual, har litt problemer med å se logikken der. Siri Johannessen (Siri J) 22. feb 2008 kl. 13:39 (CET)
Helt fint for meg at det flyttes; rotet i navn er en arv fra Wikipedia. Rekkefølgen er det ingen logikk i; det er lagt inn mer eller mindre tilfeldig for å få med mest mulig. Målet mitt har så langt bare vært å få inn en del slik at andre kunne kikke på det etterhvert som det kom inn flere brukere. Chris Nyborg (Cnyborg) 22. feb 2008 kl. 14:20 (CET)
Tror jeg har gått igjennom og flyttet det som kunne flyttes til Hjelp: Det ligger fremdeles et antall sider i Lokalhistorie:. Etter min mening bør de bli i det navnrommet da de er nærmere retningslinjer enn hjelpesider. Dette gjelder Project:Språknormer; Project:Navnekonvensjoner; Project:Lister; Project:Kildekritikk; Project:Kategorier. Jeg fant også 3x2 sider som kommer til å bli flettet etterhvert, Kategori:Sider som bør flettes. Jeg hører gjerne hva andre tenker rundt dette.
En ting jeg forundret meg over var passusen om original forskning på siden om kildebruk. Det virker gå imot en del av de målsetningene jeg hørte under helgen i Bergen.
Siri Johannessen (Siri J) 23. feb 2008 kl. 02:21 (CET)
Hm, dette må vel det oom original forskning være feil… Jeg mener som deg retningslinjer bør være i prosjektrommet og at manualer går til hjelperommet. Har også sett at et par sider ligger mer eller mindre dobbelt opp. — John Erling Blad (Jeblad) 23. feb 2008 kl. 15:57 (CET)
Ja, hele hjelp:Kilder må skrives om så den samsvarer med intensjonene her. Støtter grunnleggende manualer under hjelp og retningslinjer under prosjekt. -- Olve Utne 24. feb 2008 kl. 13:47 (CET)
Hjelp:Kilder er nok mest nyttig i forhold til den praktiske delen; som en del andre hjelpetekster/retningslinjer fra Wikipedia kan størstedelen brukes, men en del må skrives om. Når det gjelder biten om original forskning ble det fjernet fra Project:Hva Lokalhistorie ikke er, men jeg hadde ikke lagt merke til den her. Det vil garantert komme noen slike overraskelser under arbeidet med disse tekstene, og da er det bare å fjerne det eller skrive om slik at det passer dette prosjektet. Chris Nyborg (Cnyborg) 24. feb 2008 kl. 23:39 (CET)
Ok, da kjører jeg igang igjen i kveld, etter jobben. Vil først sette sammen en innledning for folk som er helt blanke, men kommer nok til å prøve å ta andre ting i samme slengen. Om dere kommer på spesifikke ting jeg bør ha i tankene, så dropp gjerne ei linje eller to på diskusjonssiden min :) Ville sette pris på om en av dere, som har jobbet mer aktivt med kildebruk og slikt kunne skrevet om den siden. Siri Johannessen (Siri J) 25. feb 2008 kl. 02:46 (CET)
Jeg kan gjerne kikke på kildesiden. Har forøvrig begynt litt på Project:Kildekritikk, som skal inngå i teoridelen, dvs. opplæring i historiefaget. Chris Nyborg (Cnyborg) 25. feb 2008 kl. 17:48 (CET)
Det var en lettelse :) Jeg tror og vi bør se på en side om hvordan kilder kan angis (litteraturlister og slikt). Det er flere standarder, men kan det ikke være greit å ha en som er "anbefalt" for dem som ikke har en forkjærlighet? Tror det vil gjöre ting enklere for begynnere her... Siri Johannessen (Siri J) 25. feb 2008 kl. 19:52 (CET)

Publisering av konfigurasjonen

Hvis ingen har sterke motforestillinger så kommer jeg til å publisere konfigurasjonen av Mediawiki-motoren. Det betyr at andre nettsteder slik som Kunsthistorie kan gjenbruke deler av vårt oppsett. Eksempelet er litt fake i og med at jeg er involvert i dette. Det som blir publisert er en prosessert utgave av LocalSettings.php hvor passord og lignende er fjernet. I tillegg vil katalogene /extensions/ og /skins/ bli gjort tilgjengelig for nedlasting. Senere vil konfigurasjonen bli gjort tilgjengelig på en langt grundigere måte i ABMu sitt produksjonssystem. Konfigurasjonen vil da publiseres via SVN-repositories. — John Erling Blad (Jeblad) 22. feb 2008 kl. 16:57 (CET)

Høres flott ut for min del. Chris Nyborg (Cnyborg) 22. feb 2008 kl. 19:30 (CET)

Kaffistovas fremtid

Jeg foreslår at vi flytter «Kaffistova» til diskusjonssiden for Portal:Kaffistova, og at vi bruker portalsiden for viktige oppslag og viktige diskusjoner. Diskusjonssiden bruker vi som er generell møteplass for smådiskusjoner på lik linje med de andre diskusjonssidene for portaler. Skal ting tas vare på så må de løftes frem på portalen som egne tråder, ellers vil de bli liggende på diskusjonssiden til de triller av og forsvinner i Glemselens Hav. Diskusjoner ramler i Glemselens Hav ved behov eller etter en gitt tid. Dette gjør at viktige diskusjoner tas vare på samtidig som vi har en sentral plass for diskusjoner. En tråd kan da åpnes på diskusjonssiden til portalen, pågå en tid før det påvises at den er viktig og deretter flyttes ut på en egen side.

For de som er redd de mister oversikten i disse diskusjonene så er det to metoder som bedrer oversikten. Det ene er funksjonen «Relaterte endringer», og ikke minst «Siste endringer). Den siste lager en svært ryddig fremstilling av diskusjoner når disse ligger i et eget navnerom. Det er også mulig å legge inn en js-snutt slik at alle Kaffistove-diskusjoner i egne tråder blir merket i de vanlige Siste endringer som om de var satt på overvåking. — John Erling Blad (Jeblad) 22. feb 2008 kl. 22:55 (CET)

Thumb

Det er en feil ifm denne malen slik at bildet ikke vises på en del sider. Se blant annet Nikolai Astrup. — John Erling Blad (Jeblad) 25. feb 2008 kl. 10:23 (CET)

Inklusjon av definerende artikkel i artikkellister

Den definerende artikkelen blir inkludert som en vanlig artikkel. Det må legges inn et eksklusjonsstatement i {{Portal sisteteaser}} og {{Portal randomteaser}}. — John Erling Blad (Jeblad) 25. feb 2008 kl. 10:26 (CET)

Quiz

Det mangler fortsatt portal og en del strukturer for Quiz. Dette skulle egentlig ikke være med her men ser ut som det har grodd inn ganske mange steder. Dermed er det vel like greit å gjøre det skikkelig. — John Erling Blad (Jeblad) 25. feb 2008 kl. 10:27 (CET)

Siste endringer

Flytter litt rundt på dette og ser hva som fungerer. Jeg tror det gjør det lettere å få oversikt ved å kunne sjekke portaldiskusjoner og kaffistova separat. Mens jeg satt med dette så jeg en annen greie, og det er at en ønsker å se noe ala «alle endringer relatert til en utvalget som brukes på en portal, og endringer på portalens egen side og diskusjonsside». Noen slik funksjonalitet finnes ikke for øyeblikket, men ville gjøre det mulig for meg å sjekke endringer for et lite antall portaler istedenfor som nå å sjekke endringer for hele landet.

Jeg har tidligere eksperimentert med «lister fra A til Å», og disse kan muligens brukes som data for Spesial:relaterte endringer. Se for eksempel Spesial:relaterte endringer/Valdres fra A til Å. Hvis dette er riktig (og farbart) så kan det på disse sidene legges på en mal som referer portalen og dennes diskusjonsside. Da er vi mer eller mindre i boks med en slik funksjon. Det eneste som trengs i tillegg er et lite javascript som legger inn en lenke til den aktuelle siden i venstremenyen for «endringer», eventuelt kan dette ligge på portalsidene. Som standard bør imidlertid en slik side for Kaffistova bli referert i venstremargen.

Det ser ut som dette er mulig, men det er noe cache-problematikk. — John Erling Blad (Jeblad) 25. feb 2008 kl. 11:27 (CET)

Organisering av stoffet

I andre sammenhenger (aviser) organiseres gjerne stoffet i flere hierarkier etter hvordan det brukes. En metode som er brukt en del, om ikke særlig bevist, er ett abstrakt hierarki og et fysisk hierarki. Det første kan vi da oversette med kategorier og det siste med portaler. Disse er ofte sammenfallende, men ikke alltid. Vi har valgt å gjøre de sammenfallende på noen punkt og dette gjør at vi må lage metoder for å oversette fra en struktur til en annen med de problemene det introduserer.

Vi kan velge å gjøre dette på en annen måte. Hvis vi aksepterer at disse er forskjellige så kan vi isteden merke artiklene med hvilken portaler som skal brukes for publisering av stoffet. Da kan en artikkel om Sigurd Islandsmoen kategoriseres som norsk komponist, mens den har en oppføring for publisering på Portal:Sør-Aurdal. Personen trenger ikke kategoriseres med tilhørighet til Sør-Aurdal overhodet. Typisk vil dette skje med påføring av en mal som angir denne tilhørigheten.

Forskjellen mellom den skisserte metoden og metoden med bruk av kategorier er at den ene tvinger portalstrukturen til å reflektere kategoristrukturen, mens den andre gjør at disse er friere. Ulempen er at manglende påføring av portaltilhørighet blir en relativt usynlig feil. Dette er litt uheldig.

En siste fordel med eksplisitt påført portaltilhørighet er at dette åpner for ad hoc tematiske portaler uten å forurense kategoristrukturen. Dette kan ha en del fordeler hvis noen ønsker å lage portaler som går på tvers av den de eksisterende kategoriene. — John Erling Blad (Jeblad) 25. feb 2008 kl. 11:53 (CET)

Internett...

Har dessverre bare øyeblikksvis Internett og null bredbåndstelefon i dag... -- Olve Utne 25. feb 2008 kl. 12:19 (CET)

Brukerboks

Har begynt litt i det små med slike, foreløpig er de laget for Mal:Bruker-Gamlebyen i Fredrikstad og Mal:NLI-bruker‎. Jeg undres på om det ikke bør komme et par til, f.eks. for historikere med og uten utdannelse, og den tekniske gjengen her (Olve, John og Chris) - hva tror dere? Det kan være at kategoriene som nå brukes, kan skiftes ut med dynamiske lister etterhvert. Jeg har valgt rettfrem-steinalder-løsningen, så kan det hives om til mer fancy stuff når basisen er på plass... Siri Johannessen (Siri J) 26. feb 2008 kl. 01:01 (CET)

Skal se om vi kan få til noe fancy dynamikk og uten å ty til kategorier, men det blir senere. — John Erling Blad (Jeblad) 26. feb 2008 kl. 01:53 (CET)

Bold manualer

Linje to oppe til høyre som i all hovedsak er manualer (eller vil bli det) blir nå bold når en står på en aktuell side. Dette er et javascripthack for å unngå å slå av sidebarcache. Dette ville gjort at alt ble mye treigere. Isteden mister vil litt visuelt for de som slår av javascript, og får en tanke sløvere respons men det er så lite at det er umulig å oppfatte. Prøv å gå til Hjelp:Hvordan man redigerer en side og lenken skal bli bold hvis nettleserens mellomlager er tømt. — John Erling Blad (Jeblad) 26. feb 2008 kl. 01:57 (CET)

Antall aksesser på nettstedet

Over siste 11 dagene har det vært omtrent 140 000 aksesser på nettstedet. Rundt 40 000 er robotaktivitet fra min side. Det ser ikke ut som om nettstedet er ukjent lengre… ;) — John Erling Blad (Jeblad) 28. feb 2008 kl. 14:14 (CET)

Alternativ organisering av Kaffistova

En alternativ organisering, flere synes løsningen vi bruker nå er uoversiktelig (se blant annet Kaffistova:Lenking på bidragsyters brukernavn), er at vi lar (hele) portalen «Kaffistova» bli en nyhetsavis for nettstedet og at diskusjonssiden blir helt sammenlignbar med andre portaldiskusjoner. Da markerer vi tydeligere forskjellen på portalsiden og diskusjonssiden. Navnerommet «Kaffistova» vil da utgå. Tråder som nå ligger i eget navnerom vil da flyttes til navnerommet «Portaldiskusjon» og det lages egne oversiktslister for diskusjonssidene. Vi vil da få større likhet mellom portalene, uavhengig av funksjon, og arkivering og bruk av tråder vil bli konsistent. Vi trenger fortsatt en klargjøring på hva som plasseres i en tråd og lever videre, relatert til hva som ramler i bit bucket. — John Erling Blad (Jeblad) 29. feb 2008 kl. 02:07 (CET)

Tråder arkiveres på separate undersider for den aktuelle diskusjonssiden, og vil hentes inn automatisk ved behov. I toppen av diskusjonssiden lages det en egen seksjon med transkludering av tråder på bakgrunn av når den ble sist endret. Det betyr at det må lages en egen ingress når tråden arkiveres, og det betyr også at tråden kan ligge i denne seksjonen en god tid før den ruller ut. Tråder som arkiveres plasseres på en egen arkivside hvor de ligger en tid før de fjernes. Hvis det er nødvendig å hente tilbake tidligere diskusjoner som ikke er flyttet til egne tråder så kan de hentes fra denne siden. Arkivløsningen og interaksjonen med undersider gjøres generell slik at den kan brukes på alle diskusjonssider, om det er for portaler eller andre sider, og ikke minst på brukernes diskusjonssider. — John Erling Blad (Jeblad) 1. mar 2008 kl. 21:24 (CET)


Teknisk: Mal:Wikipedia

Siden endringen ble foretatt som gjør at lenkingen til no/nn blir korrekt ser det ut til at alle maler som ikke har den siste variabelen fylt inn malfunctions. De gir følgende output: Denne artikkelen er helt eller delvis basert på artikkelen «[[:wikipedia:no:{{{2}}}|{{{2}}}]]» Kan noen fikse dette med en bot eller lignende? Siri Johannessen (Siri J) 1. mar 2008 kl. 04:28 (CET)

Fikset. Nå har malen en if-funksjon; hvis parameter 2 (artikkelnavnet) er lagt inn i malen vises det, hvis ikke vises artikkelnavnet. Da skal det bare være nødvendig å skrive inn artikkelnavnet hvis det avviker fra Wikipedias. Chris Nyborg (Cnyborg) 1. mar 2008 kl. 16:17 (CET)
Flott du tok den! Siri Johannessen (Siri J) 1. mar 2008 kl. 20:05 (CET)

Artikkelnavn - standardisering eller ikke?

Er ganske sikker på at dette har vært oppe her tidligere, men kan ikke finne tråden nå. Mht stedsnavn som finnes på flere steder, som Trolldalen eller Vik, eller bydeler som bør tilknyttes byen via navnet, trenger vi en måte å skille dem ad på. I øyeblikket har vi et par muligheter - som begge brukes her:

  • Cicignon i Fredrikstad - intuitivt greit søkbar, bortsett i tilfeller der vi har muligheten for å velge mellom i og på, som Melløs på Moss. Den koster mer skrivejobb i tilfeller der man bare vil ha [[Melløs på Moss|Melløs]] vist i artikkelen, det er så.
  • Brattrud (Bagn) er den andre måten, her slipper vi avveining mellom preposisjoner, og det er en fordel når man bare vil bruke selve navnet i artikkelen, [[Brattrud (Bagn)|]] er da formen.

For meg er en ting tydelig, vi trenger omdirigering på de andre formene - men spørsmålet er om vi bør søke å sette en standard her eller ikke? Slik det er nå synes jeg vi halter til begge sider... Siri Johannessen (Siri J) 2. mar 2008 kl. 01:11 (CET)

Jeg tror valget gir seg selv i en del tilfeller, men også at når noe har lokal karakter så vil vi få navnekonflikter og siste formen må brukes. Den siste er det også, såvidt jeg har forstått, en tradisjon for i oppslagsverk. På bokmålsutgaven av Wikipedia brukes siste formen, mens nynorsk bruker første formen. Kanskje vi bare må gjøre et valg? — John Erling Blad (Jeblad) 4. mar 2008 kl. 07:47 (CET)

Bilder med overdekking

Jeg tror det stadig vil dukke opp situasjoner der det finnes et bakgrunnsbilde, og så er det flere lag med overdekking på dette som slås av og på. Typiske eksempler er kart hvor overdekkingen viser brannområder. Dette kommer til å bli brukt i så mange tilfeller at det bør implementeres en standard løsning. Denne bør også støtte nettlesere uten javascript. — John Erling Blad (Jeblad) 5. mar 2008 kl. 13:48 (CET)

Det stemmer det du sier her, det er en av mulighetene vi har diskutert blant annet i forbindelse med visualisering av hvordan bybrannene raserte Gamlebyen i flere omganger. Fint du tar det opp! Siri Johannessen (Siri J) 5. mar 2008 kl. 14:36 (CET)
Dette kan gjøres med en mal og litt javascriptmagic. — John Erling Blad (Jeblad) 5. mar 2008 kl. 14:40 (CET)

Toppkategori?

Slik det er nå fungerer prosjektkategorien (p.t. «Kategori:Lokalhistorie») både som prosjektkategori og som toppkategori. Noen som har noen motforestillinger til å flytte den tematiske toppkategorien til Kategori:Kategorier (eventuelt Kategori:Toppkategori e.l.), slik at Kategori:Lokalhistorie (eller hva prosjektnavnet eventuelt vil endres til) kan forbeholdes prosjektrelaterte metasider? -- Olve Utne 5. mar 2008 kl. 20:19 (CET)

Kategori:Kategorier tror jeg er best. Kategori:Lokalhistorie er en salig blanding, så det er greit å samtidig tenke over om noe kan/bør organiseres annerledes. Chris Nyborg (Cnyborg) 5. mar 2008 kl. 21:06 (CET)
Re: Kat.:Kategorier: Helt enig.
Re: Kat.:Lokalhistorie: Ja, absolutt. Når vi får ut de vanlige artikkelkategoriene, så blir det nok litt mindre overveldende å gå løs på en grundig og nødvendig opprydding der også, ja. -- Olve Utne 5. mar 2008 kl. 21:46 (CET)
Har allerede trukket ut de rene hjelpesidene fra Lokalhistorie: Etterlot sider som var mer policyrettet. Siri Johannessen (Siri J) 5. mar 2008 kl. 22:07 (CET)

Oversiktssider for endringer

Det må lages noe for å få sider av typen Spesial:Relaterte_endringer/Portal:Kaffistova fra A til Å til å oppdatere som de skal. Vi kan muligens gjøre en greie som sørger for oppdatering på daglig basis, eller i timesintervaller eller noe i den gata. Vi kan også lage en sak som garanterer en maksimal tid etter oppdatering. — John Erling Blad (Jeblad) 8. mar 2008 kl. 23:37 (CET)

Brukerbokser

Etterhvert som det kommer flere brukere til, fra ulike geografiske områder / kommuner spørs det om ikke de områdespesifikke brukerboksene bør kunne finnes via portalene. Enten at bruker-kategorien lenkes derfra, eller også at det vises at det finnes en mal for dette. For Gamlebyens del tror jeg det beste stedet vil være i headeren for Vollane. Hva tror dere? Siri Johannessen (Siri J) 11. mar 2008 kl. 11:49 (CET)

Jeg tror det er en god idé. Jeg har lurt på om det er mulig å lage en seksjon i starten på diskusjonssidene som har en del info og henvisninger. Så kan det i denne seksjonen ligge noen faste standardlenker, blant annet til en oversikt over hvem som jobber med de forskjellige tingene, eller det kan være en boks med lenker rett til brukerne. I toppen av siden bør det også være listet opp essensielle fagspesifikke hjelpesider. Hvis en søke etter hjelp om landbrukshistorie så vil en finne dette via Portaldiskusjon:Landbrukshistorie. Hvis en søker etter hjelp om Gamlebyen i Fredrikstad så finner en dette på Portaldiskusjon:Gamlebyen i Fredrikstad. Disse lenkene vil da typisk gå til hjelperommet. I toppen kan det også legges en boks som lenker til tidligere diskusjoner hvor det er aktivitet. Vi bør få til en eller annen arkivering av tidligere diskusjoner, og jeg tror denne bør legge opp til at tidligere diskusjoner «triller over på en arkivside» etter en gitt tid. De slettes deretter fra denne siden etter ytterligere en tid. Hvis de er av en slik natur at de skal være tilgjengelig over lang tid så må det opprettes en egen underside for diskusjonen. Det er sikkert mer som bør i en slik standardtopp (eller boks) for disse diskusjonssidene. — John Erling Blad (Jeblad) 12. mar 2008 kl. 23:43 (CET)
Enig med Jeblad i at dette høres bra ut, og at det kan være lurt med en seksjon med praktiske lenker. I tillegg til det som nevnes om hjelpesider ser jeg for meg at det i en del tilfeller kan være aktuelt med et utvalg av stilmanualer som er spesielt relevante for prosjektsiden. Chris Nyborg (Cnyborg) 12. mar 2008 kl. 23:47 (CET)




Undersider

Jeg antar det er aktuelt med undersider i portalrommet, i hjelperommet og i prosjektrommet. Noe annet sted? Diskusjoner som potensielt må arkiveres trenger vel også slikt. — John Erling Blad (Jeblad) 14. mar 2008 kl. 22:08 (CET)

Blir det opprettet et kildenavnerom bør nok det ha undersider; jeg ser for meg at det kan løse noen problemer. Går ut fra at hovednavnerommet får undersider, det er praktisk i forhold til omfangsrike lister. Chris Nyborg (Cnyborg) 14. mar 2008 kl. 23:48 (CET)
Brøkstrek har en lei tendens til å dukke opp i titler og kan lage problemer. Sjekket og det ser ikke ut som om dette er i bruk på Wikipedia. Kanskje vente å se hvor dette er nyttig? Eneste stedet hvor jeg vet det er praktisk er i portal-rommet, men der er det også nokså nødvendig. — John Erling Blad (Jeblad) 15. mar 2008 kl. 02:26 (CET)
Mm, virker som om det er løst på andre måter, f.eks. ved å bruke brøkstrek selv om det ikke utløser samme funksjon som en underside. Det fungerer i og for seg helt greit i hovednavnerommet, ting er bundet sammen på andre måter. Så vi løser det uten undersider. Chris Nyborg (Cnyborg) 15. mar 2008 kl. 13:09 (CET)

Lokalhistorie:Cite

Jeg har startet å skrive på utvidelsen Cite2. Denne er, tiltross for navnet, det som brukes med taggene <ref> og <references>. Det som er tanken er at denne utvidelsen skal lette arbeidet med referanseskriving. Stemningen er loddet hos noen innholdsleverandører og det jeg trodde ville være nokså vanskelig å få til er blitt mulig gjennom den store interessen for Wikipedia hos disse aktørene. Jeg håper å få til en avklaring med noen av dem i løpet av relativt kort tid.

Versjonen av Cite som brukes på denne wikien bruker allerede metoden som er nevnt helt perifert med å legge definisjonen av alle referanser i references og navngi dem der. Det er ingen støtte for de andre teknikkene. — John Erling Blad (Jeblad) 15. mar 2008 kl. 02:34 (CET)

Lokalisering av Quiz

Utvidelsen Quiz er nå lokalisert til bokmål og nynorsk. — John Erling Blad (Jeblad) 15. mar 2008 kl. 02:38 (CET)

Utvidelsen Call

Jeg har lagt inn en utvidelse kalt «Call» som er et lite verktøy for å manipulere maler. Dette verktøyet gjør det mulig å kombinere parametre til maler med dynamiske lister og dermed kan et stort antall oversiktslister lages systematisk via noen få maler. For eksempel kan kommuneportaler få lenker til lister over artikler som ser ut og oppfører seg som ordinære kategorier, men som er skapt av dette verktøyet i kombinasjon med dynamiske lister. Ett eksempel er lista Garder i Aure som er en side som ikke gjør noe annet enn å holde en mal. Samme siden kan lages med dette verktøyet Garder i Aure (call). I det første tilfellet går lenken til en ordinær side, mens den i det andre tilfellet går til en spesialside. Forskjellen betyr et drastisk mye mindre vedlikeholdsbehov for oversiktssider som skal brukes på alle landets kommuner. Vi kan faktisk vurdere å lage alle portaler på denne måten, om vi aksepterer at alle blir like og at de blir noe tyngre for serveren å dra rundt. Det er imidlertid ikke i dette tilfellet verktøyet er best, men når det brukes til å lage aggregerte oversikter av to elelr flere kategorier. Potensielt kan alle rollekategorier kombineres med geografi, noe som gjør at vi får NxM aggregerte kategorier. Isteden kan vi bruke dette verktøyet i kombinasjon med noen maler. Hva med å syntetisere superkategorier over tynt fylte fylkeskategorier? Se resultatet på Kirker på Østlandet. — John Erling Blad (Jeblad) 15. mar 2008 kl. 03:07 (CET)

Apropos dette, se #Gårdskategorisering i forhold til dynamiske lister i kommuner. Det er ikke nødvendig å kombinere to kategorier for å få til en gårdstabell. Det å trekke ut oversikter for regioner virker veldig fint, det kan være bra både for landsdeler og distrikter, eller hvis man ønsker å lage en landsoversikt over noe. Chris Nyborg (Cnyborg) 15. mar 2008 kl. 15:22 (CET)

Dis-funksjonaliteten til IE6

Ser at bemerkningen er fjernet fra sitenotice igjen - betyr det at IE6 nå kan brukes? Var innom en offentlig datamaskin utrustet med IE6 igår - der var menyen usynlig. Flott dersom dette allerede er fiksetSiri Johannessen (Siri J) 15. mar 2008 kl. 13:20 (CET)

IE7 er fikset, er foreløpig i tåkeheimen om hva som er problemet med IE6. — John Erling Blad (Jeblad) 15. mar 2008 kl. 13:48 (CET)
Det er en bug i forbindelse med «position:absolute», som slår til og får div'er til å forsvinne når flere slike ligger kant i kant. Toppen er iferd med å omskrives slik at den vil bruke float isteden. — John Erling Blad (Jeblad) 15. mar 2008 kl. 17:24 (CET)
Ser tåka har lettet :) Flott at det virker! Siri Johannessen (Siri J) 17. mar 2008 kl. 20:34 (CET)

Da er alt (kanskje) på plass

Etter en del runder er skin'et blitt omorganisert for, tja, hvilken gang… Jeg har ennå ikke sjekket om alt har falt på plass i IE6, men det er på plass igjen i de andre nettleserne jeg har prøvd. Scriptet for å flytte på elementer når skjermen er liten er ikke slått på igjen, men jeg regner med at dette vil fungere.

IE 4, 5 og 5.5 er ikke prioritert og vil ikke bli satt opp hvis ingen kan komme opp med en god grunn til å bruke disse. — John Erling Blad (Jeblad) 18. mar 2008 kl. 04:17 (CET)

De fonetiske tegnene i f.eks. Blandaball fungerer ikke i IE6; prøvde å få ordnet et skjermbilde her, men fikk det ikke til... Spesialtegnene blir til åpne firkanter. Ellers er det veldig bra at wiki'en fungerer i forskjellige nettlesere nå! --Kristian Hunskaar 18. mar 2008 kl. 15:24 (CET)
Fonetiske tegnsett er egne filer som nok ikke finnes på alle maskiner. Disse er defieret som en del av utf om jeg ikke husker helt feil, men det er ikke dermed sagt at nettleser og/eller maskin har fonter som kan representere tegnene. Da blir disse erstattet på forskjellig måte. En vanlig løsning er å sette inn firkanter der det finnes et tegn som ikke kan representeres. Dette er et kjent problem på eldre maskiner, spesielt de som kjører tidlige versjoner av Windows. Jeg er kjent med problemet, men det er såpass komplekst å lage en løsning i forhold til å vise til at dette er et problem med historiske nettlesere og operativsystemer, at jeg tviler på at det er verd å bruke tid på det. Løsningen er å lage em utvidelse ala Math, som så setter teksten i TeX og importerer en billedfil. — John Erling Blad (Jeblad) 18. mar 2008 kl. 15:42 (CET)
Det er vel det du beskriver som har slått inn. På min maskin fungerer det helt fint i f.eks. Opera, men ikke i IE6. Jeg antar derfor at det er nettleseren og ikke maskinen som er problemet. Om du mener det ikke er verdt å bruke krefter på, så er det greit for min del. --Kristian Hunskaar 19. mar 2008 kl. 11:04 (CET)


Anonymisering av omtalte personer

I en annen sammenheng ble det oppdaget at det er mulig å anonymisere navn og lignende i en wiki. Det baserer seg på skjulte sider og transkludering av navngitte seksjoner fra disse sidene. Med noen relativt enkle maler kan det hele forenkles vesentlig. For eksempel en underside kan inneholde en artikkels faktiske navn og en annen anonymiserte navn. De anonymiserte navnene kan gjøres tilgjengelig for enkeltbrukere utfra behov, mens de anonymiserte forblir anonyme inntil de eksplisitt publiseres etter en vurdering. Når forfatteren skriver så brukes det pseudonymer, for eksempel tekststrengen {{/Anne}} istedenfor en anonymisert person Karin. — John Erling Blad (Jeblad) 25. mar 2008 kl. 12:43 (CET)

Status flytting

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)

Det er foreløpig et problem med php-xml, men Brion foreslo et hack for å gå rundt problemet. Det er ikke satt opp noen løsning for server side cache. — John Erling Blad (Jeblad) 29. mar 2008 kl. 01:23 (CET)

Vær klar over at databaser på den nye serveren kan slettes helt eller fullstendig uten forvarsel. — John Erling Blad (Jeblad) 29. mar 2008 kl. 01:27 (CET)

Kan du kort beskrive konsekvensene av slik sletting, og hva det er som skjer? Dreier det seg om noe som kan skje/kommer til å skje i noenlunde kontrollerte former i forbindelse med overflyttingen, eller er det utilsiktede slettinger som menes? Kan dette gjøre permanent skade på noen måte, eller er det noe som vi bare må regne med, men som rettes opp etterhvert? Chris Nyborg (Cnyborg) 29. mar 2008 kl. 02:02 (CET)
Serveren er oppe og igang, men en del utvidelser er ikke flyttet. De tre siste oppføringene vil bli aktivisert, men er ikke aktive på serveren for øyeblikket. De seks første er foreløpig ikke i bruk, og det er ikke flagget noen stor interesse for dem. De tre resterende er ikke for alminnelig bruk, selv om HotData har vært diskutert noe. Antakeligvis vil denne bli implementert annerledes.
Når det er verifisert at serveren fungerer vil det bli gjort en forsøksvis flytting til den nye serveren. Etter at det er påvist at denne fungerer vil vil innholdet på nytt bli slettet, deretter vil demoserveren bli låst for bidrag, det tas en ny eksport som lastes opp til www.lokalhistorie.no, og den importeres på nytt. Når denne er operativ åpnes denne wikien for bidrag og det settes opp en omdirigering fra den gamle serveren. Omdirigeringen vil være operativ en kort tid før demoserveren kanibaliseres for et nytt prosjekt. — John Erling Blad (Jeblad) 29. mar 2008 kl. 02:32 (CET)
Serveren på lokalhistorie kom opp, men med feil. Noen av de lot seg fikse relativt greit, men det er et betydelig antall mangler og også et par gjenstående feil. Selve overføringen tok lengre tid enn planlagt, databasene er på tilsammen 140MB og billedbasen på omtrent 440MB. Med andre ord oppunder en komplett CD!
DynamicPageList og Mediawiki 1.12 spiller dårlig sammen på grunn av den nye parseren som er med i 1.12, og det er ingen opplagt og solid bugfix tilgjengelig. Det betyr at det må skrives en bugfix fra grunnen av. Jeg tror ikke det er aktuelt å bruke en eldre versjon av Mediawiki, det måtte i tilfelle være i en kortere periode til det blir lagd en bugfix for dpl.
Det er også ett eller annet som utløser en fatal feil i forbindelse med malen {{kommune}}. I og med at vi gjør tilsvarende ting med andre maler så er antakeligvis problemet større enn kun de stedene der denne er i bruk. Feilen er såpass vanskelig trøblete at den nekter plent å produsere feilrapporter som kan vise hva som utløser den. Og nei, det er ikke memory limit.
De to feilene er såvidt jeg kan se showstoppers. — John Erling Blad (Jeblad) 29. mar 2008 kl. 11:15 (CET)
Serveren er gudsjammerlig treig. Antakeligvis på grunn av manglende server side caching. — John Erling Blad (Jeblad) 29. mar 2008 kl. 12:46 (CET)

Nå begynner det å se bra ut! :-) Olve Utne 29. mar 2008 kl. 14:11 (CET)

Feilen i forbindelse med dpl er fikset ved å kjøre MW 1.12 med gammel parser. Dette er litt uheldig da den gamle parseren er vesentlig tyngre og mer upålitelig enn den nye. — John Erling Blad (Jeblad) 29. mar 2008 kl. 14:26 (CET)

Kommunemalen så også bra ut da jeg sjekket. :-) (Men akkurat nå svarer ikke serveren med annet enn «DELETE FROM `mw_job` WHERE job_id = '339'» osv.) Høres ut som en grei foreløpig løsning å kjøre eldre parser — vil jo tro at DynamicPageList2 likevel snart kommer i nyere versjon som tar høyde for endringene i nyeste MediaWiki-versjon...(?) -- og da er det vel forholdsvis fort gjort å få ting mer strømlinjeformet. :) Olve Utne 29. mar 2008 kl. 15:02 (CET)

Kjente feil

  • Overføring av billedbasen tar vesentlig lengre tid enn forventet da denne var nokså mye større enn planlagt. Forsåvidt et luksusproblem.
  • Den nye parseren i MW 1.12 kolliderer med malverk i dynamiske lister. Dette skjer flere steder og nokså konsistent. Dette berører alle portaler, og antakeligvis en god del oversiktslister.
    • Antatt fiks baserer seg på å lage en tag-utvidelse som tar underlagsdata fra dpl. Tag-utvidelsen vil ta et antall oppføringer, pakke hver av disse inn i en mal, parse hele settet og levere det tilbake ferdigparset. Dette vil introdusere et ekstra trinn i parsingen for hvert enkelt kall til dpl.
    • Antatt alternativ fiks kan gjøres ved å flytte det ekstra trinnet med parsing til dpl, og rett og slett parse det genererte innholdet på nytt.

Utvidelser

Det er noen utvidelser som er diskutert tidligere og som jeg antar bør tas inn. Det er sikkert flere som jeg ikke vet om. Det vil bli gjort noe nyutvikling når rallar.org er tilbake på lufta. — John Erling Blad (Jeblad) 30. mar 2008 kl. 18:55 (CEST)

Eksisterende
  • Gadgets – åpner for forenklet bruk av avanserte tilleggsfunksjoner
Antakeligvis er denne helt uproblematisk å legge inn. Den åpner for forenklet innlegging av ekstra funksjonalitet, noe av dette er av typen «kjekt å ha», men noen av verktøyene kan være særdeles essensielle.
Utvikling
  • XMLstarlet – åpner for transkludering av innhold fra andre nettsteder (Viktig for blant annet databaser hos NLI) Se også HotData
Det har vært en del tester for å se på hva alternativer som fungerer, og hvilken trade offs som oppstår. Totalt sett virker det som om XMLstarlet er en aktuell vei å gå, men kun med korttidscaching av data. Ved korttidscaching kan en forenkle og anta at timestamp på den cachede fila er alt en trenger å sjekke og da mot en konstant. Hvis en skal gjøre langtidscaching må det skrives en separat fil for cacheinfo (proxydata).
  • HotImage – åpner for hotlenking av bilder fra samarbeidende nettsteder (Det finnes en forenklet løsning innebygget)
Det er en del fordeler med å lage en ny utvidelse som ikke bare hotlenker bilder, men som også mellomlagrer bilder og skalerer dem. Dette skaper imidlertid et problem med hva som er akseptabel levetid i en slik cache.
  • Protect – tag som setter beskyttelse på en større eller mindre del av teksten, og som lar vanlige skribenter sette en slik beskyttelse under gitte vilkår (Det er viktig å «enpower the user» slik at vedkommende føler at de spiller på likefot og at makthierarkiet flates mest mulig ut) Se også Beskyttet side, Sitat og Markør
    • License – spesialisert beskyttet tag/funksjon for å gjøre lock-in på en lisens for innholdet på en side (Må kunne settes av en bruker som har skrevet hele teksten selv, inntil andre skriver på siden kan han også fjerne merkingen) Se også Multilisensiering
    • Author – spesialisert beskyttet spesialisert beskyttet tag/funksjon for å legge til en forfatter for innholdet på en side (Må kunne legges til av en bruker som har skrevet hele teksten selv, inntil andre skriver på siden kan han også fjerne merkingen)
    • Copyright – tag/funksjon for å legge til en copyrightholder (rettighetshaver) for innholdet på en side (Må kunne legges til av en bruker som har skrevet hele teksten selv, inntil andre skriver på siden kan han også fjerne merkingen)
En utvidet protect–funksjon er antakeligvis helt essensiell for å håndtere kildemateriell, og senere kunne si med en viss grad av pålitelighet at dette er materialet som ble lagt inn av riktig person.
Alle markørtaggene og markørfunksjonene er antakeligvis en del av samme overordnede konsept, og det virker sansynlig at det er bedre å implementere dette enhetlig enn hver for seg. Da kan en implementasjon være konfigurerbar om en ønsker å introdusere flere markørfunksjoner.
Markørfunksjoner vil typisk bestå av 0-3 felt i tillegg til funksjonsnavnet, litt avhengig av hva som velges som markørnavn. Hvis markørnavnet er generelt («License») så vil første felt være lisensnavnet, andre felt en hvem som har utvidete rettigheter og tredjefelt er en kommentar knyttet til bruken av markørfunksjonen. Det er også mulig å lage en løsning hvor funksjonsnavnene er spesielle og angir lisensnavnet («GFDL»). Da vil de andre parametrene rykke opp.
  • Cite – utvides for å inkludere informasjon fra andre nettsteder (Innhenting av underlagsdata fra slike som BiBSYS forenkler dokumentasjon av opplysninger vesentlig)
  • Authors – er en omskriving av utvidelsen Contributors som tar høyde for at bidragsytere bidrar i forskjellig omfang på artikler (Det er viktig med kreditering av bidrag, langt viktigere enn å få all kreditering riktig er å kreditere de viktigste bidragene)
  • WikiLink – dette er per idag en ekstern server med en egen tjeneste for å lenke opp artikler med eksterne referanser (En del av dette arbeidet er i samarbeid med ABMu) Se også WikiLink
Denne utvidelsen er ikke essensiell for Lokalhistorie, men hvis ABMu får andre interessert i dette så kan dette gjøre at Lokalhistorie brukes for å demonstrere den her typen funksjonalitet. Ved å skrive om denne tjenesten til en utvidelse blir den raskere og representerer mindre last på systemet.

Var litt frekk...

Liker egentlig godt den rekken med url'er mellom søkeboksen og brukersidene. Tror at vi med fordel kan beholde noen av dem - om ikke alle - og kanskje heller omdøpe noen, slik at innholdet bak kan bli litt tydeligere. Å legge lenker til Om wikien, hvordan redigere en side, Stilmanualen og Sideindekset for hjelpesider sammen med en side om kildekritikk er etter min mening god bruk av denne delen. Slik er redskapene for hånden for nye brukere (som de fleste av oss er...) Frekkheten min bestod i at jeg omdøpte de to første lenkene - synes ikke helt at flagget dekket lasten der. Hva mener dere? Siri Johannessen (Siri J) 31. mar 2008 kl. 02:08 (CEST)

"Om wikien" (øverst til høyre) og "Om Lokalhistorie" (nederst i footer) dukker opp flere steder. Det er av de begrepene som har lett for å bli brukt for ofte. Historisk så hører vel denne typen lenke (innholdet er litt forskjellig) hjemme på kolofonsiden, og dette er som oftest lenket opp nederst på websider men det kan godt være at denne skal være øverst og at dette er lettere å forstå for brukere. Antakeligvis bør sidene slås sammen. Ellers så synes jeg det er viktig å få igang en diskusjon om hva som skal lenkes fra toppen. Antakelig er det viktig at punktene går fra begynner til avansert, og antakelig fra venstre til høyre, slik at brukere som "tester" kan få en tilstrekkelig intro om de starter fra venstre som er det vanligste på grunn av leseretning. Jeg tror også at velkomstmaler bør ha de samme lenkene og antakeligvis vise til at de står i toppen. Uavhengig av det lille navneproblemet på lenka så synes jeg det begynner å bli en meget god intro for brukere! — John Erling Blad (Jeblad) 31. mar 2008 kl. 05:16 (CEST)
Har du et annet forslag enn "Om wikien" eller "Nybegynner"? Det siste var heller ikke noe som dekket etter min mening... Siri Johannessen (Siri J) 1. apr 2008 kl. 01:57 (CEST)
Nei jeg har ikke noe godt alternativ, og jeg er ikke sikker på om lenken bør være oppe eller nede. Versjonen som nå lenkes fra toppen er helt klart mer omfattende enn den som er lenket nede. — John Erling Blad (Jeblad) 1. apr 2008 kl. 06:14 (CEST)
Project:Om brukes for å formidle hvilken juridisk entitet som står bak utgivelsen. Hjelp:Om wikien beskriver for en bruker hva slags nettsted dette er. Dette er min konklusjon utfra en del lenker som går litt på kryss og tvers i systemet. Jeg tror ikke jeg vil garantere at min forståelse er riktig. Hvis jeg har rett så er vel egentlig lenken i bunnen juridisk utgiver, det vil si den som står bak nettstedet. — John Erling Blad (Jeblad) 1. apr 2008 kl. 07:12 (CEST)
Lenken oppe er for å forklare folk som ikke har vært borti en wiki før hvordan denne virker, at det er vanlig at vi redigerer hverandres bidrag uten at opprinnelig skribent dermed har gjort for lite, noe galt eller lignende. Om vi enn kaller lenken Don Johan eller kanarifuggel er det greit for meg, så lenge den intuitivt leder målgruppen dit den skal... Siri Johannessen (Siri J) 1. apr 2008 kl. 08:36 (CEST)
Jeg stemmer for Gul kanarifuggel. Spøk tilside, jeg lurer på om begrep av typen «Om» skaper misforståelser, og det er litt trøblete at det brukes både øverst og nederst. Nede kan vi antakeligvis bruke et annet begrep, «utgiver» for eksempel. Oppe har jeg ingen gode forslag. Jeg vil tro at det er siden som lenkes øverst som har størst nærhet til det som brukes på Hovedsiden, men det er kanskje fordi den har mer tekst… Hvis Project:Om er utgiver så vil jeg tro denne skal transkludere noe annet stoff, og da er vel hjelpesiden nærliggende? — John Erling Blad (Jeblad) 1. apr 2008 kl. 08:52 (CEST)

E-post

Det ser ut til at e-post fungerer, men det kan bli endrigner i hvem som er avsender av e-postene. For øyeblikket er det webmaster [at] lokalhistorie.no. — John Erling Blad (Jeblad) 31. mar 2008 kl. 06:49 (CEST)

Prøvde å sende deg en test-e-post med kopi til meg selv. Ser ut som min egen adresse (bekreftet adresse) står som avsender. :-) Olve Utne 31. mar 2008 kl. 15:40 (CEST)
Ah. Nå ser jeg at det står
From: Olve Utne <olve.utne [at] gmail.com>
<snip />
mailed-by: wilhelm.disnorge.no
-- Olve Utne 31. mar 2008 kl. 15:51 (CEST)

Sommertid

En liten detalj: Det ser ikke ut som om tjeneren har fått med seg omstillinga til sommertid i helga :) Ikke rart jeg syntes tida fløy av sted når jeg sammenliknet tidspunktet for endringene jeg gjorde for et øyeblikk siden og armbåndsuret - trodde et øyeblikk at jeg hadde duppa av en times tid! --Kristian Hunskaar 31. mar 2008 kl. 16:27 (CEST)

Eller, tja?! Ser at klokkeslettet ble riktig her, men i lista over siste endringer står mitt forrige innlegg her som kl. 15:27. Må jeg endre i mine innstillinger? --Kristian Hunskaar 31. mar 2008 kl. 16:29 (CEST)

For øyeblikket er serverens klokke som angitt nedenfor. Det ser ut som om siste endrigner er på UTC. — John Erling Blad (Jeblad) 31. mar 2008 kl. 16:42 (CEST) 

[nli-jeblad@wilhelm www]$ date
Mon Mar 31 16:41:08 CEST 2008

Test. — John Erling Blad (Jeblad) 31. mar 2008 kl. 17:01 (CEST)


Bekreft e-postadresse før en kan redigere

Du må nå bekrefte e-postadressen før du kan redigere 

$wgEmailConfirmToEdit = true; # Require a confirmed address to edit pages (for version 1.6 and newer)

Får du beskjed om at du ikke kan redigere så legg inn e-postadressen i Spesial:Innstillinger, vent på e-post fra systemet og gå inn på url'en som er vedlagt i e-posten. — John Erling Blad (Jeblad) 31. mar 2008 kl. 17:28 (CEST)

Kreditering av bidrag

Det er byttet løsning for kreditering av bidrag. Den nye løsningen krediterer siste bidragsyter og tidligere bidragsytere fra siste eller nest siste og videre bakover inntil ti bidragsytere. Det kan settes grenser for flere eller færre bidragsytere. Anonyme bidragsytere blir kreditert i fellesskap. Løsningen bruker real name som må oppgis på Spesial:Innstillinger. Hvis dette ikke oppgis så vil det bli brukt et generert format som ikke er spesielt pent. Flere brukere bør ta en titt på hva de har lagt inn i dette feltet. Jeg skal se på om det er mulig å endre metoden til å sortere utfra bidragsvolum. — John Erling Blad (Jeblad) 31. mar 2008 kl. 19:13 (CEST)

Antakelig bør kreditering kun skje på reelle innholdssider, og antakeligvis ikke i alle navnerom. — John Erling Blad (Jeblad) 31. mar 2008 kl. 19:14 (CEST)

Det er noen problemer med den eksisterende løsningen for kreditering. Feltet Creator i Dublin Core blir feilaktig knyttet til siste bidragsyter istedenfor første bidragsyter. Se for eksempel RDF for Sigurd Islandsmoen hvor undertegnede opprettet artikkelen. Det bør også defineres metoder for å eksplisitt sette creator i en del tilfeller, for eksempel der materialet kommer fra Wikipedia eller andre kilder. — John Erling Blad (Jeblad) 1. apr 2008 kl. 06:12 (CEST)

Standard størrelse på bilder

Det er mulig å konfigurere standard størrelse på bilder. Det inkluderer standard størrelse på thumb, gallery og bilder på billedsidene. Standard størrelse kan settes uavhengig av hva som er minste og største valgbare størrelse på Spesial:Innstllinger. Noen forslag, elelr skal vi beholde størrelsene som de er? Jeg tror det kan være en god ide å gå noe opp på standard størrelse på thumb, men beholde de andre størrelsene. Det gjør at vi slipper en del oppskalering av bilder. — John Erling Blad (Jeblad) 1. apr 2008 kl. 14:12 (CEST)

Spamfilter

Det er lagt inn en enkel løsning for spamfiltrering. Det bør settes opp en løsning som er mer fleksibel, gjerne med innhenting av info fra egne sites som publiserer blacklists. Løsningen baserer seg på en konfigurerbar løsning som legges inn i LocalSettings.php. Ulempen er at det krever at noen med aksess til denne fila må legge inn uttrykkene. Meld fra om det observeres noe som ikke er som det skal. Det ble noe kluss under innlegging av denne løsningen, men det ser ut som om det er fikset. — John Erling Blad (Jeblad) 1. apr 2008 kl. 15:03 (CEST)

Navn på prosjektrommet

Navnet på prosjektrommet kan konfigureres via $wgMetaNamespace. Navnet vil da ikke følge $wgSitename. Et skifte medfører at det må tas en backup av databasen for vi endrer da et navnerom hvor det ligger artikler. Jeg er usikekr på hva dette kan utløse. Hvis vi skal gjøre denne endringen så mener jeg vi bør bli enige om navnet. Tidligere har «Om» blitt foreslått, men jeg tror dette kan medføre mye problemer. Internt er navnerommet referert som «Project», og jeg tror at det enkleste er å oversette dette navnet til norsk. — John Erling Blad (Jeblad) 1. apr 2008 kl. 15:15 (CEST)

Et par prinsipielle ting

På tide å se på noen prinsipielle ting som har hatt liten betydning så langt, men som nå vil slå inn etterhvert som nye brukere kommer til. Det er mange flere slike ting vi må se på, og jeg tror det er viktig at vi bruker den erfaring vi har fra før med løsninger på Wikipedia samtidig som vi hele tiden er åpne for å tenke nytt. Erfaringen fra Wikipedia vil nok like ofte tilsi at vi velger en annen løsning som at vi kopierer noe. Chris Nyborg (Cnyborg) 1. apr 2008 kl. 17:25 (CEST)

Billedgallerier

På nowiki er det generelt ikke aktuelt med billedgallerier, i stedet lenkes det til Commons. Jeg mener det er en riktig holdning for en encyclopedi, fordi en del artikler hadde lett for å gå over til å bli rene bildesamlinger under en setning om temaet; det leksikalske spilte andrefiolin.

Her tror jeg vi kan tenke annerledes. På Wikipedia er bilder illustrasjoner til artikler, men i lokalhistorisk sammenheng vil det langt oftere være aktuelt å forklare bildene i mer detalj. Bilder er et viktig lokalhistorisk kildemateriale, både i forhold til dokumentasjon av tidligere tider og forståelse av et steds utvikling. Jeg tror derfor vi i mindre grad vil få artikler som består av en linje med tekst og 16 bilder; bildene utløser i seg selv et ønske om å skrive mer. Verden er selvsagt ikke så enkel at det blir en generell regel, men jeg heller mot at bildegallerier er langt greiere her. Det er også for meg et poeng at selv om vi kan lenke til Commons (hvilket er bra fordi vi fanger opp nye bilder i en raskt voksende samling) er det et ekstern prosjekt og ikke et søsterprosjekt som det er på Wikipedia. Chris Nyborg (Cnyborg) 1. apr 2008 kl. 17:25 (CEST)

Hvis du tenker på hotlenking av bilder fra Commons så mener jeg det ikke er aktuelt. Hvis du mener at vi kan bruke bilder derifra for å bygge opp billedgallerier så mener jeg det er greit. Det finnes også andre billedgallerier som jeg lurer på om vi bør bruke hvis vi får lov. Dette er imidlertid en diskusjon som må klareres med før vi starter med noe omfattende arbeid, og er bakgrunnen for tankene rundt utvidelsen «HotImage». — John Erling Blad (Jeblad) 1. apr 2008 kl. 20:24 (CEST)
Jeg tenker ikke på hotlenking. Jeg synes generelt det er en uting å gjøre det med bilder, og Commons er heller ikke spesielt glad i det fordi det blir stort press på serverne. Jeg tenker på bruk av gallery-tagen for å lage en bildekavalkade nederst i artikkelen, slik jeg har laget på Orkerød skanse som et eksempel. Chris Nyborg (Cnyborg) 1. apr 2008 kl. 21:19 (CEST)
Nå er jeg ikke helt med, fungerer ikke gallery-taggen som den skal? — John Erling Blad (Jeblad) 2. apr 2008 kl. 11:34 (CEST)
Jo, den fungerer helt utmerket. Spørsmålet er om den skal brukes i større utstrekning enn på Wikipedia eller om det skal holdes tilbake med det. Jeg mener altså at det er greit å bruke den her til å presentere bildemateriale om et område/tema. Chris Nyborg (Cnyborg) 2. apr 2008 kl. 16:03 (CEST)
En tanke jeg gjorde meg var om det burde være en arkfane til i toppen av sidene som går til en automatisk generert side med bilder knyttet til det omtalte. En slik liste kan være av billedsider som lenker til den aktuelle artikkelen. Hvis det som en del av billedbeskrivelsen lenkes til Reinli stavkirke så vil en finne et galleri av disse bildene som en egen arkfane. Siden vil være en spesialside som bruker en mal, og vil settes opp av systemet. Utvidelsen av programvaren for å få til dette er nokså triviell. Jeg tror dette ville forenkle navigeringen i bildene, og at det ville være en motivasjonsfaktor for å få gode beskrivende tekster på billedsidene. — John Erling Blad (Jeblad) 5. apr 2008 kl. 10:00 (CEST)

Stubbmerking

Jeg er ikke tilhenger av å starte med stubbmerking/spiremerking á la det Wikipedia bruker. Men jeg mener det i en del tilfeller vil være behov for å katalogisere slike artikler. Tanken er at det skrives en del småartikler som åpenbart trenger utvidelse, f.eks. artiklene om fylker og kommuner. Men det beste for disse artiklene er om de så tidlig som mulig tas hånd om av personer med en tilknytning til dem, slik at ikke andre legger føringene for mye. Det er nok for de fleste nye brukere langt enklere å gå inn og sette preg på en kort artikkel enn på en som har blitt lang og omfattende. Derfor kan de godt bli stående som stubber, men det er greit å holde en viss oversikt slik at man på et eller annet tidspunkt gjør noe med dem hvis ingen andre har kommet til. Dette gjelder selvsagt også mange andre typer artikler, fylker og kommuner er bare de mest åpenbare eksemplene blant det vi har nå.

Ulempene med stubbmerking slik den praktiseres på Wikipedia er dels at det blir mye merker i artiklene, og dels at endel oppfatter det som en angrep på kvaliteten. Det er det ikke, to konsise setninger er bedre enn ti uklare, men i mange tilfeller er det et reelt behov for å få dem utvidet med f.eks. en historieseksjon.

Mitt forslag er derfor at vi har en stubbmerking som er usynlig i artiklene. Jeg kan se for meg tre løsninger:

  1. Oppføring på liste
  2. Kategorisering med usynlig kategori (usynlig kategorimerking er mulig gjennom et tillegg)
  3. Merking på diskusjonsside
  4. Merking med usynlig mal, med oversikt gjennom dynamisk liste på vedlikeholdsside

Jeg heller mot løsning 4. Løsning 1 er tung å vedlikeholde. Løsning 2 fungerer godt, men krever et tillegg og gir en del spor i kategorisystemet som kan være forstyrrende. Løsning 3 blir en indirekte merking som jeg ikke liker helt, kanskje er det mest følelsesmessig. Løsning 4 kan være en mal som ikke viser noe som helst i artikkelen, men som kan hentes inn gjennom et forhåndsdefinert utvalg på f.eks. Project:Stubber.

Det vil ikke være noen grunn til å differensiere stubbtyper, det kan gjøres gjennom dynamiske lister (f.eks. vil de fleste biografistubber fanges opp av «categorymatch=Personer%|uses=Mal:Stubb», mens stubber innenfor et område kan fanges opp av andre kombinasjoner.

Hvis andre har bedre løsninger omkring dette, eller er mot en slik merking, eller ønsker synlig merking, er det bra om vi tar en diskusjon og begynner å få noe på plass. Jeg føler ikke at det er behov for å lage mer teknisk kompliserte spesialløsninger omkring dette, de løsningene jeg har skissert burde fungere og være enkle å bruke og sette opp. Chris Nyborg (Cnyborg) 1. apr 2008 kl. 17:24 (CEST)

Jeg er enig med deg. Billedgallerier er en bra ting og det er bedre å ha bildene i en artikkel, selv om den er liten. I noen tilfeller kan det være interessant å følge en utvikling og kanskje bare bruke utfyllende billedtekster.
En av de tingene jeg virkelig misliker på wikipedia er stubbmerking. Det viser seg at få tar tak i dem og utvider og om de gjør det så lar de merket stå i artikkelen. Det er mulig at en eller annen form for merking av artikler som kan utvides er lurt, men det gjelder ikke alle små artikler da noen emner ikke trenger mer tekst. På andre prosjekt der jeg er bidragsyter er det nok å holde et øye med Korte sider, men der er det ikke lagt inn artikler for årstall etc. som her fyller denne listen. Den beste løsningen er nok å ha en skjult løsning eller eventuelt sette dette på artikkelens diskusjonside om en ønsker at det skal være synlig for alle bidragsytere som ikke er erfarne brukere.--Nina Aldin Thune (Nina) 1. apr 2008 kl. 17:50 (CEST)
Du er inne på et par ting jeg tenkte på tidligere i dag men glemte da jeg skrev innlegget. Det ene er at noen emner ikke trenger mer tekst; med en usynlig merking er det mindre problematisk med slike grensetilfeller. På wikipedia har det til tider vært stor uenighet om merking, med usynlig stubbmerke vil det være langt mindre dramatisk. Det andre er at Spesial:Korte_sider ikke fungerer så veldig bra til å avsløre stubber, fordi den kun går på kvantitet. I begynnelsen har vi veldig mange årstallsider som står der, og etterhvert vil vi få masse pekersider og korte definisjonsartikler. I forhold til synlighet tror jeg at en liste på en vedlikeholdsside vil være rimelig synlig; dette er først og fremst aktuelt å jobbe med for de som tenker på vedlikehold/generell kvalitetsheving, og de vil lett trekkes mot Kategori:Vedlikehold. En ulempe med merking på diskusjonsside er at den må fjernes manuelt i en egen prosess; ligger merkingen i artiklen tar man den vekk når man utvider uten å måtte huske på at det er mer man skal gjøre. Chris Nyborg (Cnyborg) 1. apr 2008 kl. 18:08 (CEST)
I stedet for å forholde seg til forslaget mitt som en teoretisk størrelse lager jeg en demo av det. Det blir liste på Project:Stubber. Velger vi en annen løsning er dette så smått at jeg kan fjerne det på et par minutter, så ikke se på det som noe bindende i diskusjonen. Chris Nyborg (Cnyborg) 1. apr 2008 kl. 18:13 (CEST)
Det er relativt trivielt å utvide DPL med en grenseparameter size hvor artikler må være større enn denne grensen for å bli tatt med på en oversikt. Dette gjør at Spesial:Call kan brukes for å lage «Korte sider om Vestby» eller andre kommuner, eller «Korte sider om Opplands ordførere». Dette er nok tilstrekkelig i de fleste tilfeller. Det er også mulig å bruke usynlige maler (malene Mal:Q1 og Mal:Q2 er slike) og så la dynamiske sider liste dem, slik Chris sier. Fordelen er at da kan artiklene bedømmes som korte utfra en bedømming, ulempen er at det utløser et administrativt arbeid og forstyrrer skribentens arbeid. Muligens kan det være en god idé å starte med merking med usynlige maler og så skifte til å bruke en grenseparameter size. Personlig er jeg veldig for å automatisere så mye vedlikeholdsarbeid som mulig. — John Erling Blad (Jeblad) 1. apr 2008 kl. 20:41 (CEST)
Jeg er skeptisk til å bruke lengde som mål på dette, jeg mener det må gå på om den er ufullstendig eller ikke. Jeg mener også at det er greiest om dette forbeholdes artikler som åpenbart er stubber. De jeg har merket nå er ikke nødvendigvis gode eksempler, bortsett fra fylkesartiklene, jeg bare trengte noen eksempler for å vise forskjellige listetyper. Jeg tror vi kan komme til å få mange artikler som er korte men allikevel uttømmende nok til at det ikke er noe kritisk å utvide dem, men en fylkes- eller kommuneartikkel som bare oppgir grunndata uten noen historieseksjon har en stor mangel som ikke kan stå altfor lenge før det gjøres noe. Jeg er redd for at automatisering i dette tilfellet vil gi en lengre liste å sjekke, hvor en betydelig andel av artiklene allikevel ikke er stubber, og dermed resultere i mer arbeid. Jeg tror også at de artikler som fortjener et stubbmerke vil skille seg ut, fordi det gjerne vil dreie seg om sentrale artikler om et område eller en viktig person som har åpenbare mangler. Det virker for meg unødvendig å finregne på det slik det blir gjort på Wikipedia. Men skulle det vise seg at det blir mye arbeid kan vi jo vurdere å skifte metode, slik Jeblad skisserer. Chris Nyborg (Cnyborg) 1. apr 2008 kl. 21:24 (CEST)
Muligens snakker vi om to litt forskjellige ting. En ting er å kvalitetssikre artikler, en annen ting er å finne artikler som skal kvalitetssikres. Det første er en manuell jobb, det siste kan automatiseres. Disse to står ikke i noe motsetningsforhold. — John Erling Blad (Jeblad) 2. apr 2008 kl. 11:33 (CEST)
Jeg snakker om å finne artikler som skal kvalitetssikres. Så langt har jeg ikke sett noe som gjør det mulig å automatisere det; ufullstendige artikler (der helt sentrale ting mangler) er ikke nødvendigvis det samme som korte artikler, og korte artikler er ikke nødvendigvis ufullstendige. Hvis vi skal gå ut fra utplukk av korte artikler vil vi hele tiden ha et betydelig antall artikler som er korte men så gode at de ikke trenger vedlikehold med i listen. Det er også slik at artikler kan være lange men allikevel mangelfulle på helt sentrale områder; f.eks. er det her viktig at historieaspektet er berørt, og en artikkel om en kommune som går i detalj om geografi kan være veldig bra og altfor lang til å slå ut i en automatisk generert liste, men allikevel trenge å merkes fordi den mangler det som i vår kontekst er helt nødvendig informasjon. Hvis hjelpesider for vedlikehold ikke er målrettet slik at man finner ting som virkelig trengs å ta tak i, men i stedet må sortere seg gjennom en lang liste med artikler som er helt fine, virker det fort demotiverende. Chris Nyborg (Cnyborg) 2. apr 2008 kl. 16:09 (CEST)

Avklaring av gjenbruk

Vi trenger en avklaring om lisensen som undertegnede har satt på er akseptabel, denne er i henhold til det som tidligere er diskutert, og om vi skal akseptere kollektiv kreditering (eg. nettstedet), kreditering av hovedbidragsytere eller om samtlige bidragsytere skal krediteres. Norsk Telegrambyrå bruker ikke individuell kreditering, mens aviser flest bruker det. Wikipedia bruker kollektiv kreditering. I forskningsmiljøer er nok kollektiv kreditering noe uvanlig. Et problem vi står ovenfor om vi velger annen form for kreditering enn artiklenes historikk er at vi enten må vedlikeholde en liste av reelle forfattere manuelt, eller vi må lage noen form for automatikk for å identifisere isse forfatterne. Se også Wikipedia:Tinget#Avklaring av gjenbruk. — John Erling Blad (Jeblad) 2. apr 2008 kl. 03:59 (CEST)

Stylesheets for utskrift

det må settes opp stylesheets for utskrift via Dynabook-skinet. — John Erling Blad (Jeblad) 2. apr 2008 kl. 11:38 (CEST)

Biografimaler

Jeg savner en generisk mal for biografier... Det blir feil å bruke Mal:Infoboks kunstner overalt. Hva er klokt her, en som via feltene kan passe til flere, eller flere bokser for feks politikere, lokalkjendiser, offiserer osv. ? Siri Johannessen (Siri J) 2. apr 2008 kl. 22:10 (CEST)

Vedlikehold blir enklest hvis man har færrest mulig bokser å forholde seg til. Det må være noen spesielle ting, men jeg tror vi kan lage noen grupper av biografibokser. F.eks. vil embetsmenn, ministre, politikere og slike, som gjerne skal ha angitt verv/embete/stilling for en gitt periode kunne dele en boks, kunstnere av alle slag kan dele en (inkludert forfattere, tror jeg) osv. Det betyr innlegging av noen flere felt i boksene, og så bruker man de som trengs. På malsidene kan det eventuelt legges inn flere kodeeksempler så man kopierer over det man trenger. Alt i alt trenger vi kanskje ikke mer enn en tre-fire forskjellige bokser. Vi kan klare oss med en, men jeg tror det da blir for mange parametere til at det er praktisk å bruke den. Chris Nyborg (Cnyborg) 2. apr 2008 kl. 23:08 (CEST)
Du sier noe av det jeg tenkte på, ved siden av vedlikehold er og brukbarhet/logisk navngivning av mal og felt viktig. For mange vil det være meget ulogisk å legge inn mal:Infoboks kunstner på Bertel O. Steen og Gerhardsen, det er det jeg prøver komme i forkjøpet her ;) Siri Johannessen (Siri J) 3. apr 2008 kl. 00:24 (CEST)
Vi kan forsåvidt godt bruke noen omdirigeringer hvis ting virker veldig ulogisk, slik at det blir mer intuitivt. Chris Nyborg (Cnyborg) 3. apr 2008 kl. 00:47 (CEST)
Tror det kan være en god løsning, slik blir brukerne lettere selvhjulpne og er det lettere å følge med på hva som skjer. :) Siri Johannessen (Siri J) 4. apr 2008 kl. 00:10 (CEST)


Velkomstmaler

Jeg lurer på om det er en idé å få satt opp noen velkomstmaler. Disse bør omtale forhold ved kreditering og at feltet «virkelig navn» brukes for kreditering hvis det er satt. Jeg vil tro slike maler bør omtale hjelpelenkene i toppen av sidene, og de bør også omtale fokuset på forskning. Antakeligvis er det også lurt å nevne at det finnes brukere som er i rollen som faglige veiledere, og at disse kan rådspørres ved behov. Det bør nok også nevnes at brukere blir utnevnt til skribenter utfra en vurdering av veilederne. (Jeg må få sjekket at veiledere faktisk kan gjøre slik promotering av brukere) — John Erling Blad (Jeblad) 5. apr 2008 kl. 09:50 (CEST)

Olve er allerede i gang med det - se hos Anne Brit Flatin Borgen (AnBor), vi har jobbet noe med hva og hvordan. Siri Johannessen (Siri J) 5. apr 2008 kl. 10:35 (CEST)
La ut {{Velkommen}} som egen mal, litt tilpasset. Siri Johannessen (Siri J) 5. apr 2008 kl. 14:28 (CEST)

Opprinnelig demosite

All omdirigering av trafikk blir stoppet 6. eller 7. april, databasene vil bli tømt og nytt prosjekt opprettet på de aktuelle serverene. — John Erling Blad (Jeblad) 5. apr 2008 kl. 21:20 (CEST)

Utsatt ett døgn for å gjøre omdirigeringer permanente. — John Erling Blad (Jeblad) 6. apr 2008 kl. 19:14 (CEST)

Utsatt opptil flere døgn på grunn av at skiftet er knyttet til sykluser på søkemotorene og dette kan ta uker og opptil måneder. Det er også knyttet til lenking fra andre nettsteder, da det er umulig for rankingalgoritmene på flere søkemotorer å beregne en ranking uten slike. Det er vel verd å merke seg at for eksempel Google må ha 6-8 uker på å etablere ranking for et nytt nettsted. I denne sammenhengen er clusteret av sider på wikien til Lokalhistorie et nytt nettsted. — John Erling Blad (Jeblad) 11. apr 2008 kl. 15:09 (CEST)

Uerfarne brukeres forhold til wikikode

Jeg er involvert i et annet prosjekt der brukere som ikke tidligere har skrevet wikikode skal introduseres til ganske avanserte funksjoner. Det synes som om terskelen er ganske høy, og ikke minst at de ønsker seg howto istedenfor manual. Dette har ganske store konsekvenser da mesteparten av manualene til Wikipedia er organisert som manualer. — John Erling Blad (Jeblad) 11. apr 2008 kl. 15:13 (CEST)

Automatiske portaler

Det er mulig å lage automatisk genererte portaler som vedlikeholdsmessig representerer en vesentlig mindre arbeidslast for de som skal vedlikeholde dem enn de eksisterende. Teknikken er relativt enkel og baserer seg på utstrakt bruk av tildels enkle malverk.

Noen av de eksisterende portalløsningene er vanskelig å erstatte, mens de fleste lar seg erstatte nokså greit. Se for eksempel den automatiske portalen Spesial:Call/Kommuneportal,Sør-Aurdal og sammenlign med den ordinære portalen Portal:Sør-Aurdal. — John Erling Blad (Jeblad) 18. apr 2008 kl. 00:39 (CEST)

CustomTitle

Det er lagt inn en utvidelse som gir funksjonen {{#customtitle:My own title}} som tillater litt mer tilpassing enn {{DISPLAYTITLE:My own title}}. Den førstnevnte åpner for titler som avviker fra titler på normalisert form. Generelt bør dden sistnevnte brukes om det ikke er gode grunner til å velge den første. Funksjonen customtitle åpner for missbruk gjennom det som kalles social engineering og det bør derfor legges inn noen begrensinger. Jeg har ikke hatt tid til å gå løs på dette, men jeg vil tro at en tilstrekkelig begrensing er å kun tillate at denne brukes på sider i Mediawiki-rommet og Spesial-rommet. — John Erling Blad (Jeblad) 17. apr 2008 kl. 14:36 (CEST)

Denne skaper missbrukssituasjonen via Special:Call, og det er samtidig svært vanskelig å avskjære missbrukssituasjonen i vesentlig grad. Det ser ut som en kan gi en begrensing at denne kun kan settes inn på sider i Mediawiki-rommet, og dermed skape en situasjon hvor administratorer må inn når malverk og meldinger skal endres. Det er også mulig å legge inn en føring hvor bruk av denne eksplisitt sjekker om det er en administrator som setter den inn, endrer innholdet, eller fjerner den. Dermed har en flyttet ansvaret for bruk av funksjonen over på administratorene, men uten egentlig å ha fjernet risikoen for missbruk. — John Erling Blad (Jeblad) 20. apr 2008 kl. 13:54 (CEST)

Aggregerte portaler

Ved å bruke automatisk genererte portaler er det mulig å aggregere portaler slik at en kan lage portaler som både bruker et geografisk begrep og et tematisk begrep. Dermed kan en lage portaler som ikke bare er om et lokalområde eller som er om et tema, men som er av begge disse kombinert. Dette gjør det mulig å lage portaler om for eksempel «Den andre verdenskrig i Valdres». Slike aggregerte portaler vil bli helt umulig å lage manuelt, om en har for eksempel 20 tematiske begreper og 500 geografiske så får en 10 000 portaler. Hvis disse lages automatisk så er det kun 20 pluss 500 definisjoner, og et tilsvarende antall lenker til disse. Selve portalene blir mer eller mindre like, det er kun innholdet som endres. — John Erling Blad (Jeblad) 17. apr 2008 kl. 23:56 (CEST)

Portaler og tidslinjer

Portaler kan kombineres med tidslinjer slik at en kan trekke ut informasjon relatert til en tidsperiode. Ved at en lenker på årstallsartikler så kan dette skape tidslinjer. Dermed kan en bruke geografiske portaler, tematiske portaler og aggregerte portaler i kombinasjon med slike tidslinjer for å hente ut svært spesifikk informasjon; på sett og vis kan en si at portalene skaper et tidsbilde av det beskrevne. Når en avskjærer et tema både i tid og rom vil utvalget som oftest bli lite, og dermed må det lages noen metoder for å endre portalene fra en kondensert form og over til en komplett form. Det vil si at alle oppføringer i resultatet blir listet. Antakeligvis trenger en ikke mer enn å sjekke antall treff og så velge presentasjonsmetode på bakgrunn av dette, og så velges en grad av kondensering på bakgrunn av antall treff.

Resultatet er at en kan lage en portal «Militærhistorie i Valdres på 1700-tallet» som dermed er en portal med avskjæring i tre dimensjoner. Dette vil gi et svært stort abntall portaler om alle skal lages eksplisitt, det vil si noe slikt som 500*20*10 eller enda flere portaler. — John Erling Blad (Jeblad) 18. apr 2008 kl. 00:01 (CEST)

Ad hoch sosiale prosjektgrupper

Brukere former egentlig prosjektgrupper på ad hoch –basis, og slike er ikke styrt av formelle gruppemønstere hvis de kan formes som frie grupper uten hierarkisk styring. Slike grupper vil for en stor del være beskrevet av brukernes bidragsmønster og det kan derfor genereres grupper automatisk via underliggende systemer. Grupper lagd på denne måten vil både relatere til formelle grupper, til artikler, til portaler og til tråder i diskusjoner. For øyeblikket finnes det ingen underliggende systemer som kan støtte en slik gruppedannelse, men et utall metoder er kjent fra clustering innen automatisk klassifisering. — John Erling Blad (Jeblad) 18. apr 2008 kl. 00:06 (CEST)

Problemet med eksploderende arbeidslast

I et system slik som en wiki så vil brukerne ha en tendens til å dele seg i tre «kaster». Den ene er leserne, som ikke egentlig setter noen ekstra last på systemet utover at de er en last for maskinparken. Dernest har en skribentene som er de som produserer innholdet. Disse vil som oftest oppfatte seg som allminnelige brukere av systemet. På toppen har en administratorer som også gjerne oppfatter seg som brukere men som er langt mer opptatt av integrasjonsdisipliner og systemvedlikehold. Det er verd å merke seg at skribenter har en lokalisert interesse og det kan sies at de har en O(K) –kompleksitet å forholde seg til. Administratorene er derimot involvert i integrasjon på tvers av interessegrupper, og om en sier at det er to akser av interessegrupper, M og N, så representerer dette en O(M*N) –kompleksitet for administratorene. Hvis kompleksiteten representerer en reell arbeidslast fordi interessegruppene har avvikende teknologiske løsninger så vil administratorene bli en begrensende ressurs i systemet. Tar en utgangspunkt i de geografiske og tematiske portalene så snakker en om at M er omtrent 500 og N er omtrent 20. Hvis hver portal representerer 4-5 timers arbeid så akkumulerer dette til 40-50 000 timer. Det synes nokså klart at en bør velge løsninger som i størst mulig grad støtter gjenbruk og automatisering. Selv om en ikke velger å aggregere manuelt, men kun tilpasser geografiske portaler så snakker en om 2000-2.500 timer for kun å tilpasse portaler.

De første tallene viser at dette er en helt uoverkommelig oppgave å gjøre manuelt ved å skrive portalene en for en. Selv de siste tallene blir svært store. En kan tenke seg å skifte litt på de ved å velge mer eller mindre automatiserte løsninger men de blir fortsatt svært store. Problemet er at tallene multipliseres opp som en kvadratisk funksjon. Skal en løse problemet så er det ikke nok å redusere tidsforbruket knyttet til hvert enkelt interessefelt, det er dimensjonen til problemet som må angripes. — John Erling Blad (Jeblad) 18. apr 2008 kl. 00:24 (CEST)

Nytt meny-item oppe i høyre hjørne

Har lagt til «Brukerinteresser», slik at Project:Brukerinteresser og ekspertise også skal bli enkel å finne. La den der, sammen med resten av de spesialiserte redskapene våre. Tror den siden kommer til å måtte splittes etterhvert, forresten. Den kan bli kraftig stor etterhvert. Siri Johannessen (Siri J) 21. apr 2008 kl. 14:22 (CEST)

Fint å få brukerinteresser lett tilgjengelig! Jeg tror det bør kalles brukerinteresser heller enn brukerekspertise. Ordet interesse tar vare på både det folkelige og det faglige elementet i lokalhistorien. Siden trenger sikkert oppsplitting etter hvert, ja! --Marianne Wiig 22. apr 2008 kl. 13:42 (CEST)
Har endret - var glipp fra meg at jeg sa a) her og gjorde b) der ;) Siri Johannessen (Siri J) 22. apr 2008 kl. 14:01 (CEST)

Vårrengjøring?

Har begynt så smått ved å flytte ut diskusjoner som kan bli gamle travere. Har lagt dem på Project:Avtaler_og_retningslinjer og Project:Tips inntil videre, navn(rom) kan godt forandres. Har for ofte lett etter slike ting på "vanlig" wiki. Tror ellers at det meste som er her nå kan flyttes til et arkiv, evt. slettes. <Input needed>  ;) Hvad nu? Siri Johannessen (Siri J) 21. apr 2008 kl. 17:44 (CEST)

Slå sammen by- og kommuneportaler

På Liste_over_forsider er det en liste over kommuneportaler og en over byportaler. Det er flere på kommunelista enn det er på bylista, og det er bare to av byene som ikke finnes under oversikten over kommuner. Siden disse listene overlapper så mye som de gjør, synes jeg det hadde vært kjekt å slå sammen listene. Jeg er riktignok ikke sikker på om dette bør bety at vi skal legge føringer på at portalene skal omhandle hele kommunen. - Hva slags synspunkter har dere andre på dette? Jeg synes godt byer og kommuner kan stå om hverandre på samme lista. Sånn som det er nå synes jeg vi skaper en kunstig idé om at de fleste kommunene har en byportal som viker fra kommuneforsida. --Marthe Glad Munch-Møller (Marthe Glad) 15. des 2008 kl. 11:02 (CET)

Jeg tror vi kan slå dem sammen, men er usikker og vil forklare tankegangen bak strukturen slik den er nå. Kategoriene ble opprettet fordi en av de første forsidene vi fikk var Gamlebyen i Fredrikstad. Det er en byforside, men ikke en kommuneforside. Jeg er ikke sikker på om det vil være noen forvirring hvis vi sørger for at forsider som dekker begge deler legges inn i begge kategorier. Det er også tenkt at by i denne sammenheng gjelder den historiske definisjonen, og ikke den kunstige bystatusen som kommuner nå tildeler seg selv uten at det har noen praktisk betydning, og da får man gjerne avvikende grenser. Chris Nyborg (Cnyborg) 15. des 2008 kl. 12:35 (CET)

Kategori:Klær

Heisann dere, - som dere sikkert har lagt merke til, jobber jeg litt av og på med kleskategoriene våre. (La for eksempel merke til at kategorien "arbeidsklær", som Eiker arkiv og samvirkelagsbildene gir masse eksempler på ikke er kategorisert som arbeidsklær... Spørsmålet mitt idag er: Kategoriene manne- og dameklær er lite i bruk. Skal vi droppe dem? Mye av klærne vi har bilder av ér jo kjønnsdelte, vi har dame- og mannesportsantrekk for eksempel, og dette gjør meg usikker. Jeg ser to alternativer: gå gjennom alle bilder av menn og damer i hele wikien og kjønnskategorisere dem etter hvem som er på bildene, - eller droppe kjønnskategoriene. Den siste kjennes mest gjennomførbar. Men hva synes dere. Vennlig hilsen Marthe Glad 30. nov 2010 kl. 14:59 (CET)

Synes kjønnsnøytralt er greit. Mvh. Morten Bakkeli (Mbakkel2) 30. nov 2010 kl. 15:06 CEST)
Hentet fra «https://lokalhistoriewiki.no/index.php?title=Lokalhistoriewiki-samtale:Diskusjonsforum&oldid=177001»