Wikipedia-diskusjon:Underprosjekter/Infoboks

message: Jeg håper personlig vi kan ta i bruk den første varianten av infobokser, men det er også en del andre ting som bør diskuteres.
*Infobokser importeres ofte blindt fra andre språk (spesielt engelsk), hvordan takle kompitablitet/utfordringer med dette
*Parameternavn er forskjellige, boter tilgjenglige til å ordne?
*Slå sammen maler,  er en "universiell" mal til politiske verv. Kan også gjøres på andre områder. 
*Maldokumentasjon: På egen side, eller underside? 
Mvh Røed (d · en) 25. mai 2008 kl. 22:27 (CEST)
replies: text: Jeg hadde tenkt å gjennomstarte dette prosjektet selv, men du var modigere enn meg.

text: *Infobokssystem: (gav den id'er for å skille mellom dem) Ja til ID 1. Felttittel og verdi oppgis som parametre i malen, de henger ikke bare etter som på ID 2.

text: *Engelske infobokser:Noen av disse er uhyre komplekse, så komplekse at jeg i noen tilfeller tviler på at andre en de som skrev dem forstår hele malen. Noen kan med fordel forenkles.

text: *Parameternavn: Mener å ha hørt at dette må gjøres mede regxp, og i så fall må bot kjøres manuelt (diff godkjennes av botfører før endring).

text: *Universielle maler: Absolutt mulig. Mener at også  er en slik.

text: *Maldokumentasjon: Maldokumentasjon, kategorier og interwikilinker på Mal:Infoboks xx/doc og en  i <noinclude>-tagger på Mal:Infoboks xxx. Malen inkapsles i <includeonly>-tagger.

text: — Kagee 26. mai 2008 kl. 09:36 (CEST)
thread_title:  Utfordringer 

message: Jeg har gjennomgått kategorien og har sortert de etter type som jeg har lagt her. selle og infobox er desidert mest brukt,  i tillegg er det en del jeg er usikker på. Mvh Røed (d · en) 26. mai 2008 kl. 21:15 (CEST)
thread_title:  Dagens tall 

message: Jeg mener prosjektet bør fokusere på å finne frem til noen enkle entydige mekanismer for navngiving av parametre, det bør være et mål å generalisere bokser der det er mulig – også ved bruk ev delmaler der det er mulig, det bør være et mål at infobokser kan brukes for å strukturere data, og det bør være et mål at infobokser kan tilpasses forskjellige visuelle design (skin). Diskusjoner om farger og fonter bør tas ved tilpassing til de enkelte skin, og hvis ikke implementasjonen kan tilpasses så er den feilet. Malverket bør også være såvidt enkelt at flest mulig kan bruke det, men det er ikke nødvendigvis noe krav (jeg tror det er uønsket) at bokser skal sprudle i alle mulige farger etter dagsformen til den som bruker de. — Jeblad 26. mai 2008 kl. 22:36 (CEST)
thread_title:  Noen momenter 

message: I sin tid opprettet jeg tre maler jeg siden har benyttet på korearelaterte emner for å vise skrivemåter på ulike måter (,  og ). Jeg visste neppe hva jeg gjorde da jeg laget de, med andre eksisterende maler som eksempler, jeg var bare glad for at de så sånn noenlunde ålreite ut og at de kunne brukes. Etter hvert har behovet økt, og jeg er ikke lenger fornøyd med hva de tre malene kan brukes til. Jeg har observert at en på sv: og en: opererer mer avanserte maler enn hva jeg har klart å prestere (så langt). På sv: (Mall:Koreanamn) har en tatt ett steg, mens en på en: (Template:Koreanname) har noe skikkelig avanserte greier med mange valgmuligheter som dekker de fleste behov. Jeg har sett på dette selv så vidt, men innser at dette er et studium i seg selv. Men å få samlet de tre i en god en bør være et mål. Med adekvat veiledning kan jeg gjøre jobben selv. --Frodese 28. mai 2008 kl. 20:27 (CEST)
thread_title:  Korea-maler 

message: En måte å løse problemet med at en skal ha med spesielle ikoner er å plassere de i headeren til infoboksen. I noen tilfeller er dette gjort uten å tilpasse boksen for å vise et slikt ikon, slik som på Knut Hamsun – noen ganger også i egen boks slik som i bunnen av artikkelen Urnes stavkirke, men jeg mener at en del slike ikon kan vises enkelt og entydig som en integrert del av boksen. Ute til høyre er et skjermdump av øvre høyre hjørne av en slik boks. Denne ble lagd for et annet formål, men konseptet kan tilpasses slik at det brukes andre ikon og annen lenking. En kan også tenke seg å legge på ekstra tekst på ikonet slik at en kan ha generiske medaljer slik at den her typen utmerkelser er enklere å bruke der vi mangler korrekte bilder, det vil si at medaljene er verk slik som for :Bilde:Nobel prize medal.svg. En ulempe med slik lenking på bilder er at det ikke kommer frem at bildet faktisk lenker til en artikkel, slikt omtales som skjulte bruksegenskaper og er generelt et no–no. Likevel mener jeg det er greit for som oftest er dette utmerkelser som gjør vedkommende relevant for et leksikon og vil derfor bli en del av omtalen. — Jeblad 1. jun 2008 kl. 20:37 (CEST)
thread_title:  Medaljer, våpen, etc 

message: Har nettopp lagt inn mal for militær person på Horatio Nelson, kopierte den fra Erwin Rommel. Det virker imidlertid som en må angi bilder på en måte jeg ikke er vant med fra andre maler og undertekst fungerer heller ikke... Noen som kan se på det? Ulf Larsen 14. jun 2008 kl. 00:39 (CEST)
replies: text: Var i gang allerede.  :)  Kort historie: «thumb» bør unngås, men størrelse bør settes, når bildet ellers er for stort; jeg valgte «250px» og tror det er rimelig.  Season to taste.  :)  — the Sidhekin (d) 14. jun 2008 kl. 00:58 (CEST)
replies: text: : Jeg begynte med det som fungerer ellers i slike maler, dvs legger inn bildenavn og kun det, det virker som malen så skalerer bildet selv så det passer inn. Om det er tilfelle (dvs at jeg ikke bare har vært heldig) så hadde vel det vært gunstig å ha i denne malen også? Jeg har aldri satt fast billedstørrelse før i tilsvarende maler, se f.eks på slagmalen, der kan en bare legge inn et stort bilde og det skalerer automagisk. I andre maler er det heller ikke nødvendig å benytte klammer, se feks på Andre verdenskrig, en legger inn fullt bildenavn og det er det. mvh - Ulf Larsen 14. jun 2008 kl. 08:14 (CEST)
replies: text: :: Jeg har ikke oversikt over hva som er mest utbredt.  Wikipedia:Underprosjekter/Infoboks forsøker å standardisere infoboksene.  Kanskje noe for dem?  — the Sidhekin (d) 14. jun 2008 kl. 13:57 (CEST)
thread_title:  Hva er det med denne malen? 

message: De infobokser som har mulighet for bilde (det er vel de fleste), bør også ha støtte for byline. For de infoboksene som bruker , ,  og tilsvarende, kan nå bruke . Det gjenstår nok fortsatt et par infobokser som ikke støtter byline, og det burde være en av underprosjektets oppgaver. — H92 (d · b · @) 22. aug 2008 kl. 18:09 (CEST)
thread_title:  Byline 

message: I infoboks offiser, som denne, Boris Sjaposjnikov er det lagt inn internlenking på født/død. Det virker unødvendig da samme informasjon jo også er internlenket først i løpende tekst, foreslår at internlenkingen i infoboksen på født/død fjernes. Ulf Larsen 22. okt 2008 kl. 17:24 (CEST)
replies: text: Jeg skal se på muligheten for å konvertere den levde-parameteren til født/død-parametre.. da kan det jo kanskje samtidig gjøres noen triks der. Stigmj 22. okt 2008 kl. 17:30 (CEST)
replies: text: :Og det har jeg nå gjort. Stigmj 25. okt 2008 kl. 20:29 (CEST)
thread_title:  Infoboks offiser 

message: Jeg har opprettet en ny fellesmal for sivile skip som er ment å erstatte Infoboks ruteskip, Infoboks motorskip, Infoboks passasjerskip og Infoboks tankskip, nemlig Mal:Infoboks skip. Har lagt en notis på mal-sidene for at ikke nye artikler tar dem i bruk. Driver og erstatter passasjerskip-boksene nå, og har tenkt å ta de andre etterhvert. Når en mal er ferdig «utfaset», skal jeg bare merke den med hurtigslett, eller behøves en diskusjon først? Aldebaran 15. apr 2009 kl. 06:54 (CEST)
replies: text: Så lenge en mal er helt utfaset og det ikke er tenkelig at den skal brukes lenger, så kan den bare slettes. Bare pass på at all informasjon er videreført i en eller annen form. Stigmj 15. apr 2009 kl. 09:10 (CEST)
replies: text: :Da har jeg faset ut Mal:Infoboks passasjerskip, Mal:Infoboks motorskip, og Mal:Infoboks tankskip, og merket dem for hurtigslett. Mvh Aldebaran 27. apr 2009 kl. 06:06 (CEST)
replies: text: ::Og der er de slettet. Stigmj 27. apr 2009 kl. 08:21 (CEST)
thread_title:  Infobokser skip 

message: Jeg liker egentlig mye bedre infoboksene på engelsk WP, kanskje pga. de horisontale skillestrekene og at det brukes litt mindre skriftstørrelse. Har det vært diskutert om vi skulle legge oss på et utseende mer likt det på engelsk WP? – Danmichaelo 10. jul 2011 kl. 16:48 (CEST)
replies: text: Det har vel ikke vært noen spesiell diskusjon angående det enda, men du er jo velkommen til å gjøre dine egne endringer i din egen CSS-fil. Stigmj 10. jul 2011 kl. 22:49 (CEST)
thread_title:  Utseende til infobokser på norsk og engelsk WP 

message: Har en tanke jeg må få skrevet ned for å se om det mulig å gjennomføre:
Gitt at vi har følgende moduler:
* Infoboks-layout modul (Modul:Infobox/layout) - får en ferdigprosessert datastruktur fra Infoboks-builder og lager en layout (tabell/whatever) som blir sluttresultatet
* Infoboks-builder modul (Modul:Infobox/builder) - får en datastruktur fra Infoboks-konfigurasjon samt input fra wiki og slår opp i wikidata ved behov og lager en datastruktur med alle data som skal inn i infoboksen som videresendes til Infoboks-layout for selve "utskriften"
* Infoboks-konfigurasjon modul (Modul:Infobox/config) - får et hint om hvilken type infoboks som skal lages, henter grunnkonfig fra et felleslager (f.eks. Modul:Infobox/config/bio), tar i mot overrides/exclusions/whatever fra en spesialisert Infoboks-spesialisering modul, lager en datastruktur og sender videre til Infoboks-builder
* Infoboks-spesialisering modul (f.eks. Modul:Infobox/config/bio/composer for komponist)- legger inn spesialiseringer i henhold til hvilken type infoboks dette er (f.eks. "bio" for biografi) og sender dette med input fra wiki videre til Infoboks-konfigurasjon.
Deretter har vi forskjellige maler som da peker på Infoboks-spesialisering-modulene i henhold til hvilken type infoboks som skal vises.
;Eksempel
# Artikkel Wolfgang Amadeus Mozart har lagt inn 
# Malen  kaller opp modulen Modul:Infobox/config/bio/composer
# Modulen Modul:Infobox/config/bio/composer har en datastruktur som setter spesialiserte verdier og "kaller opp" modulen Modul:Infobox/config
## Rekkefølgen her er viktig og definerer hvordan dette vil vises frem. Må lages mulighet for å overstyre grunn-konfig i neste modul på en eller annen måte. Bør også kunne endre rekkefølger / evt. sette inn etc. på en eller annen måte.
## Modul = bio/composer
## InheritsFrom = bio
## Religion_show = false (skal ikke vises generelt for komponister)
## Vekt_show = false (skal ikke vises generelt for komponister)
## Høyde_show = false (skal ikke vises generelt for komponister)
## Mor_show = false (skal ikke vises generelt for komponister)
## Far_show = false (skal ikke vises generelt for komponister)
## Stemmetype_wikiattributt = stemmetype (hva dette argumentet kalles i infoboksen i artikkelen)
## Stemmetype_property = P12345 (wikidata property)
## Stemmetype_list = 5 (hvis det er flere claims i WD, hvor mange skal listes opp før det lages en form for summary)
# Modulen Modul:Infobox/config henter opp grunn-strukturen basert på input (bio) fra modulen Modul:Infobox/config/bio, inkluderer spesialiseringene fra foregående modul og sender videre til Modul:Infobox/builder
## grunn-strukturene må inneholde referanser til wikidata. Ser for meg at det må være et oppkall til en standard navngitt funksjon som sørger for å returnere en ferdig datastruktur. Hvis det skal utføres kalkuleringer etc. så må dette gjøres her
## Rekkefølgen her er viktig og definerer hvordan dette vil vises frem
## Modul = bio
## Religion_wikiattributt = religion
## Religion_property = P1234
## osv. 
# Modulen Modul:Infobox/builder leser config, legger inn data fra wiki, evt. fra Wikidata, sender videre til Modul:Infobox/layout
# Modulen Modul:Infobox/layout leser ferdig prosessert datastruktur og returnerer kun en ferdig formatert og utfylt infoboks.
Tanken her er videre at man kan, hvis ønskelig, overstyre alle default-settinger helt ute fra Infoboks-definisjonen i selve artikkelen. Så hvis man av en eller annen grunn finner det viktig å ha med høyde og vekt på en viss komponist (fra eksempelet ovenfor), så er det bare å definere opp da f.eks. "vekt_show = true" og "høyde_show = true", som vil få builder-modulen til å ta med dette fra WD, hvis dette finnes, evt. at det også defineres verdiene helt fra infoboksen. Definisjonen av radene må finnes i grunnkonfigurasjonen for infoboks-typen for at de skal kunne vises frem. Det bør også bestemmes hva som er autoritativt, WD eller lokal info. Jeg heller mot lokal info hvis dette finnes, men da må det også gjøres en vurdering av eksisterende definerte verdier i infoboksene (Ukens konkurranse?).
Det er ikke sikkert at en eventuell teknisk implementasjon av dette vil se ut akkurat som beskrevet ovenfor, men det er tanken med separeringen av funksjonsområder som er viktigst i dette. På denne måten blir "konstruksjonen" av infoboksene standardiserte og kanskje lettere separert? Et annet viktig spørsmål blir videre om dette blir for komplisert og "tungt" for å kunne kjøre fornuftig?
 +  Jeg pinger noen som kanskje er interesserte i å diskutere en slik mulig fremgangsmåte. Jeg ber dere om å ha en åpen innstilling samt å komme med konstruktive innspill og spørsmål rundt dette forslaget. Det er mulig noen andre har gjort noe tilsvarende allerede? Jeg skal innrømme at jeg har blitt litt påvirket av løsningen hos frwiki hvor de gjør noe "tilsvarende" med tanke på modulariseringen, men jeg har ikke sett på detaljene i dette enda. Stigmj (diskusjon) 23. mar. 2016 kl. 12:52 (CET)
replies: text: Det er et sentralt prosjekt for å lage en gjenbrukbar infoboks. Før det er klart hvilken vei dette tar så er det bortkastet tid å lage konkurrerende forslag. Det sagt så virker det ikke som noen av de eksisterende infoboksene fanger opp at dette ikke handler om å presentere en stilistisk arketype, men om data knyttet til en reell instans. Ole Ellefsæter er ikke langrennsløper, friidrettsutøver eller visesanger, han er langrennsløper, friidrettsutøver og visesanger. Det har som konsekvens at hvilken data som skal fremvises er en funksjon av alle hans aktiviteter. Vi forsøker å sette på en mal som så skal representere subjektets type, men subjektet har mange typer og noen (flesteparten) av subjektets aspekter kan være polymorfiske. Kort sagt vil det ikke gi mening å lage systemer som bruker fikserte maler for «komponister», «syklister», «jurister» og «politikere». Vi har politikere som er utdannede jurister og sykler til jobben, og som komponerer på si'. — Jeblad 23. mar. 2016 kl. 12:59
replies: text: :Ingen har lagd noe som helst i forbindelse med dette forslaget enda, men dersom du har noen konstruktive innspill på idéen må du gjerne komme med de. Idéene rundt dette forslaget kan, hvis de har løsninger rundt våre spesifikke behov, evt. gjenbrukes til å vurdere og/eller komme med innspill i et sentralt prosjekt. Stigmj (diskusjon) 23. mar. 2016 kl. 13:10 (CET)

text: :Siden du har funnet på å utvide svaret ditt i etterkant, så svarer jeg her på det du utvidet med: Hvis vi da lager grunnmalene så omfattende som mulig, så blir spesialiseringene kun brukt til å gjøre "utvalg" fra grunnmalene. Den eneste ulempen jeg da ser er at en person ikke kan ha attributter fra en helt annen klasse (altså at en komponist f.eks. ikke kan ha et deplasement eller ammunisjonskapasitet). Dette betyr at dersom du har en komponist som også skal ha attributter som vanligvis er tiltenkt en syklist, så kan du i infoboksen i artikkelen overstyre ved å si at "disse attributtene skal med likevel". Poenget mitt er at det ikke er nødvendigvis ønskelig å vise fram alt fra f.eks. Wikidata uten at det er gjort en individuell vurdering av dette av en bruker. Selv om Ole Ellefsæter er en visesanger, så betyr ikke det at det er disse bragdene som ønskes visualisert i infoboksen om ham, basert på en helhetsvurdering. Ved at brukerene som skriver artikkelen får muligheten til å påvirke infoboksen som genereres, gjør det oss fleksible nok til at dette kan bli akseptert. En ArticlePlaceholder-funksjon kan sikkert gjerne linkes opp i artikkelen på en måte for vise all sentral informasjon om vedkommende, men det er ikke nødvendigvis ønskelig i alle artikler. Stigmj (diskusjon) 23. mar. 2016 kl. 13:59 (CET)
replies: text: ::Det du beskrive er et hierarki med mange underklasser med store mengder overlapp (mixins). Det vi treger er derimot en enkelt infoboks som er polymorf. Såvidt jeg har forstått så er det den siste som blir forsøkt implementert i Capiunto. — Jeblad 23. mar. 2016 kl. 14:13 (CET)
replies: text: :::Jeg er tilhenger av poenget om at det ikke nødvendigvis pr. automatikk er ønskelig å fremvise alle parametre fra Wikidata. F.eks. kan dødsårsaker i noen sammenhenger være interessante og relevante, mens de under andre omstendigheter kan være utleverende, intimiderende og kanskje også irrelevante, f.eks. avhengig av hvilken tid man befinner seg i. Automatiserte data i infobokser øker sannsynligheten for at de fremviste  data til enhver tid er aktuelle, men jeg ser ikke dét som en motsetning til manuelle vurderinger av hvilke data som til enhver tid måtte befinne seg i infoboksen. Jeg føler meg aller mest trygg ved tenkning og automatisering frem og tilbake, ut og inn av boksen. Mvh. Orphée (diskusjon) 28. mar. 2016 kl. 14:09 (CEST)
replies: text: ::::Min tilnærming til dette er rent praktisk: Infoboks biografi er en god infoboks som godt kan utvides til også for eksempel å vise verv. Denne funksjonen finnes ikke i denne boksen idag, og man tvinges til å bruke infoboksen for personer med verv. Sistnevnte boks er på andre områder mindre fleksibel, og kan ikke overstyres for eksempel med hensyn til hvilke språk fødebyens navn skal oppgis. Eksemplet her er Erich Mende, hvis fødested i Wikidata oppgis med dagens navn, som er polsk.  Jeg vet at det også er et vanskelig spørsmål å velge språkversjon, men det er altså en annen diskusjon. Jeg vil oppfordre Stigmj til å fortsette sitt arbeid. --Trygve Nodeland (diskusjon) 24. apr. 2016 kl. 11:13 (CEST)
replies: text: :::::Historiske navn på byer, områder og land er et stebarn på wikipedia. Også ja takk herfra til at Stigmj fortsetter arbeidet med infoboksene. Mvh. Orphée (diskusjon) 25. apr. 2016 kl. 08:17 (CEST)
thread_title:  Ny måte å bygge infobokser 

message: Merk at det er planer om en ny måte å lage infobokser, kalt mw:Extension:Capiunto, men at prosjektet for øyeblikket er «stalled». Dette er også nevnt på Wikipedia:Torget/Arkiv/2016/mars#Nytt Lua-bibliotek for infobokser. — Jeblad 23. mar. 2016 kl. 13:36 (CET)
* RFC: Magic Infobox implementation (merk at denne RFC-en er stalled)
* RFC Meeting: triage! (2016-03-02, #wikimedia-office)
thread_title:  Capuinto 

message: Det som synes klart så langt er at det er utvalgskriterier og sorteringskriterier på flere nivåer. Det finnes muligens et eller flere øvre gruppenivå i en infoboks. Vi bruker nesten ikke noe slikt. Et tenkt gruppenivå kan for eksempel være fysiske dimensjoner på en innsjø. Det neste nivået er rader (innslag) i boksen, for eksempel antall innbyggere i en kommune. Dette tilsvarer omtrent blokkene med en bestemt type egenskap i dataelementet. Innenfor hver slik oppføring kan det finnes flere enkeltutsagn, for eksempel barnene til et subjekt. Hvert av disse barnene kan ha utsagn om oppføringen, for eksempel når en folketelling er gjort. Hvis det er et barn så kan omtalen av barnet være plassert i et eget dataelement. Hvordan ekstra data (qualifiers) knyttet til utsagnet blir brukt og presentert kan variere. Hvert av disse utsagnene kan også ha referanser, men de ekstra utsagnene har ikke enkeltreferanser.
Gjenganger for hvert av disse lagene er at det finnes en prioritering (kun det som ansees viktig tas med), en sortering (kan være annerledes enn prioriteringen), og en presentasjon (kan være tabularisk eller tekstlig). Prioritering, sortering, og presentasjon, kan være forskjellig for hvert av lagene. Noen ønsker å kunne påvirke prioriteringen i og med at det er forskjell på kunnskap til brukere og hva de anser som viktig. I noen tilfeller ønskes det en sortering i informasjon som kun skal brukes i tekst eller infoboks, eller begge. Uansett er det ønskelig med høy grad av lesbarhet i infoboksen, og det er en viss enighet om at mengden tegnsetting skal reduseres og at det skal brukes naturlig språk.
Det kan være verd å merke seg at tagging bør brukes for å gjøre det mulig å få til spesifikk grafisk presentasjon, men at begge hører med til det mer generiske «presentasjon». Foreløpig er det kun tagging som er gjort i Capiunto, det er opp til oss hvordan vi ønsker å style boksene.
Det vanskeligste punket er utvalgskriteriene (prioriteringen) av oppføringene, og spesielt hvordan dette skal vekselvirke med personlige valg og preferanser. Her er det sterke meninger, og ikke alle er like velbegrunnet. Generelt ønsker vi at noen data alltid tas med, mens et større sett skal være tilgjengelig. Dette større settet må da lastes, og så skjules det som er ansett uviktig. (Dette er beskrevet på Wikipedia:Tinget/Arkiv/2016-09#Brukerstyrt infoboks og Make a user configurable "property visibility" dialog for the infobox)
Hvordan vi skjuler det som ikke skal tas med er gitt av hvordan vi sorterer, og men om sortering og prioritering er avvikende så kan vi få problemer med fremvisningen. Det er ikke gitt at åpen og redusert fremvisning bruker samme sortering.
Det er svært lite støtte i Mediawiki og Lua for å generere lesbar tekst, så det kan gjøre det enklere å bruke spesiell tegnsetting. Sær tegnsetting kan gjøre infoboksen tunglest. Det finnes en fritt tilgjengelig publikasjonshåndbok for SSB som kan være til en viss hjelp, selv om føringene er forskjellige. — Jeblad 23. mar. 2016 kl. 14:09 (CET)
thread_title:  Noen føringer 

message: For å få rask og effektiv oppdatering må aktuelle maler være balanserte i fremtiden. Maler som ikke er balanserte vil fortsette å fungere, men de vil gi en langsom uttegning. Se også [RFC] Balanced templates. — Jeblad 23. mar. 2016 kl. 15:27 (CET)
thread_title:  Balanserte maler 

message: Jeg klør meg litt i hodet over [RFC] Visual Templates: Authoring templates with Visual Editor. Denne kan få konsekvenser for infobokser, men jeg tror den hovedsakelig får konskvens for malverk vi lager i en enkelt artikkel. Det vil si tabeller hvor rader lages med skreddersydde maler. — Jeblad 23. mar. 2016 kl. 20:35 (CET)
thread_title:  Visual templates 

message: Jag föreslår skapande av [[Mal:Infoboks dyrehage]] alt [[Mal:Infoboks dyrepark]] alt [[Mal:Infoboks dyrepark og zoo]] (se exempel da:Skabelon:Infoboks dyrepark og zoo, för att ge artikler om dyreparker bättre struktur. Dan Koehl (diskusjon) 19. jun. 2016 kl. 12:15 (CEST)
thread_title:  Mal:Infoboks dyrehage 

message: Jeg planlegger en oppdatering malen Mal:infoboks petrofelt, for å gjøre innholdet mer forståelig både for lesere og skribenter. Den eksisterende malen er uklar på hva de oppgitte volumtallene representerer, ressurser eller reserver?  Et utkast til ny mal vil være tilgjengelig en periode på min kladdeside Bruker:Toba/sandkasse.  Jeg vil sette pris på alle innspill til innhold, design og beskrivelse, her eller på min brukerside. Etter råd fra Torget er planen å lage en ny mal som erstatter den gamle.  Toba (diskusjon) 13. feb. 2020 kl. 19:06 (CET)
thread_title:  Infoboks petrofelt