Lokalhistoriewiki:Diskusjonsforumarkiv/Kaffistova/2007 oktober

Nedenfor finner du arkivert innhold fra en tidlig versjon av Diskusjonsforumet.

Velkommen

Da ønsker jeg å hilse alle nyregistrerte og åpner ballet her inne. Får håpe vi får en noe mer stabil maskin etter hvert, ikke minst at linja skal bli en del raskere. Vær vennlig å ikke publiser adressen til denne serveren til flere enn høyst nødvendig. John Erling Blad (Jeblad) 15. okt 2007 kl. 02:32 (CEST)

Bruk av piktogrammer

Det er fint om det er mulig å bli enige om en felles form på piktogrammer. Selv er jeg litt svak for den litt stiliserte formen som er på helleristninger. Det er liksom noe heilnorsk over dem, selv om de finnes over mye av Europa. Se blant annet svanen som brukes på farmasiområdet. I forbindelse med lokalområder så tror jeg vi skal bruke våpenskjold så sant det er mulig. John Erling Blad (Jeblad) 15. okt 2007 kl. 02:37 (CEST)

Utvidelsen mod_rewrite

Denne utvidelsen for Apache er ikke i bruk på serveren, men vil gjøre det mulig å bruke url'er som i dag peker andre steder. Hvis en url peker på www.rallar.org/rallar/Rallarveger så kan mor_rewrite gjøre at denne kan ende på www.jeb.no:8089/wiki/Rallar:Rallarveger. Bruken av navnerommet «Rallar» er egentlig helt uvesentlig, url'ene kan omskrives nokså fritt. Det er denne utvidelsen for Apache som gjør det mulig i andre wikier å skrive url'er på formen www.jeb.no/wiki/Sigurd_Islandsmoen. På en produksjonsserver er dette viktig å få til. Slik serveren er satt opp i dag så er det imidlertid nokså meningsløst å legge arbeid i dette. John Erling Blad (Jeblad) 15. okt 2007 kl. 02:44 (CEST)

«Tabloid»

Utseendet, eller «skin'et» som er i bruk heter «Tabloid» og er basert på «Monobook». Endringer består i noen farger og at farger og ikonbruk lar seg styre etter hvor en er på serveren. Dette gjør det mulig å visuelt fremstå som et helt annet nettsted om enkelte fagmiljøer ønsker dette. Mer om dette på Lokalhistorie:Grafisk design. Det er viktig at malverk bruker de relativt enkle klassene for å få dette til å fungere. Klassen «infobar» vil gi farger til maler i høyrespalten, noe som er en del av det ferdige malsettet. For øyeblikket er det kun navnerommet «Farmasihistorie» som har sterkt avvikende fargevalg. John Erling Blad (Jeblad) 15. okt 2007 kl. 02:47 (CEST)

Infoboks

Det er påbegynt et malsett «Infoboks» som består av {{infoboks start}}, {{infoboks overskrift}}, {{infoboks rad}} og {{infoboks slutt}}. disse vil endre utseende i takt med endringer av navnerom. På grunn av endringer i parseren så vil ikke tilsvarende maler på bokmålspedia fungere. John Erling Blad (Jeblad) 15. okt 2007 kl. 02:52 (CEST)

infobar

Det brukes et tagsett infobar for å plassere tekst ute i høyrespalten. All tekst som denne innkapsler vil flyttes ut dit. Det som flyttes ut bør følge et enhetlig design, og det bør være forberedt for å tilpasses fargevalgene i de forskjellige navnerommene. John Erling Blad (Jeblad) 15. okt 2007 kl. 02:56 (CEST)

Artikler som skal følge avvikende fargenormaler

Hvis en skal ha enkeltartikler som skal følge avvikende fargenormaler, det vil si at de ligger i hovedrommet og skal følge fargene til et annet navnerom eller være helt avvikende så kan dette enklest gjøres ved at artikkel id brukes til en test mot en tabell i LocalSettings. Dette er nok mest aktuelt for artikler som brukes for lokalportaler, hvis vi ikke skal lage et eget portalrom for slikt. Kanskje holder det at vi lager et portalrom og så legger på noen avvikende elementer slik som bruk av våpenskjold? John Erling Blad (Jeblad) 15. okt 2007 kl. 03:03 (CEST)

Administratorer

Jeg regner med at alle blir nominert til administratorer og at de som kommer senere får status som skribenter inntil vi får litt system og struktur. Initielt ble det satt opp en byråkrat kalt WikiSysop og denne er flyttet over på min egen bruker. For å sikre kontinuitet regner jeg med at det er et ønske om å ha minst en byråkrat til og jeg foreslår at Chris blir utnevnt. Hvis det ikke kommer noen innsigelser så klubber jeg den så fort han har registrert seg. I tillegg regner jeg med at NLI ønsker en byråkrat så fort tjenesten er i prod. John Erling Blad (Jeblad) 15. okt 2007 kl. 03:09 (CEST)

Registrering av brukere

Det er ingen begrensing på registrering av brukere, men da tjenesten ikke er knyttet til noen utgående mailserver er det ikke mulig å få mailbekreftelser. Dette vil det bli sett på men jeg tror ikke jeg setter det opp på denne maskinen. John Erling Blad (Jeblad) 15. okt 2007 kl. 03:12 (CEST)

Lisensmerking av artikler

Jeg har lurt på om artikler bør merkes med en lisens, og at denne er av en slik art at den ikke skal kunne fjernes. Malen vil da fungere omtrent som portalmalen, hvis det finnes Javascript så flyttes den til en mer hensiktsmessig plass – hvis ikke så blir den liggende som en boks i artikkelen. Merket settes idet artikkelen opprettes og kan deretter kun endres av noen med adminrettiheter. John Erling Blad (Jeblad) 15. okt 2007 kl. 03:16 (CEST)

Lokalportaler

Jeg har sett for meg at fagportalene ligger i toppen og lokalportalene ligger i venstremargen. Når en er inne på en fagportal vil venstremargen endres. Denne settes opp i Mediawiki:Sidebar og tallene på seksjonsheaderen referer til navnerommet der de respektive seksjonene brukes. Jeg regner med at noen på NLI har oversikt over hva slags granularitet vi bør legge oss på i lokalportalene. For eksempel så har vi faste utgivelser av årbøker for Valdres og også en noe mer rufsete Sagn og soge i Søndre Ourdahl. John Erling Blad (Jeblad) 15. okt 2007 kl. 03:22 (CEST)

Omskrivingsregel for lenker

Jeg lurer på om det er en stor arbeidsbesparelse om vi legger einn en omskrivingsregel som internt fjerner navnerom på presentasjonsdelen av lenker. Det betyr i praksis at vi alltid skriver [[Musikkhistorie:Sigurd Islandsmoen]] mens det alltid blir presentert som Sigurd Islandsmoen. John Erling Blad (Jeblad) 15. okt 2007 kl. 03:31 (CEST)

Lenking til navnerom

I toppen av siden er det en samling lenker til navnerom. Dette er kodet nokså langt nede i systemet. Det er også en seksjon for navnerom i Mediawiki:Sidebar og det er meningen at denne skal brukes for å definere lenkingen i toppen. Dette vil gjøre det litt lettere å endre denne lenkingen. For øyeblikket er lenkingen kodet til å være «navnerom:hovedside» men dette vil bli enkelt å konfigurere etter endringen. John Erling Blad (Jeblad) 15. okt 2007 kl. 03:38 (CEST)

Flytting av verktøy

Boksene for «personlige verktøy» og «verktøy» flyttes ovenfor tilleggsboksene, slik at det eneste som står ovenfor dem er boksen «navigasjon». Dette gjør at disse boksene vil stå i ro uavhengig av hvem artikkelside en lander på. dette vil også gjøre at en kan ta seg noe større friheter med plassering av lenker i venstremargen. Dette åpner også for en diskusjon om vi kan bruke «iw-lenker» for å lenke til en del faste steder, slik som for eksempel Wikipedia. En annen ting vi med fordel kan plassere i venstremargen er artikkelens kategorisering, alternativt kan den plasseres ute til høyre. John Erling Blad (Jeblad) 15. okt 2007 kl. 03:48 (CEST)

Feil på svg

Det er en feil på rendring av SVG-filer. Dette gjør at transparente områder ikke tegnes som de skal. En rask fix er å bruke png isteden for SVG. 127.0.0.1 15. okt 2007 kl. 19:46 (CEST)

Ser at det er problemer. Jeg vet ikke; siden er jo ikke offentliggjort enda, så dersom vi får SVG-filene i funksjon før den legges ut er det det greieste. Chris Nyborg (Cnyborg) 15. okt 2007 kl. 19:51 (CEST)

Regner med at problemet lar seg løse, jeg har bare ikke lagt arbeid i det ennå. Det er helt klart en fordel om vi kan bruke SVG-filer. John Erling Blad (Jeblad) 15. okt 2007 kl. 21:07 (CEST)

Fint, da lar vi det bare stå nå, og så legger jeg heller over til png som midlertidig fiks dersom det blir nødvendig for lanseringen. SVG er veldig bra i forbindelse med en del grafikk, som selvlagde kart – selv om vi får inn skikkelige kart, kan det bli en del hjemmesnekrede historiske kart og slikt.Chris Nyborg (Cnyborg) 15. okt 2007 kl. 21:26 (CEST)

Rendringen skal nå være korrekt. — John Erling Blad (Jeblad) 22. okt 2007 kl. 23:15 (CEST)

Sidebar

Mediawiki:Sidebar har nå også seksjonen som legges i toppen, det er den første seksjonen i Sidebar. Seksjon nummer to blir deretter tegnet ut som første seksjon etter søkeboksen. Resten vil komme etter verktøyseksjonen og før eventuelle iw-lenker. Innledende tall henviser til seksjoner som kun skal tas med når sidebar brukes på sider i et navnerom med samme nummeriske id, eller disses diskusjonssider. John Erling Blad (Jeblad) 15. okt 2007 kl. 21:11 (CEST)

Ikke-standardiserte maler

Jeg kommer til å legge inn noen maler som ikke er standardisert i forhold til klasser som brukes her. Det er ingen grunn til panikk; det er bare så mye lettere å tilpasse dem etter at de er lagt inn fremfor å drive å flikke på dem annensteds. Chris Nyborg (Cnyborg) 15. okt 2007 kl. 21:27 (CEST)

Jeg har ikke sett så mye på rene merkemaler og hvordan de skal klasses. Antakeligvis bør vi standardisere en del av dette før vi går åpent ut med wikien. John Erling Blad (Jeblad) 15. okt 2007 kl. 21:29 (CEST)

Grønne lenker

I en del tilfeller finnes det artikler i andre wikier, og nettsteder, og det vil være lurt å vise for brukeren at «det finnes ingen slik artikkel i denne wikien men et annet nettsted har en slik artikkel». John Erling Blad (Jeblad) 15. okt 2007 kl. 21:36 (CEST)

Sammarbeidende nettsteder vil bli notert på en egen side med en url som utfører en eksportering eller nedlasting av et artikkeldump eller en dump av titler. Kun titlene vil bli brukt og vil legges inn i en egen databasetabell. I en artikkel der det er lenker hvor base part er identisk med artikler på de sammarbeidende nettstedene, vil fargen bli grønn for eksisterende artikler og oransje for ikke eksisterende artikler. Umiddelbart etter lenken er det et favicon som symboliserer det aktuelle nettstedet omtrent som på ekstern.lenke. Noe ala Wikipedia John Erling Blad (Jeblad) 16. okt 2007 kl. 16:11 (CEST)

Jeg ble gjort oppmerksom på et speil av Wikipedia i dag som bruker denne teknikken, Veropedia. — John Erling Blad (Jeblad) 23. okt 2007 kl. 23:34 (CEST)

IW-lenker

En mulig måte å bruke IW-lenker er å lenke til andre prosjekter, for eksempel hvis Kunsthistorie fortsetter som en selvstendig site så kan en ha en IW-lenke til en fagartikkel om for eksempel reinli stavkirke, mens den interne artikkelen i større grad kan beskjefige seg med lokale forhold. Det gjør at en unngår at kunsthistorikere kommer i konflikt med lokalhistorikere som er mer opptatt av andre forhold ved den samme kirken. Slik denne wikien er satt opp så kan det være en artikkel om samme kirke i alle navnerom, men antakeligvis er det ikke lurt å gjøre det. John Erling Blad (Jeblad) 15. okt 2007 kl. 21:43 (CEST)

Årstall og datosider

Jeg tror årstall- og datosider slik vi har på Wikipedia vil være interessante. Jeg har fått veldig gode tilbakemeldinger fra profesjonelle leksikografer/encyklopedologer på at den kronologiske manøvreringen som disse åpner for er en spennende innfallsvinkel, og på en historieorientert wiki virker det enda viktigere med en slik mulighet. Det vil være en spennende måte å knytte sammen stoff fra forskjellige deler av landet innen et spesielt tidsrom på. Jeg tror nok også at vi etterhvert kan komme til å få portaler eller andre løsninger som har perioder som innfallsvinkel, f.eks. senmiddelalder eller mellomkrigstid, og da vil årstallsider være greit. Det er noe skit å legge inn slikt manuelt; kan det etterhvert overlates til en bot å lage slike sider ved å legge inn en standardtekst (evt. subste inn en mal)? Chris Nyborg (Cnyborg) 15. okt 2007 kl. 22:07 (CEST)

I forlengelse av dette kan kategorisering av personer etter fødsels- og dødsår også være ønskelig. Chris Nyborg (Cnyborg) 15. okt 2007 kl. 22:10 (CEST)

Hva med noe slikt: http://nn.wikipedia.org/wiki/Mal:Levde ? Den malen er relativt lett å bruke, og personartiklene kategoriseres automatisk. -- Olve Utne 15. okt 2007 kl. 22:21 (CEST)

Ikke dumt. En ting vi bør vurdere er løsningen de har på dewiki, hvor alle biografier skal ha en standardisert, usynlig mal nederst. Den kan dels brukes til å hente ut informasjon til kategorisering, og del til robotuthenting av informasjon. Chris Nyborg (Cnyborg) 15. okt 2007 kl. 22:24 (CEST)

For å få noen eksempler på plass har jeg lagt inn {{årstall}} med noen tilhørende maler og {{årsside}} som substes inn. Chris Nyborg (Cnyborg) 17. okt 2007 kl. 21:25 (CEST)

Dyplenking til Bibsys

Kjenner noen til om det er greit å dyplenke til Bibsys? I {{tl|Infoboks bok}} kan det være veldig praktisk å legge inn lenke direkte til siden der, ettersom man da får opp eksemplarliste ved tilknyttede institusjoner, samt andre opplysninger. Chris Nyborg (Cnyborg) 15. okt 2007 kl. 22:57 (CEST)

Jeg la inn lenkingen, men kanskje noen bør sjekke… John Erling Blad (Jeblad) 15. okt 2007 kl. 23:01 (CEST)

Jeg tror det er helt uproblematisk, men jeg kan starte med å sende en mail til Morten H.; det er antagelig lettere å spørre han til råds enn å lete seg frem til rette vedkommende. Chris Nyborg (Cnyborg) 15. okt 2007 kl. 23:12 (CEST)

Migrasjon

Hvis vi skal beholde «Utvandrerhistorie», så foreslår jeg å bruke det språklig nøytrale «utvandringshistorie». Et alternativ er å endre dette til «migrasjonshistorie». Da får vi bl.a. med oss innvandringen fra Danmark og Schleswig-Holstein/Hamburg, utvandringen til Nord-Amerika og innvandringen fra Pakistan i tillegg til andre eldre og nyere innvandringstrender. (Eventuelt kunne vi beholde «utvandringshistorie» og legge til «innvandringshistorie» eller «innvandring og minoriteter».) -- Olve Utne 15. okt 2007 kl. 23:08 (CEST)

Jeg tror utvandringshistorie bør bestå som kategori, ettersom det er et kjent og avgrenset studiefelt. Overordnet kategori kan være migrasjonshistorie, hvor man også får plass til innvandringshistorie. Chris Nyborg (Cnyborg) 15. okt 2007 kl. 23:14 (CEST)

Absolutt — i likhet med «nasjonale minoriteter», selv om det nok også kan forsvares å putte den sistnevnte under immigrasjonshistorie. -- Olve Utne 15. okt 2007 kl. 23:40 (CEST)

Brukergrensesnitt og målform

Vi må passe på at alle tilrettelegginger av languageNx.php, stilark m.m. inkluderes i både bokmåls- og nynorskutgavene. For øyeblikket lenkes det til «Kaffistova» på bokmål, men «Aktuelt» på nynorsk. -- Olve Utne 15. okt 2007 kl. 23:37 (CEST)

Jeg har ikke gjort noe forsøk på å gjøre alle endringer på nynorsk. Noen av tilpassingene mangler også mulighet for å få de språknøytrale da de hentes rett ut av mediawikirommet. Såvidt jeg husker finnes det noen triks for å få til dette men det er ikke prioritert for øyeblikket. John Erling Blad (Jeblad) 15. okt 2007 kl. 23:49 (CEST) (Og er du ikke snill så blir det kaffestuen på nynorsk)

Mediawikirommet bestemmes av languageXx.php-filen og skulle være en enkel sak å justere. Med tilgang til den filen kan jeg fikse litt på det i ny og ne. Hmmm.... Ved nærmere ettertanke, så kan jeg jo rett og slett gå inn og gjøre endringer i spesial:allmessages med nynorsk som valgt målform. Det skal kunne fungere under forutsetning av at databasen som helhet eksporteres til permanent server når den tid kommer. -- Olve Utne 16. okt 2007 kl. 00:43 (CEST)

Tenke at det skulle kunne fungere etter de siste endringene. Men så likte jeg tanken på å ha full kontroll med språket til vestlendinger! :D Neida, jeg tror det meste av endringer skal kunne lokaliseres ganske greit. det eneste jeg tror ikek lar seg lokalisere er noen av tekstene som brukes som tittel helt øverst. De hentes rått ut fra LocalSettings. Når det gjelder tilgang til koden så blir det ingen direkte tilgang til den som brukes i prod. Det blir tilgang via et svn-repository som så sjekkes mot test. Først når test fungerer med endringene, og endringene blir godkjent av en av de som blir bemyndiget å gjøre versjonering, så blir prod bumpa til neste versjon. Litt tungvint men veldig kjekt når en jobber med servere som skal ha god oppetid. Med andre ord så er det ikke helt et ordinært webhotell vi skal over på. John Erling Blad (Jeblad) 16. okt 2007 kl. 00:55 (CEST)

Det finnes flere utvidelser for å fikse målform i deler av brukergrensesnittet, artikler og andre deler av Mediawiki. Noen metoder fungerer, mens andre deler funger heller dårlig. Er det noen som har erfaring med de forskjellige metodene? Hva trenger vi å lokalisere og hva kan vi la være. — John Erling Blad (Jeblad) 22. okt 2007 kl. 23:19 (CEST)

Hvis en bygger videre på løsningen med javascript så kan en lage egne samlebokser som plukker opp språkvalg fra settingen i brukergrensesnittet. Dette vil være et «låst valg» til forskjell fra valget som angis i flerspråksboksen som brukes for synopsis. Språkvalget vil fungere slik at det finnes en standardliste av språk som brukes på hele nettstedet. Denne lista justeres for brukerens egne valg i sin klient. Til slutt prioriteres hans valg inne på nettstedet, dvs i innstillinger. Det valget som kommer øverst i lista og som finnes igjen i en språkboks vil bli brukt. Det betyr at om et annet språk er synlig så blir dette skjult og det andre vises. Dette kan fungere for en del malverk, men problemet med «Måløy kirke» vs «Måløy kyrkje» vil delvis bestå. Hvis malene kan ta flere språk i parametre så kan det imidlertid fungere. Hvis en snekrer en utvidelse så kan dette bli noe ala

{{Infoboks katedral|navn={{#lang:no=Måløy kirke|nn=Måløy kyrkje}}}}

Omskrevet blir parameteren noe ala

…<div class="alternate multilingual"><div class="lang-no" lang="no">Måløy kirke</div><div class="lang-nn" lang="nn">Måløy kyrkje</div></div>…

Dette ser ut som om det kan fungere. En forutsetning for at det ikke introduserer unødig last er at skifte mellom språkene skjer via javascript eller css. Dette er for å unngå at en må slå av caching. En meget aktuell og meget elegant løsning kan være å la javascript skrive et css-statement tidlig under rendring av siden. Da unngår en flikker og riktig tekst skrives ut ved første forsøket. — John Erling Blad (Jeblad) 23. okt 2007 kl. 14:08 (CEST)

En ekstra utvidelse?

Det finnes en utvidelse som angir hvem som er online til enhver tid. Dette kan være veldig kjekt der noen trenger hjelp og derfor undersøker hvem han kan spørre. Stort sett er denne nokså nøyaktig. En uheldig bieffekt er at den kan villede enkelte til å tro at det er fritt frem om de ikke ser at det er en administrator pålogget. John Erling Blad (Jeblad) 16. okt 2007 kl. 00:12 (CEST)

En annen ulempe er at et åpent nettleservindu uten aktive redigeringer trolig vil kunne være nok til å vise noen som aktiv. Jeg vet av erfaring at f.eks. bleieskift med komplikasjoner kan medføre at denne statusen blir misvisende. En god indikator på hvem som er pålogget er ellers siste endringer-listen. Om en ikke aktivt redigerer, blar eller laster sider om igjen, vil en heller ikke oppdage om noen har skrevet melding med bønn om hjelp... -- Olve Utne 16. okt 2007 kl. 00:54 (CEST)

Jeg har ikke sjekket men jeg tipper at de bruker keep alive som indikasjon på at en bruker fortsatt er pålogget. John Erling Blad (Jeblad) 16. okt 2007 kl. 00:56 (CEST)

Notabel eller relevant?

Jeg tror vi skal være forsiktig med å innføre sosiodialekten fra wikipedia som er påvirket av engelsk språkbruk. Svensk wp har noen mye bedre uttrykk for dette: http://sv.wikipedia.org/wiki/Wikipedia:Relevanskriterier. Jeg er redd for at vanlige mennesker som vi ønsker som brukere ikke vil skjønne uttrykket notabel fordi det ikke er brukt på denne måten på norsk. Kan vi ikke bruke relevans eller leksikonverdi? Det vil vel også være slik at en del stoff som har liten relevans på wikipedia godt kan skrives om her, så kanskje det ikke er lurt å overføre alle stilmanualene fra wikipedia uten å tilpasse dem denne wikiens egenart. Nina Aldin Thune (Nina) 16. okt 2007 kl. 02:15 (CEST)

1. Notabel > relevant er en god idé.
2. Hva Lokalhistorie ikke er: «Lokalhistorie er ikke Wikipedia». Med andre ord: Det som er for lokalt for Wikipedia kan til og med være hovedfokus her.

-- Olve Utne 16. okt 2007 kl. 14:02 (CEST)

Det kommer krav om pålogg slik at en kan skrive original research, noe som i seg selv skulle borge for at vi ikke er Wikipedia. John Erling Blad (Jeblad) 16. okt 2007 kl. 14:28 (CEST)

Portaler

Jeg la til et portalrom. Etter mye tenking konkluderte jeg med at det er lettere å forholde seg til et portalrom enn lokale hovedsider inne i navnerommene. Fordelen er at «informasjonssamlinger» kan trekkes ut av navnerommene. For å få visuelle likhetstrekk med navnerommene er det lagd en tabell i LocalSettings som identifiserer sider som skal ha en avvikende stil. Det er litt uheldig at dette må konfigureres der, kanskje en bedre metode ville være å hente dette fra en tabell i Mediawiki-rommet. I første omgang er det bare et hack for å se hvordan det fungerer. 127.0.0.1 16. okt 2007 kl. 13:00 (CEST)

Etter noen diskusjoner med Nina så er forslaget at navnerommet «Kunsthistorie» deles i tre, en for lokale kuntnere, en for folkekunst/byggeskikk og en for kirke/menighetshistorie. Kunsthistoriewikien har et langt mer internasjonalt perspektiv enn det helt lokale og vil ikke passe helt inn. Isteden kan vi bruke IW-lenking til aktuelle artikler på denne. Det samme gjelder «Musikkhistorie» hvor det lokalhistorske vil knytte seg til tradisjonsmusikk og folkemusikk. Her dukker det vel også opp et område folkedans. «Farmasihistorie» har et så internasjonalt perspektiv at det er litt vanskelig å se hvordan dette kan innpasses. John Erling Blad (Jeblad) 16. okt 2007 kl. 15:45 (CEST)

Det musikkhistoriske vil i tillegg til tradisjonsmusikk/folkemusikk og folkedans også inkludere klassisk musikk — både i form av lokale komponister/musikere og i form av lokal oppførelsespraksis (f.eks. orkesterhistorie). En annen historie er at navnerommet utvandrerhistorie bør flyttes til (f.eks.) migrasjonshistorie — se ovenfor. Der kan det gjerne være flere portaler, slik som Utvandringshistorie og Innvandringshistorie, og muligens også separate portaler for hver av de nasjonale minoritetene og nyere innvandrergruppene...(?) -- Olve Utne 16. okt 2007 kl. 16:15 (CEST)

Folkemedisin - «Kloke koner» - Svartebøker etc. er noen emner som kan være aktuelle her. Det problematiske med slike emner er at de ikke må skrives på en slik måte at folk oppfatter dette som legeråd. Jeg er sikker på at det finnes veldig mye slikt stoff i lokal tradisjon. --Nina Aldin Thune (Nina) 16. okt 2007 kl. 17:48 (CEST)

Kanskje lage et navnerom som tydelig signaliserer hva det er? Noe ala «Folkemedisin», «Folketro» (litt på siden og dårlig begrep) eller «Heksekunst»! Den siste kommer unektelig til å gi oss oppmerksomhet… John Erling Blad (Jeblad) 16. okt 2007 kl. 19:47 (CEST)

Portaler vs navnerom

En liten klargjøring for de som ikke kjenner til den vanlige oppdelingen av en wiki. Navnerom er separate områder i en wiki slik som mediawiki. Ett slikt navnerom er «Okkupasjonshistorie». Portaler derimot er definerte innganger til større samlinger av stoff. Det kan da lages en portal inn til et navnerom, og Portal:Okkupasjonshistorie er en slik inngang. Slike innganger kan lages på flere måter, og på bokmålspedia brukes en håndfull forskjellige metoder. En av de som jeg har funnet at fungerer særdeles bra er den som brukes på «Portal:Kunst». Denne er lagd slik at aktuelle artikler roteres gjennom året slik at en kan sette opp en portalside som så endres hver måned, uke, eller enda daglig gjennom hele året. Denne bruker rotorer som skifter inn artikler i en endeløs ring.

I denne wikien blir noen av navnerommene brukt til å styre hvem som får lov å redigere der. Dette gjør at navnerommet «Leksikon» kan stenges ned for alle andre enn noen få brukere. For å synliggjøre de tematiske og faglige skiftene mellom navnerommene så er det lagt til en mekanisme som gjør at artikler får utseende som reflekterer at de er i et slikt rom. Dette gjør at alle artikler i Okkupasjonshistorie blir relativt like.

Portaler er derimot et helt annet navnerom men når en skal formidle at det er en del av et annet rom så «juksar me lite granne». En mekanisme lar en artikkel få utseendet til et annet navnerom. Dermed kan en portal, som egentlig ikke er noe annet enn en vanlig artikkel, få utseendet til et navnerom. En portal er teknisk sett en vanlig artikkel som ligger i et eget navnerom, men for å gjøre relasjonene tudeligere for brukere så lar vi den bruke utseendet fra det navnerommet som den lager en inngang til. John Erling Blad (Jeblad) 16. okt 2007 kl. 17:35 (CEST)

Jeg er enig i at Portal:Kunst på nowiki er bra. Den er veldig praktisk vedlikeholdsmessig, og nokså enkel å forklare. Det jeg mener er bra, og som jeg har et opplegg for er:

• En mal som substes inn på Portal:X med oppsett og lenker til «modulmaler»
• En veiledning som forklarer hva de enkelte maler som da opprettes skal fylles med, hvordan man kan bruke onlyinclude for å lime inn deler av en artikkel og evt. andre aktuelle triks.

Dette blir såpass enkelt at brukere med minimal erfaring kan klare å sette opp en portal. Det vil være et visst krav til kunnskap om wikier, men det mener jeg er en fordel. De som setter opp portaler bør ha en grad av comittment til prosjektet, og de bør ha orientert seg en del først, blant annet slik at de vet om det finnes nok artikler til en effektiv portal.

Tilpasning til relevant navneroms oppsett kan evt. gjøres i ettertid av personer som behersker det. Chris Nyborg (Cnyborg) 16. okt 2007 kl. 22:32 (CEST)

da har jeg lagt inn {{Portaloppstart}}. Den er ikke testet ut, og det må helt sikkert gjøres en del småtteri, men den inneholder hele oppsettet fra Portal:Kunst, og skulle gi noe som er rimelig enkelt å fikse på. For portaler som har færre underkategorier og/eller lister er det lett å bruke de modulene til noe annet, noe som kan legges inn i bruksanvisningen. Jeg venter med å legge ut bruksanvisning til jeg får en tilbakemelding på malen. Chris Nyborg (Cnyborg) 16. okt 2007 kl. 22:41 (CEST)

Da er malene sett over, og det er sikekrt noe jeg ikke har fikset. Farger får vi ta siden. Malen {{thumb}} skrev jeg om så den blir godtatt av parseren. Jeg fant aldri ut hvorfor den ikke likte mine første utkast. Den lager et ordinært bilde når den er på en artikkelside og flytter seg inn i venstrekanten som et lite frimerke når den er på en portalside. John Erling Blad (Jeblad) 16. okt 2007 kl. 23:48 (CEST)

Jeg har nå startet testing av portaler i praksis med Portal:Vestby. Ikke tenk for mye på innhold og bildevalg, det er foreløpig improvisert fordi det ikke er så mye å ta av. Det er lettest for meg å teste det ut med stoff jeg kjenner skikkelig, og det er den tekniske siden ved dette jeg i første omgang er opptatt av. Chris Nyborg (Cnyborg) 18. okt 2007 kl. 22:58 (CEST)

Okkupasjonshistorie

I toppen til Okkupasjonshistorie la jeg inn et lite bilde bare for å prøve, og ble litt overrasket over hvor mye det løste opp det stramme designet. Kan det være en ide å bruke bilder for å vise lokal tilhørighet? Hvordan gjør vi det da med logoer? Det er gjort noe lignende på kommuneportaler [1] uten at jeg akkurat bifaller det designet. John Erling Blad (Jeblad) 16. okt 2007 kl. 14:31 (CEST)

Ser bra ut :-) Olve Utne 16. okt 2007 kl. 14:47 (CEST)

CharInsert?

Noen mulighet til å legge inn programutvidelsen CharInsert? Hadde vært fint å kunne begynne å legge inn hjelpetegn o.a. i redigeringsvinduet. -- Olve Utne 16. okt 2007 kl. 18:14 (CEST)

Hva vil du ha med, og husker du hva som er siden som hører til editboksen?

Á á Ć ć É é Í í Ĺ ĺ Ń ń Ó ó Ŕ ŕ Ś ś Ú ú Ý ý Ź ź

Legg til i strengen her eller legg det på plass med en gang og anfør hva sider du endrer. John Erling Blad (Jeblad) 16. okt 2007 kl. 18:34 (CEST)

Har lagt til et relativt fyldig utvalg her: MediaWiki:Edittools. Noe av dette kan nok skjæres litt ned på (og enkelte tegn bør kanskje også legges til), men nå har vi et utgangspunkt å arbeide videre med. :) Olve Utne 16. okt 2007 kl. 21:33 (CEST)

Noen av tegnene jeg skulle likt å ha med er enkelte enheter som det alltid er et ork å rote frem. grader, promille, osv. John Erling Blad (Jeblad) 16. okt 2007 kl. 22:58 (CEST)

Herved gjort, om enn ikke finsortert ennå... :] Andre ønsker? -- Olve Utne 18. okt 2007 kl. 01:41 (CEST)

LilyPond

Just enclose some music in LilyPond syntax in <lilypond>...</lilypond> or <lilymidi>...</lilymidi> tags. For example <lilymidi>f, d f a d f e d cis a cis e a g f e</lilymidi>

If you enclose the music in <lilymidi>...</lilymidi> tags, the image will be clickable, and the link will download the MIDI file.

Another option is to use <lilybook>...</lilybook> tags, which creates a full page of music. for example, this code:

<lilybook>

\version "2.10.5"

\header { 
 title = "Mary Had a Little Lamb"
 tagline = ""
}

\paper {
 ragged-right = ##t
 ragged-bottom = ##t
 indent = 0\mm
}

melody = \relative c' {
 e d c d | e e e e |
 d d e d | c1 |
}
    
text = \lyricmode {
\set stanza = "1." Ma- ry had a lit- tle lamb,
 its fleece was white as snow.
}
    
\book{
  \score{ <<
    \new Voice = "one" { \melody }
    \new Lyrics \lyricsto "one" \text
    >>
 
    \layout { }
    \midi { }
  }
 
  \markup{
    \wordwrap-string #"
    Verse 2.
  
    All the children laughed and played,
    
    To see a lamb at school."
  }
}

</lilybook>

Denne er nå satt opp men jeg har ikke fått sjekket at den produserer gyldig midikode. John Erling Blad (Jeblad) 16. okt 2007 kl. 19:43 (CEST)

Det kan være at denne bør brukes sammen med et eller annet script for å konvertere midi til mp3 eller noe lignende. John Erling Blad (Jeblad) 16. okt 2007 kl. 21:00 (CEST)

Kategorimanual

Til orientering har jeg ting klart på kategorimanual, men venter litt med å legge inn dette til det har kommet litt mer avklaringer i forhold til løsningen med dynamiske lister og evt. annet som vil påvirke kategorisystemet. Hvis noen ønsker at jeg skal legge det ut kan jeg gjerne gjøre det, bare si fra, men jeg lurer på om det kan være greit å skrive mye fra scratch hvis vi skal velge en annen modell, og så bare legge inn den praktiske veiledningen fra det jeg har klart. Chris Nyborg (Cnyborg) 16. okt 2007 kl. 19:18 (CEST)

Det er tre varianter; DynamicPageList, NewsPageList og CategoryTree. Den siste er veldig lettvekts og er den jeg har eksperimentert med på noen sider på Wikipedia. den første er tung og krever endringer i koden til Mediawiki. Nummer to er mer orientert mot å lage tidsskrifter. Noen tanker om hva vi skal bruke? Jeg liker den første men det er litt uggent med endring av kodenn i og med at det gjør at ting blir ustandard. John Erling Blad (Jeblad) 16. okt 2007 kl. 19:26 (CEST)

CategoryTree er nå installert. Gjør et forsøk etter hvert på å få DynamicPageList til å spille. John Erling Blad (Jeblad) 17. okt 2007 kl. 01:58 (CEST)

Proofread Page

Denne er satt opp, men uten at det er noen side å teste med her inne. På wikisource er den i bruk, se blant annet The Adventures of Sherlock Holmes (flere) og Side by side image view for proofreading. Navnerommene som er avsatt er «Side» og «Innhold». (Dvs de blir satt opp om noen strakser, – done) John Erling Blad (Jeblad) 16. okt 2007 kl. 20:39 (CEST)

Vedlikeholdsmaler

På nowiki er det mange vedlikeholdsmaler som opprydning, språkvask osv. Jeg tror en del av disse kunne være praktiske her også, og har dem klare til å legge inn, men vil høre hva andre synes. De kan evt. tilpasses til fargevalget her, slik at de blir enda mindre påtrengende, eller de kan lages som usynlige maler som bare legger til en vedlikeholdskategori. Sistnevnte mulighet tenker jeg på fordi vi nok må regne med å måtte pleie brukerne litt mer intensivt her enn på Wikipedia, og samtidig blir det nok også lettere å få oversikt. Men jeg tror det er nødvendig med en enkel måte å merke artikler som skal wikifiseres osv. Jeg har f.eks. ofte ti minutter til å sjekke ting i et friminutt – da kan jeg ikke redigere så mye, men jeg kan merke slik at det er lett å finne det senere og ta det. Chris Nyborg (Cnyborg) 17. okt 2007 kl. 00:33 (CEST)

Jeg tror det er best at de er usynlige og bare oppretter en kategori. Et av problemene med malene er at de kan ta motet fra nye brukere. Jeg mener også at vi ikke skal innføre stubbmerking. --Nina Aldin Thune (Nina) 17. okt 2007 kl. 00:39 (CEST)

Ta en titt på {{portal}}, den forsvinner opp i toppen og gjør lite av seg. Det er teksten som henger oppe under tittelen på Sigurd Islandsmoen. Vi kan lage noen slike maler som kan legges inn i teksten og som kan stues effektivt bort. En måte kan være at malene bare setter på en kategori og når en peker på kategorilenken så får en hjelpeteksten som sier hvorfor artikkelen er merket slik og slik. Malen {{nøyaktighet}} setter på en kategori og lenken blir Nøyaktighet som står på sin vanlige plass. Lar en pekeren hvile over lenken så vil teksten komme til syne. Kategorilenkene kan i tillegg merkes slik at en gjenkjenner slike merkede kategorier lettere. Hvis brukeren ikke har JavaScript så må malene tegnes ut på vanlig måte. I og med at de normalt vil forsvinne så tror jeg de kan lages svært enkelt og kanskje like. Dermed så kan en kanskje lage en mal som lager disse? John Erling Blad (Jeblad) 17. okt 2007 kl. 00:46 (CEST)

Jeblads forslag virker bra. F.eks. en {{vedlikehold}} som fungerer som utgangspunkt for alle typer vedlikeholdsmerker, med et parameter som fylles ut og forklarer hva det gjelder hvis man er interessert.

Det som kanskje er aktuelt som en mal som vises tydeligere er et «under arbeid»-merke. Det vil gjøre det lettere å legge ut stoff som er veldig lite bearbeidet og jobbe med det her; jeg tror en del vil kvie seg for å gi inntrykk av at en rotete haug med tekst er det beste de kan prestere, og dermed vil sette pris på å kunne merke det tydelig med at det er under arbeid. Chris Nyborg (Cnyborg) 17. okt 2007 kl. 16:53 (CEST)

En vedlikeholdsmal som sjekker kategorien med et switch-statement og om riktig kategori er angitt så blir merket stående i tillegg til at kategorien får hele forklaringen. Hvis kategorien er helt ukjent så prøver malen å sende kallet videre til en mal av samme navn. Hva som plasseres hvor og hvordan det blir seende ut blir kraftig forenklet i fohold til dagens løsning på Wikipedia, og jeg tror den vil fremstå som langt mer elegant. John Erling Blad (Jeblad) 17. okt 2007 kl. 20:51 (CEST)

Må se litt mer på dette. John Erling Blad (Jeblad) 19. okt 2007 kl. 15:25 (CEST)

Hvis du sier fra når du har fått det til kan jeg skrive en brukerveiledning. Chris Nyborg (Cnyborg) 19. okt 2007 kl. 15:26 (CEST)

Biblio

En utvidelse som hvis den fungerer vil danne basis for en del tilsvarende systemer. Kilden til bibliografiene kan ligge i artikkelen, på en brukers underside, eller på eksterne nettsteder som gjør bibliografier tilgjengelige i særskildte format. På eksterne nettsteder brukes det enten sider som er formlike wikisider eller soap. Mer fullstendig beskrivelse er på wikiomics.org: Biblio John Erling Blad (Jeblad) 17. okt 2007 kl. 00:51 (CEST)

Teksten som skrives

A citation <cite>somebook</cite>. Three citations <cite>webber2001 schwartz2005 somebook</cite>.

Teksten vil bli

A citation somebook. Three citations webber2001 schwartz2005 somebook.

Referanseseksjon

<biblio>

1. schwartz2005 pmid=16100001

// see also stryer somebook for a smooth introduction

1. webber2001 pmid=11751224
2. somebook John Smith. The art of saying nothing. Verbose Editions 1999.
3. stryer isbn=0-7167-4954-8

</biblio>

Bør integreres mot Bibsys og historisk-administrativt avgrensede kildesøk. John Erling Blad (Jeblad) 17. okt 2007 kl. 01:12 (CEST)

Jeg mistenker denne for å være særdeles tung å kjøre, eller at responsen fra serveren er avhengig av svar fra de aktuelle tjenestene. John Erling Blad (Jeblad) 17. okt 2007 kl. 03:33 (CEST)

Det tenkes på en utvidelse av denne for å passe inn med den historisk-geografiske databasen. John Erling Blad (Jeblad) 19. okt 2007 kl. 13:41 (CEST)

CategoryTree og sidenavigasjon

Under installasjonen av CategoryTree så jeg at denne kan brukes for å lage en dynamisk navigasjon som ligger i venstremargen. Gitt en artikkel som ligger i et navnerom kan vi legge en kategori eller et sett av kategorier inn i et CategoryTree som ligger i venstremargen. Dette blir isteden for en statisk navigasjon på ett nivå. For eksempel vil vi da kunne legge inn at det i navnerommet «Lokalhistorie» skal være innganger på bispedømmer, fylker og fogderier. John Erling Blad (Jeblad) 17. okt 2007 kl. 02:04 (CEST)

Pdf-utskrift

Satte opp sider for pdf-utskrift, men det ser ut som det mangler en del tilpasninger. Noen som kjenner til denne? John Erling Blad (Jeblad) 17. okt 2007 kl. 02:56 (CEST)

Pdf-book

Dette er en utvidelse for å skrive ut kategorier som bøker. Jeg ser for meg at enten så brukes det en mal på utvalgte sider, eller så skiftes det automatisk når en er i kategorirommet fra enkeltsideutskrift til å skrive ut en bok av artikler. I det siste tilfellet så står da lenken i verktøyboksen. Det er også mulig å skrive ut punktlister, og dermed kan en kalle utvidelsen fra en mal. For mere informasjon, se mw:Extension:Pdf_Book John Erling Blad (Jeblad) 17. okt 2007 kl. 03:17 (CEST)

ConfirmAccount

Det må vurderes hvordan en skal gå frem i forhold til redigeringer. Skal alle ha lov til å redigere, skal bare registrerte få redigere, skal registrerte godkjennes på bakgrunn av det de oppgir, skal registrerte kontaktes for å få lov til å redigere, osv. John Erling Blad (Jeblad) 17. okt 2007 kl. 04:33 (CEST)

Virker ikke. 127.0.0.1 17. okt 2007 kl. 12:57 (CEST)

Koordinater

Koordinatmalen er veldig viktig, ikke minst i forhold til artikler om gårder. Jeg har lagt inn {{koor}} og {{koordinater}}, og de fungerer som de skal. Det som ikke fungerer er plasseringen; ettersom oppsettet er anneledes her blir de stående der de ligger i teksten. Noen idéer? Chris Nyborg (Cnyborg) 17. okt 2007 kl. 17:57 (CEST)

Husker ikke i farten om de plasseres med css eller javascript. Skal se på det. Tenkte å legge inn noen utvidelser for å regne på koordinater (forferdelig å gjøre manuelt) og eksportere data til Google maps og Google earth. Disse gjør det enklere å bli med på lasset når ABMu gjør sine eksporter. John Erling Blad (Jeblad) 17. okt 2007 kl. 20:21 (CEST)

Det kunne kanskje også være greit å legge inn dingsen vi har på Wikipedia og Commons som oversetter en lenke fra Google Maps til en koordinatmal på redigeringssiden, se http://no.wikipedia.org/wiki/Bruker:Atluxity/koordinater.js. Den gjør det veldig enkelt å identifisere et sted på Google Maps' satelittbilder og så slenge inn koordinater. Jo flere artikler vi har koordinater på, jo lettere vil det være å kombinere artikkelmassen med kartløsninger. Chris Nyborg (Cnyborg) 19. okt 2007 kl. 15:22 (CEST)

Det er lagt inn en utvidelse for å få konvertert koordinater. Dette gjør det litt enklere å lage maler for slikt. — John Erling Blad (Jeblad) 22. okt 2007 kl. 23:23 (CEST)

Nynorske kategorier, ol

I denne utgaven av mediawiki er det såvidt jeg har forstått ingen støtte for flere navn på samme kategorier, utover en rå omdirigering. På en eller annen måte må vi enten bli enige om vi navngir kategorier på bokmål eller nynorsk, eller at vi setter enkle og klare grenser for hva som skal navngis på bokmål og nynorsk. Selv ser jeg helst at vi velger bokmål, gjerne tettest mulig på nynorskformen, og at vi heller velger mindre optimale navn som er felles enn 100% korrekte navn som skaper konflikter ved at de er rene bokmåls eller nynorskformer. John Erling Blad (Jeblad) 17. okt 2007 kl. 22:59 (CEST)

Omdirigering av kategorier medfører «skjulte medlemmer», ja. Å legge seg på «radikalt bokmål» er en god idé i utgangspunktet, men vil erfaringsmessig møte såvel glemsomhet som noe motstand. Både i forbindelse med glemsomhet og motstand vil en risikere unødige gnisninger på sikt — jfr. Wikipedia... Doble kategorier er også foreslått, men har definitivt sine ulemper. En mulighet som såvidt var oppe på siste telefonmøte var å holde kategoriene på nynorsk i forbindelse med «nynorskfylkene» («gardar i Hordaland») og på bokmål i «bokmålsfylkene» («gårder i Akershus»), og trolig også på toppkategorinivå (?) I alle fall er det nok lurt å prøve å bruke samlende former i forbindelse med statiske enheter (f.eks. portalsider, navnerom); der vil glemsomhetsfaktoren være mindre merkbar enn ved dynamiske enheter som kategorier. -- Olve Utne 18. okt 2007 kl. 01:37 (CEST)

Som nynorskfylker regnes definitivt Rogaland–Møre og Romsdal. Litt usikker på Telemark, Buskerud og Oppland. -- Olve Utne 18. okt 2007 kl. 01:49 (CEST)

Magefølelsen sier at det er lurt å unngå kategoriseringer langt ned i kommuner. Kategorier brukes for å samle linjene og bare unntaksvis bør vi bruke kategorier av typen Gårder i kommune. Bruk kategorier for gårder og kommuner og skal en ha uttrekk så bør det brukes dynamiske lister. Det er en teknisk begrensing som vil komme med antall oppføringer i en kategori men det er lenge til denne nås og grensen er konfigurerbar. John Erling Blad (Jeblad) 18. okt 2007 kl. 01:56 (CEST)

Småkategorier

Relatert til innlegg i denne tråden: Det er opprettet kategorier helt ned på enkeltgårds- og enkeltkirkenivå, hvilket er uheldig i forhold til oppretting av dynamiske lister. Jeg ser at det gjør det enkelt å lage bildegallerier, men jeg tror det da er bedre å opprette et galleriavsnitt med <gallery> på artikkelsiden. Chris Nyborg (Cnyborg) 18. okt 2007 kl. 18:05 (CEST)

Dynamiske lister og gallerier vil i felesskap løse dette tror jeg… Skal se om jeg får DynamicPageList til å fungere. John Erling Blad (Jeblad) 19. okt 2007 kl. 13:39 (CEST)

Vi bør huske at dette ikke er en modifisert utgave av Bokmålswp og Nynorskwp, men en kombinasjon av begge disse og Wikimedia Commons. Bildemateriale er en separat ressurs her og vil kunne trenge en litt annen granularitetsfilosofi. Matrikkelgården som grunnenhet er hensiktsmessig på flere måter:

1. Administrative grenser er flytende gjennom historien, men hver matrikkelgård vil på ethvert tidspunkt tilhøre én enhet.
2. Innenfor hver matrikkelgård kan det fort bli mange bilder OG mange artikler. Kategorien matrikkelgård er intuitiv og lett å hanskes med til og med for relativt ferske bidragsytere.
3. En slik relativt automatisk sortering av materiale på matrikkelgårdsnivå letter arbeidet med å strukturere stoff og produsere artikler innenfor denne grunnenheten.
4. En kan (bør?) forøvrig også velge å legge historiske bygninger (f.eks. kirker) innenfor denne grunnkategorien — gjerne i stedet for separate kategorier for enkeltkirker.

At enkeltkirker ikke trenger en egen kategori er greit, så lenge en kan legge dem i en annen grunnenhet.

Det er mulig at et manuelt gallerisystem også vil kunne virke, men jeg er i utgangspunktet mye mer skeptisk til dette.

Å legge alt materiale i helt vide kategorier (gårder i fylke; kristendom; islam; mål og vekt; osv.) høres meget bra ut med forbehold om at en matrikkelgårdskategori kan beholdes.

Alt dette er selvfølgelig foreløpige standpunkt. Om det kan demonstreres at andre løsningstyper faktisk vil fungere på en hensiktsmessig og faglig fullt tilfredssstillende måte, så er jeg selvsagt helt med. :-) Kanskje det er lurt å kjøre litt parallelle løsninger de første ukene? -- Olve Utne 22. okt 2007 kl. 14:54 (CEST)

Matrikkelgårder i <fylke> for eksempel? Jeg tror det er mulig å relatere bruk til disse via dynamiske lister. Bilder kan en vise i gallerier på bakgrunn av utvalg fra dynamiske lister om jeg har forstått riktig. Kirker som en del av en gård bryter sammen i byer så det tror jeg ikke er en god ide. Hovedfordelen ved å hente utvalg på dette nivået fra dynamiske lister er at vi da kan håndtere både gårder i sogn, gårder i grunnkretser og gårder i kommuner med de samme mekanismene. Antakeligvis kan vi hente ut bruk under gårder også om vi planlegger kategorisering, linking og bruk av maler effektivt. Det er et par problem som er nokså betydelige, og det er at matrikkelgårdene har endret seg over tid, og at store deler av landet ikke er med i gårdsmatrikkelen. Den dekker stort sett Sør-Norge. 127.0.0.1 22. okt 2007 kl. 16:02 (CEST)

Matrikkelgårder i <fylke> som neste kategorinivå høres bra ut. Noen matrikkelgårder har endret seg over tid, ja — men i vesentlig mindre grad enn ved kommuner, fylker (amt/len), prestegjeld, bispedømmer, osv, ikke sant? At deler av landet ikke er inkludert er absolutt en utfordring, ja. Ser problemet med matrikkelgårder i forbindelse med bykirker... -- Olve Utne 22. okt 2007 kl. 16:13 (CEST)

Vi har fått ganske klare tilbakemeldinger på at vi må fange opp byhistorie i samme grad som bygdehistorie, og jeg er vel tilbøyelig til å være enig. — John Erling Blad (Jeblad) 22. okt 2007 kl. 16:35 (CEST)

Matrikkelgarder på Voss, roder i Bergen... :-) Olve Utne 22. okt 2007 kl. 17:06 (CEST)

Bør vel få inn Lars Roede på diskusjonen rundt kategorisering av stoff fra byer. — John Erling Blad (Jeblad) 22. okt 2007 kl. 23:09 (CEST)

Nei uff, nå blei de visst litt for møe rod her... ;-p Olve Utne 22. okt 2007 kl. 23:16 (CEST)

Jeg har ganske god peiling på Bergen og rodesystemet. --Nina Aldin Thune (Nina) 23. okt 2007 kl. 01:00 (CEST)

Lokaliserte kategorier

Det ser ut som NLI går for en løsning med lokalkategorier som reflekterer dagens kategorier kommuner for dette er lettest å tolke for brukere. De ønsker også på noen måte å bruke den historisk-geografiske inndelingen. En tanke er å kunne eksportere data fra denne databasen som så brukes for å sette opp dynamiske lister. Selve søket og den dynamiske listen vil da plasseres på en spesialside. Dette er for å unngå å slå av caching, noe som minst vil doble lasten på serveren. En side om den tidligere kommunen Hedalen vil da ha en lenke til «Historiske Hedalen», hvor artikkelen transkluderes inn (eventuelt som en liten teaser) og med en oversikt over alle historiske detaljer. Det er denne siden som er en spesialside. Underlagsdataene for denne kommer fra den historisk-geografiske databasen. Ved å gjøre det på denne måten får vi full uttellling for alle historiske oppdelinger, ikke bare den som fantes på et eller annet tilfeldig tidspunkt.

For oss betyr det i praksis at kategorisering på tid blir veldig viktig. Vi må også legge opp til kategorier eller maler som angir når noe starter og når noe slutter. Hvordan vi skal få med oss mellomliggende årstall er jeg usikker på, men det finnes en utvidelse for å sette opp programmatiske løkker. Da sier malen når noe starter og slutter, og aktiviteten blir flagget i alle mellomliggende år i tillegg. Hvis en kommune ble opprettet i 1910 og avviklet i 1915 så vil disse to være året for opprettelse og avvikling, og i tillegg vil den bli listet som eksisterende i 1911, 1912, 1913 og 1914. På denne måten kan vi med minimale endringer få søkene til å fungere. Det er også mulig å lage programmatiske endringer som er mer effektive, men da snakker vi om mer omfattende løsninger.

Jeg tror at det kanskje finnes noen inndelinger i landskaper som er aktuelle, men det er ikke gitt at det er enkelt å få disse entydinge. Det er rimelig entydig hva som er grensene for Valdres og Hallingdal, men det er ikke entydig hva som er grensene for Ringerike. De som bor i områdene har ofte en annen oppfatning enn de som bor i randområdene. Inne på Wikipedia er det trukket grenser for Ringerike som går relativt langt inn i Land-regionen, og det er usikkert om de som bor i denne regionen er enig i at de er regnet til det historiske Ringerike.

Mitt forslag er å bruke CategoryTree i venstremargen slik at den viser fylkene, og slik at brukeren kan navigere fra disse. Underkategorier åpner da i venstremargen. Venstremargen skal ikke endre seg med artikler så lenge artiklene er i hovedrommet. Navnene på fylker og kommuner er vel nøytrale i forhold til nynorskdiskusjonen så dette tor jeg er problemfritt så langt.

Inne i kategorier og andre sider så kan vi bruke en utvidelse som lar en skrive notater på flere språk. Vi velger da å bruke denne for maler ol, slik at vi i størst mulig grad kan lokalisere språket. Artikler merkes med språkform slik at brukere gjøres oppmerksom på at artiklene har en offisiell språkdrakt, og da er det denne som er offisiell. Er en artikkel merket på denne måten så vil den bare unntaksvis skrives på alternativ målform.

Selve kategoriene blir det bare rot med om de skal skrives på alternativ målform så lenge det ikke finnes noen utvidelse for å håndtere dette. Det er relativt enkelt å endre målformen under presentasjon, men dette vil lett forvirre brukeren til å tro at nynorskformen fungerer på alle nivåer i programvaren. Det er også lett å sette opp en løsning slik at hvis brukeren skriver en kategori på nynorsk så vil han fortsatt havne på riktig sted. Dette er fortsatt feil fordi artikkelen ligger i en annen kategori. For å unngå alle problemene med dette så foreslår jeg at vi er tydelige på at kategorier er på bokmål inntil noen gjør alle endringer som skal til for en full lokalisering av kategorier. John Erling Blad (Jeblad) 19. okt 2007 kl. 13:38 (CEST)

Den skisserte løsningen for å løse historisk-geografiske problemer virker god. Kategorier for etableringer og opphør ville uansett være aktuelt her, og kan vi gjøre disse funksjonelle utover direkte oppslag er det flott. Jeg er tilhenger av å bruke den enkleste løsningen som er funksjonell, fordi det da er mindre som kan gå galt og det er lettere å fikse det hvis noe slutter å fungere skikkelig f.eks. fordi det blir for mange artikler i en kategori til at rutinene takler det. Jo færre «bevegelige deler», jo lettere er det å reparere ting.

I forhold til regionene vil det alltid være problemer med grensetrekkingen der. De har ofte en historikk som rent geografisk definerte enheter, basert på naturlige grenser, som administrative enheter basert på praktiske hensyn (avstander, veikvalitet osv.), og i moderne tid som sammenslutninger av flere kommuner definert ut fra kommunegrensene. At slike grenser har forskjøvet seg over tid og i en del tilfeller alltid har vært noe uklare må man bare leve med, og forsøke å gjøre det beste ut av. Lokalhistorikere kjenner denne problematikken godt nok til at man kan utarbeide akseptable løsninger i forhold til kategorisering, der man evt. har overlapping for noen bygder i randområdene, og så være mer nøyaktig i artiklene i forhold til forskjellige mulige definisjoner.

Språkformer: Jeg har et utkast til språkregler. Jeg tar der også med noe om å skrive på dialekt, noe som har blitt gjort en del innen lokalhistorie (dels fordi man baserer seg på muntlige kilder og vil bevare den nøyaktige ordlyden, og dels fordi mange lokalhistorikere også er ihuga lokalpatrioter). Jeg rydder litt opp i forhold til det som er sagt her, og legger det ut i kveld under Lokalhistorie:Målformer. Chris Nyborg (Cnyborg) 19. okt 2007 kl. 15:16 (CEST)

Om kategoriene (og infoboksene) foreløpig skal låses til bokmål, så betyr dette at en må legge opp til en type bokmål som ligger nær «samnorsk». Da blir f.eks. former som seglskute, gard, kvit, mjøl, mjølk, 1920-åra osv. nødvendige. Kan alle leve med og etter dette? :) ? Olve Utne 22. okt 2007 kl. 15:09 (CEST)

Jeg tror det enkleste er å bare akseptere at en målform velges på denslags. Hvis noe kan tilpasses språket brukeren ønsker, fint. Hvis ikke, kjipt det, men vi har et prosjekt som skal fungere. Muligens kan vi lage maler som skifter målform, muligens kan vi klare å få støttetekst i kategorier til å fungere også, men jeg tror vi unngår svært mye problemer ved å si at inntil en tekst på tilfredsstillende måte kan lokaliseres så er målformen gitt til det de fleste bruker. Det eneste unntaket er der noen ønsker å skrive en artikkel av noe omfang, der kan vedkommende velge. Hvis det bare er flikking på en eksisterende artikkel så beholdes målformen. På kategorinavn brukes bokmål inntil noen gjør en skikkelig metode for lokalisering av disse navnene. — John Erling Blad (Jeblad) 22. okt 2007 kl. 16:16 (CEST)

Kan du utdype dette i forhold til det jeg nettopp skrev? -- Olve Utne 22. okt 2007 kl. 16:23 (CEST) Nå ser jeg at Chris har skrevet inn kortversjonen av det jeg nettopp argumenterte for på Lokalhistorie:Språknormer. -- Olve Utne 22. okt 2007 kl. 16:32 (CEST)

Overføring til permanent server?

Vil det som lastes opp hit av artikler/bilder bli direkte overført til permanent server, eller må vi laste opp bilder o.a. på nytt når denne er oppe? Jeg spør fordi jeg er usikker på hvor mye det er verdt å flytte over hit fra egen server. -- Olve Utne 18. okt 2007 kl. 01:49 (CEST)

Vi hiver over billedkatalogen og dumper databasen via en backuprutine. John Erling Blad (Jeblad) 18. okt 2007 kl. 01:57 (CEST)

Fritt fram for innholdet, med andre ord? :-) Olve Utne 18. okt 2007 kl. 02:00 (CEST)

Jeg regner med det. Så langt kan jeg ikke se store problemer. Artikler og annen tekst kan vi ta over med Special:Export og Special:Import. Dette går raskt om det er lett å identifisere materialet. Her inne kan vi identifisere alt ved å bruke Special:Allpages. John Erling Blad (Jeblad) 18. okt 2007 kl. 08:24 (CEST)

Leksikon

Da er det lagt inn litt innhold fra Norsk historisk leksikon i navnerommet Leksikon:, med omdirigeringer fra hovednavnerommet. De er merket med {{nhl}}, som inntil ting er avklart forteller at de er beskyttet av opphavsrett. Chris Nyborg (Cnyborg) 18. okt 2007 kl. 23:32 (CEST)

Se også Spesial:Lenker hit/Mal:Nhl. John Erling Blad (Jeblad) 19. okt 2007 kl. 15:13 (CEST)

Jeg har lagt på protect-tagger slik at denne merkingen ikke kan fjernes. — John Erling Blad (Jeblad) 22. okt 2007 kl. 23:25 (CEST)

Fagportaler

Marianne kom med noen morsomme tanker om at wikien er Lokalhistorie.no og at fagportaler da er områder de arbeider med, isteden for at det er en mer generell lokalhistorisk portal. Da vil en fagportal være instituttets publikasjonsbehov. Andre fagportaler kan da være deres offisielle sammarbeidsprosjekter. I en slik løsning blir enkelte av de foreslåtte fagportalene noe perifere. Løsningen vil da nærme seg en mer tradisjonell bruk av et content management system. Jeg er litt usikker på hvordan dette vil påvirke en community, men kanskje det vil gi denne wikien en større tyngde. John Erling Blad (Jeblad) 19. okt 2007 kl. 13:49 (CEST)

Server

ABMu har lagt opp til at serveren installeres rett fra svn-baserte script. Det gjør at en kan hente ut de nødvendige scriptene fra deres svn-server og deretter sette opp en replisert server på en vilkårlig maskin. Hvis noen da vil eksperimentere med endringer kan de lage en slik replisert server, og så sende en diff tilbake med ønske om forandringer. Disse vil da bli lagt inn i en test-instans. Først når denne fungerer tilfredsstillende vil en prod-instans bli oppdatert. Undertegnede har fått en demo av konseptet, hvor det ble satt opp en helt ny test fra scratch på serveren. Dette skjedde i løpet av noen minutter. Jeg kommer til å gjøre et forsøk på å replisere dette på en av mine servere. John Erling Blad (Jeblad) 19. okt 2007 kl. 13:56 (CEST)

CategoryTree istedenfor Kategorier

Det kan se ut som om vi med fordel kan bruker utvidelsen CategoryTree der kategorier nå angis i bunnen av artikler. Dette vil visuelt endre boksen slik at det foran kategorinavnene står et plusstegn. Klikker en på dette så er en direkte inne i kategorien. Dette vil betydelig redusere behovet for navigasjonsmaler. Det er kun kategorier som vil vises på samme måte som dagens kategorier. John Erling Blad (Jeblad) 19. okt 2007 kl. 15:32 (CEST)

Høres veldig bra ut. Men dette åpner for et nytt spørsmål: Dersom vi bruker denne varianten blir det aktuelt å lage mer spesifikke kategorier, fordi de vises raskere slik at det er lettere å få overblikk enn hvis man må klikke seg gjennom kategorier på Wikipedia-måten. Men så spørs det hvordan dette vil slå ut i forhold til dynamiske lister. Jeg kan lage et eksempel for å forklare hva jeg egentlig spør om:

Hvis vi har

• Kategori:Vestby

• Kategori:Personer fra Vestby

• Kategori:Ordførere i Vestby

• Kategori:Ordførere i Son
• Kategori:Ordførere i Hølen

• Kategori:Kirker i Vestby
• Kategori:Utdanning i Vestby
• Kategori:Vestbys geografi

• Kategori:Gårder i Vestby
• Kategori:Steder i Vestby

• Kategori:Vestbys historie
• Kategori:Fornminner i Vestby

og man skal lage en dynamisk liste som omfatter alle artikler med tilknytning til Vestby som har årstallskategori mellom 1500 og 1600, vil man da kunne få med artikler fra alle underkategorier hvis man definerer bare Kategori:Vestby som kriterium, eller må man definere hver enkelt underkategori.

Dette vil ha stor betydning for veivalget, fordi vi har to motstridende faktorer:

• Dynamiske lister gir muligheter som kategoriseringen ikke kan åpne for alene
• Spesifikke kategorier gjør det lettere å finne en artikkel innenfor et enkelt tema for den jevne bruker, spesielt når man bruker CategoryTree som gjør det lettere å få overblikk over systemet.

Altså, dersom de to tingene rimelig enkelt kan kombineres tror jeg det er den beste veien, men hvis det ene utelukker enkel bruk av det andre må vi ta noen valg, og de valgene må følges temmelig rigid. Chris Nyborg (Cnyborg) 19. okt 2007 kl. 15:50 (CEST)

Saken om navigasjonsbokser under utløste en problemstilling til: Vil en slik mal rimelig enkelt kunne defineres slik at den tar med underkategorier, eller må den da ha definert tilhørighet til hver enkelt kategori? For å ta eksempelet som er brukt under kan man tenke seg at kirkekategoriene blir oppsplittet på forskjellige nivåer, alt ettersom hvor mange kirker det finnes og hvor mange forskjellige typer kirker det er i de ulike geografiske enhetene. Chris Nyborg (Cnyborg) 19. okt 2007 kl. 15:56 (CEST)

Jeg tror vi skal ha mest mulig generelle kategorier der det er mulig, og unngå det virvaret av spesifikke kategorier som finnes inne på Wikipedia. Vi kategoriserer på «Vestby» og på personer, gårder ol som har spesielle egenskaper, eller på ett nivå opp, slik som «Lensmenn i Østfold» eller «Fornminner i Østfold». Spesielle ting som «Fornminner i Vestby» tror jeg med fordel kan plasseres i en navigasjonsboks «Fornminner i Vestby». Denne plasseres på artikler om slike fornminner og vedlikeholdes automatisk av DynamicPageList. Dette gir oss fungerende kategorier, mens boksene følger grovt sett subject-metodikken i IPTC-kategoriseringen. Vi kan faktisk ha en navigasjonsboks {{helleristning|Vestby}} uten at det finnes en kategori «Helleristning».

Jeg ville endre treet noe og si at vi kan ha følgende kategorier

• Kategori:Vestby (Full kategori)

• Subject:Personer fra Vestby (Vestby AND Personer i Østfold)

• Subject:Ordførere i Vestby (Vestby AND Kommuneordførere i Østfold)

• Subject:Ordførere i Son (Son AND Kommuneordførere i Østfold)
• Subject:Ordførere i Hølen (Hølen AND Kommuneordførere i Østfold)

• Subject:Kirker i Vestby (Vestby AND Kirker i Østfold)
• Subject:Utdanning i Vestby (Vestby AND Utdanning i Østfold)
• Subject:Vestbys geografi (Vestby AND Geografi i Østfold)

• Subject:Gårder i Vestby (Vestby AND Gårder i Østfold)
• Subject:Steder i Vestby (Vestby AND Steder i Østfold)

• Subject:Vestbys historie (Vestby AND Historie i Østfold)
• Subject:Fornminner i Vestby (Vestby AND Fornminner i Østfold)

Jeg tror vi må ta med en lokal avskjæring på kategorier ala «Fornminner i Østfold» da den ellers blir for stor, men det kan nok gjerne løftes opp på fylkesnivå. John Erling Blad (Jeblad) 19. okt 2007 kl. 16:16 (CEST)

Bortsett fra denne vrangforestillingen din om at Vestby kommune ligger i Østfold ser dette bra ut. Jeg tror slike navigasjonsbokser vil være mer vedlikeholdsvennlig og praktisk enn småkategorier, og for de som leter etter informasjon vil de være lettere tilgjengelig. Ser nydelig ut, da skriver jeg et utkast til kategoriforklaring i løpet av kvelden som baserer seg på dette. Hovedtrekkene blir findeling på fylkesnivå men ikke lenger ned. Når en slags mal begynner å komme på plass kan vi rydde i kategoriene her, det er allerede noen småkategorier som kan byttes ut. Chris Nyborg (Cnyborg) 19. okt 2007 kl. 18:06 (CEST)

Det finnes vel ingen mer passende plass for Vestby enn i Østfold? 127.0.0.1 20. okt 2007 kl. 18:50 (CEST)

Hjelp:Kategorisering er opprettet. Den er basert på Wikipediaversjonen, men er tilpasset til de tankene som er drøftet her, og har eksempler som er relevante her (eller rent teoretiske eksempler). Den må sikkert endres underveis, men dette skulle være et greit grunnlag for å komme i gang. Chris Nyborg (Cnyborg) 19. okt 2007 kl. 20:47 (CEST)

Etter mye rot funker det på hovedrommet. Det er satt opp en dynamisk boks som er organisert med et ittel som kommer fra MediaWiki:Navbar og et innhold som kommer fra MediaWiki:navcontent0 for hovednavnerommet. Jeg skal se på om jeg kan få dette til å funke korrekt for andre navnerom, nå blir det ikke riktig for diskusjonsrommene.

Det er også nødvendig å rydde litt i kategoriene som brukes som «hovedinnganger» og den enkleste måten å gjøre dette er at en lager en kategori «Kommuner i Norge» som så har «Kommuner i Østfold». Under denne kommer de enkelte kommunene. Hvis en bruker «Østfold» direkte så blir denne relativt rotete fordi den har all mulig annen graps. — John Erling Blad (Jeblad) 21. okt 2007 kl. 01:13 (CEST)

Navigasjonsbokser

Jeg foreslår at det lages en form for standardiserte navigasjonsbokser ala middelalderkirker inne på Wikipedia, at disse plasseres i høyremargen på artiklene og at de gis noen parametre som er relativt enkle å forholde seg til. Selve merkemalen blir da noe så enkelt som {{middelalderkirker}} eller litt lokalisert som {{middelalderkirker|Oppland}}. I utgangspunktet kan de liste de artiklene hvor de er brukt og hvor artikkelen er plassert i en nærmere angitt kategori. Det betyr at en mal middelalderkirker kan plasseres på Slidredomen og den vil bli tatt med i boksen. Plasseres samme mal på artikkelen om Middelalderkirker så vil ikke denne artikkelen tas med. Jeg tror det er mulig å lage malverk som håndterer dette på en enkel måte, men det forutsetter DynamicPageList. John Erling Blad (Jeblad) 19. okt 2007 kl. 15:41 (CEST)

Jeg synes dette høres bra ut. Det vi mister i forhold til den ikke-dynamiske typen maler er at det ikke blir røde lenker, og dermed blir det mindre synlig hvilke behov vi har i forhold til nye skribenter. Men det kan løses på andre måter, f.eks. ved opprettelse av lister i artikelform kombinert med oppfølging overfor brukere som viser interesse for et gitt område eller tema. Chris Nyborg (Cnyborg) 19. okt 2007 kl. 16:18 (CEST)

Mener du Mal:Infoboks katedral? Problemmet er at samme stoff da vil opptre på forskjellige plasser. Jeg syns det er bedre å lenke til arkitekturhistoriske fagartikler enn å skrive det samme flere steder. Det som kunne være fint var at det her kunne komme mer stoff om menigheter, sagn, prester, kirkebøker, kirkegårder og annet som har en mer lokalhistorisk karakter. Dette er stoff som vi ikke har noen andre steder.--Nina Aldin Thune (Nina) 19. okt 2007 kl. 16:35 (CEST)

Navigasjonsbokser, ikke infobokser. Vi lager slike bokser manuelt inne på Wikipedia. Der inne kan vi med rimelig grad av sannsynlighet angi hva som det vil bli skrevet en artikkel om. Her inne kan vi i liten grad forvente at det skrives en artikkel om stoffet og det er bedre å skape boksene dynamisk. Et alternativ er å la boter vedlikeholde boksene. John Erling Blad (Jeblad) 19. okt 2007 kl. 16:52 (CEST)

Jeg tror en dynamisk løsning er å foretrekke fremfor å bruke boter. Vedlikeholdsmessig virker det mer hensiktsmessig, fordi det da i stor grad blir «fire and forget». Man må jo følge med litt så de ikke vokser seg altfor store; da må kriteriene for inklusjon i malen snevres inn. Men i overskuelig fremtid er ikke det noen stor problemstilling fordi det tar tid å bygge opp så mange artikler at vi får slike situasjoner, og vi kan da fokusere både menneskelige evner og botkapasitet på andre oppgaver. Chris Nyborg (Cnyborg) 19. okt 2007 kl. 18:18 (CEST)

Da har jeg lagt inn DynamicPageList, og en foreløpig mal for {{Steder i område}}. Denne malen er brukt på Vestby og steder i kommunen. Stedene er i dette tilfellet statiske, og kan forsåvidt skrives som en liste med en gang. Etter å ha sittet med småsteder i en annen kommune en tid så så jeg at slike steder er et høyst dynamisk begrep på grunn av den tolkingen de tillegges. En starter høyt og jobber seg nedover. Det som så skjer er at en skifter fokus.Malen for steder i område har da fordelen at den skalerer veldig bra, det er bare å endre parameter to og en får en finere granularitet. Tilsvarende kan vi lage en dynamisk liste for {{Gårder i område}}, hvor vi kanskje starter helt ute på landskaper og jobber oss nedforbi sogn og ender på grunnkretser en eller annen gang i fremtiden. Som en liten kuriositet, vi kan endre malen slik at isteden for å skrive {{Steder i område|fylke|kommune}} kan skrive {{Snitt|steder i fylke|kommune}}. Denne siste formen fungerer ved utvalg basert på to kategorier, men kan utvides. — John Erling Blad (Jeblad) 22. okt 2007 kl. 19:44 (CEST)

Ser ut til at det fungerer utmerket. Såvidt jeg kan se er dette systemet veldig greit å overføre til andre temaer, slik at det er lett å lage nødvendige maler etterhvert som det blir artikler nok innenfor forskjellige områder. Du traff godt i forhold til mine planer, det var nettopp for at det skulle være greit å kunne kjøre en slik test jeg slengte inn de forskjellige stedene i kommunen. Jeg var litt i ulage i går og er det i dag også; var i 60-årslag på lørdag og tryna skikkelig på i mørket på hjemveien. Jeg skjønte at jeg ikke var i stand til å sykle, men hadde trodd jeg skulle klare å gå ;-) Ingen virkelige skader, men halve ansiktet skrubbet opp ‐ som jeg sa på jobben: «Det gjør bare vondt når jeg blunker». Begynner å komme i farta igjen nå, men var litt mer sigen enn vanlig rett etter jobb. Legger ut mer stoff i morgen, så vi får testet litt flere ting. Tar blant annet kirkene i Vestby; jeg fokuserer litt på stoff derfra av hensyn til portaltesten. Chris Nyborg (Cnyborg) 22. okt 2007 kl. 22:13 (CEST)

Det er et view i databasen som ikek er lagt inn. Hvis det dukker opp feilmeldinger så kan dette være grunnen. Det er også et par andre utvidelser som muligens må på plass. — John Erling Blad (Jeblad) 23. okt 2007 kl. 00:08 (CEST)

La inn et par kirker for å teste en mal til, og lagde {{kirker i område}} som nå er i bruk på Såner kirke og Vestby kirke (og kommer på et par til). Det var enkelt å greit å lage den, og vi kan etterhvert få laget standardmaler for ting det er naturlig å bruke slikt på. Chris Nyborg (Cnyborg) 23. okt 2007 kl. 19:20 (CEST)

Da er alle de fem kirkene i Vestby lagt ut, fungerte fint det. Chris Nyborg (Cnyborg) 23. okt 2007 kl. 19:36 (CEST)

Et spørsmål meldte seg rett etter at jeg hadde lagret siste innlegg: Hvordan takler den alfabetisering? Ta f.eks. Ås kommune, hvor man finner Kroer kirke, Ås arbeidskirke og Ås hovedkirke, eller Vestre Toten hvor man finner Eina kirke, Raufoss kirke og Aas kirke. Vil Ås og Aas bli riktig plassert, eller er det evt. mulig å spesifisere noe? Dette blir komplisert, men for enkelte temaer kan det være avgjørende for at malen fungerer. Sorteringsmetoden er ordered, men er den spesifisert etter norsk alfabet, og da med aa som å? Chris Nyborg (Cnyborg) 23. okt 2007 kl. 19:41 (CEST)

Jeg har ikke gravd nok i koden til å si noe om dette. Jeg vil tro at vi kan gjøre noen tilpassinger slik at den fungerer om det skulle vise seg at det blir feil noe sted. — John Erling Blad (Jeblad) 14. nov 2007 kl. 06:06 (CET)

Supportmaler for fotografer

Istedenfor å opprette separate maler for hver enkelt fotograf så foreslår jeg at vi lager supportmaler som lager standardutlegg for «self», «owner», «credit», «license» og muligens andre. De siste er vel typisk de ordinære lisensene. «Self» er en notis om at bildet er tatt av opplaster. «Owner» er en notis om at bildet er lastet opp av billedeier. «Credit» er en henstilling om å kreditere bildet. — John Erling Blad (Jeblad) 20. okt 2007 kl. 19:11 (CEST)

Det er greit å ha egne maler da det også er mulig å bruke disse til å legge bildene i en kategori over brukerens bilder. Eksempel fra commons, mal kategori--Nina Aldin Thune (Nina) 20. okt 2007 kl. 20:41 (CEST)

En mal {{self|John Erling Blad}} kan legge bildene i en kategori Photos by John Erling Blad. Alle filer lastet opp av en bruker kan hentes ut slik. — John Erling Blad (Jeblad) 20. okt 2007 kl. 21:04 (CEST)

En egen kategori hvor en ser bildene sine som et galleri er veldig oppmuntrende for gode bidragsytere. Det har jeg erfaring for. --Nina Aldin Thune (Nina) 20. okt 2007 kl. 22:00 (CEST)

Er enig i at det bør gjøres mulig å ha en automatisk fotografmal, men vi trenger vel ikke dermed å «bannlyse» individuelt tilpassede maler? En mal som {{FIH}} eller {{Olve Utne}} vil kunne gjøre det enkelt for brukere som har bestemt seg for lisens o.a. å sette inn den ferdigtygde malen direkte. Dessuten kan det jo være morsomt og motiverende å få lov til å utforme sin egen mal...? :-) Olve Utne 22. okt 2007 kl. 15:15 (CEST)

Hovedgrunnene for å lage lister er å unngå å miste oversikten over hvem som laster opp hva, og sikre at ikke kategorirommet blir for uoversiktelig. — John Erling Blad (Jeblad) 14. nov 2007 kl. 06:09 (CET)

Timeline

Da er EasyTimeline lagt til. Det finnes en annen utvidelse for å produsere grunnlagsdata til denne, men den er ikke lagt til. — John Erling Blad (Jeblad) 21. okt 2007 kl. 17:58 (CEST)

Three examples of what is possible. For more extensive examples see

• WW II - Pacific Theatre
• History of Computing
• Tour de France Sieger
• Vocal and instrumental pitch ranges (a nice example of a diagram that is not a timeline at all)
• Complete timeline of Macintosh models
• English Monarchs

<timeline> ImageSize = width:160 height:550 PlotArea = width:50 height:530 left:50 bottom:10 DateFormat = yyyy Period = from:1919 till:1991 TimeAxis = orientation:vertical ScaleMajor = unit:year increment:5 start:1920 there is no automatic collision detection, so shift texts up or down manually to avoid overlap Define $dx = 25 # shift text to right side of bar PlotData= bar:Leaders color:red width:25 mark:(line,white) align:left fontsize:S from:start till:1922 shift:($dx,15) text:Vladimir~Ilyich~Lenin from:1922 till:1953 shift:($dx,5) text:Josef Stalin from:1953 till:1964 shift:($dx,5) text:Nikita~Khrushchev from:1964 till:1982 shift:($dx,5) text:Leonid~Brezhnev from:1982 till:1984 shift:($dx,-12) text:Yuri~Andropov from:1984 till:1985 shift:($dx,4) text:Konstantin~Chernenko fontsize:XS from:1985 till:end shift:($dx,10) text:Mikhail~Gorbachev </timeline>

<timeline> ImageSize = width:800 height:100 PlotArea = left:65 right:15 bottom:20 top:5 AlignBars = justify Colors = id:neogene value:rgb(0.99215,0.8,0.54) id:paleogene value:rgb(1,0.7019,0) id:cretaceous value:rgb(0.5,0.764,0.1098) id:jurassic value:rgb(0.302,0.706,0.5) id:triassic value:rgb(0.403,0.765,0.716) id:permian value:rgb(0.404,0.776,0.867) id:carboniferous value:rgb(0.6,0.741,0.855) id:devonian value:rgb(0.6,0.6,0.788) id:silurian value:rgb(0.694,0.447,0.714) id:ordovician value:rgb(0.976,0.506,0.651) id:cambrian value:rgb(0.984,0.5,0.373) id:neoproterozoic value:rgb(0.792,0.647,0.583) id:mesoproterozoic value:rgb(0.867,0.761,0.533) id:paleoproterozoic value:rgb(0.702,0.698,0.369) id:eoarchean value:rgb(0.5,0.565,0.565) id:paleoarchean value:rgb(0.6,0.592,0.569) id:mesoarchean value:rgb(0.698,0.65,0.6) id:neoarchean value:rgb(0.796,0.804,0.784) id:ediacaran value:rgb(0.918,0.847,0.737) id:cryogenian value:rgb(0.863,0.671,0.667) id:tonian value:rgb(0.796,0.643,0.424) id:stratherian value:rgb(1,1,0.8) # light yellow id:calymmian value:rgb(1,1,0.8) # light yellow id:orosirian value:rgb(1,1,0.8) # light yellow id:rhyacian value:rgb(1,1,0.8) # light yellow id:siderian value:rgb(1,1,0.8) # light yellow id:ectasian value:rgb(1,1,0.8) # light yellow id:stenian value:rgb(1,1,0.8) # light yellow id:cenozoic value:rgb(1,1,0) id:mesozoic value:rgb(0.5,0.6784,0.3176) id:paleozoic value:rgb(0.5,0.7098,0.835) id:phanerozoic value:rgb(0.7019,0.886,0.819) id:proterozoic value:rgb(0.8,0.85,0.568) id:archean value:rgb(0.6,0.6784,0.6745) id:hadean value:rgb(0.4,0.4,0.4) id:black value:black id:white value:white Period = from:-4567.17 till:0 TimeAxis = orientation:horizontal ScaleMajor = unit:year increment:500 start:-4500 ScaleMinor = unit:year increment:100 start:-4500 Define $markred = text:"*" textcolor:red shift:(0,3) fontsize:10 PlotData= align:center textcolor:black fontsize:8 mark:(line,black) width:25 shift:(0,-5) bar:eon at: 0 align:right $markred at: -542 align:left $markred shift:(2,3) from: -542 till: 0 text:Phanerozoic color:phanerozoic from:-2500 till: -542 text:Proterozoic color:proterozoic from:-3800 till: -2500 text:Archean color:archean from: start till: -3800 text:Hadean color:hadean bar:era from: -65.5 till: 0 text:C~z shift:(0,1.5) color:cenozoic from: -251 till: -65.5 text:Meso~zoic shift:(0,1.5) color:mesozoic from: -542 till: -251 text:Paleo~zoic shift:(0,1.5) color:paleozoic from: -1000 till: -542 text:Neoprote-~rozoic shift:(0,1.8) color:neoproterozoic from:-1600 till: -1000 text:Mesoproterozoic color:mesoproterozoic from:-2500 till: -1600 text:Paleoproterozoic color:paleoproterozoic from:-2800 till: -2500 text:Neo-~archean shift:(0,1.5) color:neoarchean from:-3200 till: -2800 text:Meso-~archean shift:(0,1.5) color:mesoarchean from:-3600 till: -3200 text:Paleo-~archean shift:(0,1.5) color:paleoarchean from:-3800 till: -3600 text:Eoar-~chean shift:(0,0.5) color:eoarchean fontsize:6 from:start till: -3800 color:white bar:period fontsize:6 from: -23.03 till: 0 color:neogene from: -65.5 till: -23.03 color:paleogene from: -145.5 till: -65.5 color:cretaceous from: -199.6 till: -145.5 color:jurassic from: -251 till: -199.6 color:triassic from: -299 till: -251 color:permian from: -359.2 till: -299 color:carboniferous from: -416 till: -359.2 color:devonian from: -443.7 till: -416 color:silurian from: -488.3 till: -443.7 color:ordovician from: -542 till: -488.3 color:cambrian from: -630 till: -542 text:Ed. color:ediacaran from: -850 till: -630 text:Cryo-~genian color:cryogenian shift:(0,0.5) from: -1000 till: -850 text:Ton-~ian color:tonian shift:(0,0.5) from: -1200 till: -1000 text:Ste-~nian color:mesoproterozoic shift:(0,0.5) from: -1400 till: -1200 text:Ect-~asian color:mesoproterozoic shift:(0,0.5) from: -1600 till: -1400 text:Calym-~mian color:mesoproterozoic shift:(0,0.5) from: -1800 till: -1600 text:Stath-~erian color:paleoproterozoic shift:(0,0.5) from: -2050 till: -1800 text:Oro-~sirian color:paleoproterozoic shift:(0,0.5) from: -2300 till: -2050 text:Rhy-~acian color:paleoproterozoic shift:(0,0.5) from: -2500 till: -2300 text:Sid-~erian color:paleoproterozoic shift:(0,0.5) from: start till: -2500 color:white </timeline> <timeline> ImageSize = width:800 height:100 PlotArea = left:65 right:15 bottom:20 top:5 AlignBars = justify Colors = id:neogene value:rgb(0.99215,0.8,0.54) id:paleogene value:rgb(1,0.7019,0) id:cretaceous value:rgb(0.5,0.764,0.1098) id:jurassic value:rgb(0.302,0.706,0.5) id:triassic value:rgb(0.403,0.765,0.716) id:permian value:rgb(0.404,0.776,0.867) id:carboniferous value:rgb(0.6,0.741,0.855) id:devonian value:rgb(0.6,0.6,0.788) id:silurian value:rgb(0.694,0.447,0.714) id:ordovician value:rgb(0.976,0.506,0.651) id:cambrian value:rgb(0.984,0.5,0.373) id:cenozoic value:rgb(1,1,0) id:mesozoic value:rgb(0.5,0.6784,0.3176) id:paleozoic value:rgb(0.5,0.7098,0.835) id:phanerozoic value:rgb(0.7019,0.886,0.819) id:black value:black id:white value:white id:darkgreen value:rgb(0,0.35,0) Period = from:-542 till:0 TimeAxis = orientation:horizontal ScaleMajor = unit:year increment:100 start:-500 ScaleMinor = unit:year increment:10 start:-540 Define $markred = text:"*" textcolor:red shift:(0,3) fontsize:10 Define $markgreen = text:"*" textcolor:darkgreen shift:(0,3) fontsize:10 PlotData= align:center textcolor:black fontsize:8 mark:(line,black) width:25 shift:(0,-5) bar:eon at: 0 align:right $markred at: -542 align:left $markred shift:(2,3) from: -542 till: 0 text:Phanerozoic color:phanerozoic bar:era at: 0 align:right $markgreen at: -65.5 align:left $markgreen shift:(2,3) from: -65.5 till: 0 text:Cenozoic color:cenozoic from: -251 till: -65.5 text:Mesozoic color:mesozoic from: -542 till: -251 text:Paleozoic color:paleozoic bar:period fontsize:8 from: -23.03 till: 0 text:Neo-~gene shift:(0,0.5) color:neogene from: -65.5 till: -23.03 text:Paleo-~gene shift:(0,0.5) color:paleogene from: -145.5 till: -65.5 text:Cretaceous color:cretaceous from: -199.6 till: -145.5 text:Jurassic color:jurassic from: -251 till: -199.6 text:Triassic color:triassic from: -299 till: -251 text:Permian color:permian from: -359.2 till: -299 text:Carboniferous color:carboniferous from: -416 till: -359.2 text:Devonian color:devonian from: -443.7 till: -416 text:Sil-~urian shift:(0,0.5) color:silurian from: -488.3 till: -443.7 text:Ordovician color:ordovician from: -542 till: -488.3 text:Cambrian color:cambrian </timeline> <timeline> ImageSize = width:800 height:100 PlotArea = left:65 right:15 bottom:20 top:5 AlignBars = justify Colors = id:neogene value:rgb(0.99215,0.8,0.54) id:paleogene value:rgb(1,0.7019,0) id:cenozoic value:rgb(1,1,0) id:holocene value:rgb(1,1,0.702) id:pleistocene value:rgb(1,0.922,0.384) id:pliocene value:rgb(1,0.922,0.675) id:miocene value:rgb(1,0.871,0) id:oligocene value:rgb(0.918,0.776,0.447) id:eocene value:rgb(0.918,0.678,0.263) id:paleocene value:rgb(0.92,0.576,0.005) id:black value:black id:white value:white id:darkgreen value:rgb(0,0.35,0) Period = from:-65.5 till:0 TimeAxis = orientation:horizontal ScaleMajor = unit:year increment:10 start:-60 ScaleMinor = unit:year increment:1 start:-65 Define $markgreen = text:"*" textcolor:darkgreen shift:(0,3) fontsize:10 PlotData= align:center textcolor:black fontsize:8 mark:(line,black) width:25 shift:(0,-5) bar:era at: 0 align:right $markgreen at: start align:left $markgreen shift:(2,3) from:start till: 0 text:Cenozoic color:cenozoic bar:period from: -23.03 till: 0 text:Neogene color:neogene from:start till: -23.03 text:Paleogene color:paleogene bar:epoch from: -0.1 till: 0 color:holocene from: -1.806 till: -0.1 text:P color:pleistocene from: -5.332 till: -1.806 text:Plio-~cene shift:(0,1) color:pliocene fontsize:7 from:-23.03 till: -5.332 text:Miocene color:miocene from:-33.9 till:-23.03 text:Oligocene color:oligocene from:-55.8 till:-33.9 text:Eocene color:eocene from:start till:-55.8 text:Paleocene color:paleocene </timeline>

Bokmål vs Nynorsk vs dialekt

Målføreproblematikken er nok litt større enn bare bokmål/nynorsk, også dialekter må tas med. Det er tatt i bruk en utvidelse/tilpassing inne på meta som tillater flere språk i en og samme artikkel.[2] Muligens kan dette være aktuelt her inne også for å få en viss struktur på problemet. — John Erling Blad (Jeblad) 21. okt 2007 kl. 18:46 (CEST)

Vi må i dette tilfellet finne ut hva som er riktig måte å navngi dialekter, og om dialektene skal «normaliseres» på noen måte. Som et første forslag foreslår jeg at vi bruker nn for nynorsk, nb for bokmål og så lar no angi det som er språket i selve artikkelen. Formene nn/nb lar vi da angi en oversatt artikkel, eller synopsis på det aktuelle målføret. Der det er naturlig anbefaler vi at det skrives synopsis på engelsk. Dette vil radikalt bedre tilgjengeligheten for norsk-amerikanere. Hvis vi kommer opp med en god måte å angi spesifikke dialekter så kan vi bruke dette, men jeg ser vel nokså store problemer med å finne frem til slikt. — John Erling Blad (Jeblad) 21. okt 2007 kl. 19:15 (CEST)

For et kjapt lite eksempel, se Sigurd Islandsmoen. — John Erling Blad (Jeblad) 21. okt 2007 kl. 19:34 (CEST)

Se også m:Multilang, m:LanguageSelector og m:Polyglot. Disse har tildels problemer med caching. Muligens er det bedre å lage en liten utvidlese ala Multilang som kan spille sammen med js-løsningen som er angitt her. Dette vil gjøre det noe enklere å kode slikt konsistent. — John Erling Blad (Jeblad) 22. okt 2007 kl. 03:34 (CEST)

JavaScript

The JavaScript method is activated by default on the Wikimedia MetaWiki. You can disable it by adding the following line to your script file.

ls_enable = false;

You can see an example of the JavaScript in action below. If language selection is disabled, all of the text will be displayed. The same happens if the cache needs a refresh. <div class="multilingual"> {{ls|br|Brezhoneg eo an destenn-mañ.}} {{ls|ca|Aquest text és en català.}} {{ls|da|Denne tekst er på dansk.}} {{ls|de|Dieser Text ist Deutsch.}} {{ls|el|Αυτό το κείμενο είναι ελληνικό}} {{ls|en|This text is English.}} {{ls|et|See tekst on eesti keeles.}} {{ls|ar|هذا النّص عربي.}} {{ls|fi|Tämä teksti on suomeksi.}} {{ls|fr|Ce texte est Français.}} {{ls|it|Questo testo è in Italiano.}} {{ls|ja|この文章は日本語です。}} {{ls|la|Haec nota Latine scriptus est.}} {{ls|nl|Deze tekst is in het Nederlands.}} {{ls|nn|Dette er ein tekst på nynorsk.}} {{ls|nb|Denne teksten er på bokmål.}} {{ls|no|Denne teksten er på «norsk».}} {{ls|oc|Aqueste tèxt es en Occitan.}} {{ls|pl|Ten tekst jest po polsku.}} {{ls|pt|Este texto está em Português.}} {{ls|sc|Custu testu est in Sardu.}} {{ls|tr|Bu tekst Türkçe'dir.}} {{ls|zh|这些文字是中文。}} </div>

When specifying a language, use the code, not the full name.

You can view the JavaScript code at MediaWiki:Monobook.js.