WikiWoordenboek:De Kroeg

Welkom in de kroeg! Hier kunt u kletsen met andere WikiWoordenboek-gebruikers.

Archiefpagina's: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18

Proost! Schol!

Santé!, на здоровье, Prost, Cin cin!, şerefe!, Na zdrowie!, Cheers!, Skål!, εις υγείαν, לחיים, Kippis!, Salud, Noroc!, ممنون - شادباش, Na zdraví!, Kanpai! Een nieuw onderwerp toevoegen

Voorstellen: Taalcodering

Dit kopje is een vervolg op het vorige kopje waarin ik iets te enthousiast aan de slag ging. (Excuses daarvoor) Mijn gedachte is simpel: ik denk dat het goed is dat er meer zaken op WikiWoordenboek gekoppeld zouden moeten worden aan de betreffende taalcode. Alle pagina's (incl. taalspecifieke categorieën en sjablonen) behoren tot een bepaalde taal, maar die koppeling is niet altijd even handig/snel/makkelijk te leggen of niets eens aanwezig. Ik denk dat het goed is en praktisch om al deze pagina's te koppelen aan een bepaalde taalcode. Dat vergemakkelijkt de identificatie van een pagina behorende tot een taal voor gebruikers op dit project, voor bots, scripts en voor anderstalige gebruikers. Door betere identificatie kunnen fouten gemakkelijker opgespoord worden.

Dit is voor de categorieën in Categorie:Woorden naar taal, de Categorie:Onderwerpen naar taal en de Categorie:Talen naar familie reeds gebeurt door middel van Sjabloon:ISOc. Ik zou dat ook graag zien gebeuren voor:

• Woordsoort-sjablonen: ofwel in de naam ofwel als parameter standaard overal toegevoegd.
• Contextlabels: van taalnaam -> taalcode
• Taalspecifieke onderwerpcategorieën en taalspecifieke grammaticacategorieën
• De taalpagina's

Hieronder de voorstellen, graag reactie! Romaine 13 jan 2012 14:11 (CET)

Voorstel 1: woordsoort-sjablonen

Voorstel: ofwel in de naam van een sjabloon ofwel als parameter standaard overal de taalcode toegevoegd.
Deze optie zit standaard reeds in sjablonen zoals {{-adjc-}}, {{-adverb-}}, {{-name-}}, {{-noun-}} en anderen.
Aanvullende reden: op heel wat pagina's ontbreken een of meerdere taalspecifieke categorieën die daar eigenlijk wel horen te staan. Als het overal verplicht is om een taalcode ingevoegd te hebben, is het eenvoudig na te gaan waar er nog een taalcode ontbreekt zodat die ingevuld kan worden. Bijvoorbeeld: africano -> hier ontbreekt de Categorie:Bijvoeglijk naamwoord in het Portugees.

• Vraag 1: dienen de verbogen zelfstandige naamwoorden, werkwoordsvormen en bijvoeglijke naamwoordsvormen uit de respectievelijke categorie van zelfstandig naamwoord naar taal, werkwoord naar taal en bijvoeglijk naamwoord naar taal moeten blijven?
• Vraag 2: indien ja bij vraag 1: hoe zorgen we ervoor dat een verbuiging/vervoeging niet in de respectievelijke taalspecifieke categorie voor zelfstandig naamwoorden, werkwoorden of bijvoeglijk naamwoorden terecht komt (terwijl toch de taalcode wordt toegevoegd aan deze sjablonen)?

Graag reactie! Romaine 13 jan 2012 14:11 (CET)

 Steun Dit is een stukje historische achterstand: het was lange tijd gewoon niet mogelijk taalcodes te hangen aan dingen als {{-adverb-}}. Ik kan twee nadelen zien, die ik overigens niet als onoverkomelijk zie: Het wordt moeilijker te zien hoe ver een pagina is uitgewerkt. Immers de cat's bevatten eerst alleen maar lemma's die een blokje zoals adjcomp of -nlnoun- hadden. Nu krijgen ook heel summiere lemmas een plek in een cat. Ik denk echter niet data dat een ernstig probleem is omdat je met AWB kunt speuren naar wat ontbreekt. Een ander nadeel is dat we voor de vele taaltjes waar we misschien een woord of drie in het bestand hebben weer ieder drie cats genereren. En ja er zijn al erg veel cats. We zouden natuurlijk catlinks die maar een paar treffers opleveren voorlopig gewoon rood kunnen laten tot er voldoende materiaal is gegenereerd om een cat te rechtvaardigen, maar dat is ook een beetje een gedoe. Wat je kunt doen voor o.a. de vormen is een nocat parameter toevoegen die het aanhangen van een categorie onderdrukt. Ik zou liever niet alle vormen ook in de cats zien, behalve misschien voor vormen van voornaamwoorden. Daar zijn er niet zo veel van i.h.a. Bij substantiva en werkwoorden zou je anders in de vormen verzuipen.Jcwf 13 jan 2012 18:13 (CET)

Weet je toevallig een voorbeeld waar die nocat-parameter reeds gebruikt is? Het lijkt me het beste dezelfde opzet als in andere sjablonen dan te gebruiken. Romaine 13 jan 2012 18:29 (CET)

In {{adjcomp}} bijvoorbeeld

 Steun Zoals Cadfaell en Jcwf al hebben gezegd, graag met uitsluiting van de woordvormen. -- Curious 13 jan 2012 19:16 (CET)

In eerdere discussie ter sprake gekomen, en het herhalen waard (m.i. een welkome aanvulling):

1. I.p.v. "nocat" zouden we ook een variabele kunnen toevoegen aan het woordsoortsjabloon, dat het woord juist wel categoriseert, maar dan in de woordvorm-categorie. Dus bijv. {-noun-|ita|f} (f= form) zal het woord categoriseren in "Categorie:Zelfstandig-naamwoordsvorm in het Italiaans", maar niet in "Categorie:Zelfstandig naamwoord in het Italiaans". Zo kunnen we misschien ook overstappen op een systeem dat de woordsoortcategorie altijd via het woordsoortsjabloon (zoals -noun-, -adjc-) wordt geregeld, en niet meer afhankelijk is van een ander sjabloon. Dus zowel normale lemma's als woordvorm-lemma's kunnen dan altijd via het woordsoortsjabloon in de juiste categorie geplaatst worden.
2. Veel woordsoortsjablonen hebben 4 letters, maar {-adverb-} heeft er meer. Het is eerder al eens genoemd om het ook consistent 4 te maken en om te zetten naar {-advb-}, misschien is dit een goed moment om dit voorstel ook op te pakken. -- Curious 16 jan 2012 21:19 (CET)

 Steun Maar een nocat-parameter is niet handig. Want wat doe je als er inmiddels wel genoeg pagina's zijn? Hoe vind je dan de pagina's terug die nocat hebben? Ik zou liever zeggen 'doe het meteen zoals het hoort', dus altijd in de categorie. Dat levert later minder problemen met opruimen op. En ik vind een bijna lege categorie niet eens een probleem. Dat moedigt mensen ook aan om er meer aan toe te voegen. :) Wat betreft de vragen, ben ik het eens met vraag 1, en stel ik voor dat voor verbogen vormen een apart woordsoortsjabloon gemaakt wordt. Bijvoorbeeld {{-noun-form-}}. —CodeCat 14 jan 2012 13:53 (CET)

• Gedaan: verbogen zelfstandige naamwoorden hebben een {{-noun-|0}} gekregen zodat ze hiermee niet in de Categorie:Zelfstandig naamwoord in het taal terecht komen. Het kan zijn dat als een bepaald zelfstandig naamwoord meer dan één betekenis heeft, waarbij de tweede geen zelfstandig-naamwoordsvorm, dat die 0 er dan onterecht als parameter is ingevoegd. In dat enkele geval zal dat nog handmatig gecorrigeerd moeten worden dan. Romaine 29 jan 2012 06:19 (CET)
• Gedaan: werkwoordsvormen hebben een {{-verb-|0}} gekregen zodat ze hiermee niet in de Categorie:Werkwoord in het taal terecht komen. Het kan zijn dat als een bepaald werkwoord meer dan één betekenis heeft, waarbij de tweede geen werkwoordsvorm is, dat die 0 er dan onterecht als parameter is ingevoegd. In dat enkele geval zal dat nog handmatig gecorrigeerd moeten worden dan. Romaine 30 jan 2012 02:45 (CET)
• Gedaan: bijvoeglijke naamwoordsvormen hebben een {{-adjc-|0}} gekregen zodat ze hiermee niet in de Categorie:Bijvoeglijk naamwoord in het taal terecht komen. Het kan zijn dat als een bepaald bijvoeglijk naamwoord meer dan één betekenis heeft, waarbij de tweede geen bijvoeglijke naamwoordsvorm is, dat die 0 er dan onterecht als parameter is ingevoegd. In dat enkele geval zal dat nog handmatig gecorrigeerd moeten worden dan. Romaine 30 jan 2012 04:07 (CET)
• Gedaan: Woordsoortsjablonen die een taalcode behoeven en voortaan bij ontbreken te vinden zijn in Categorie:WikiWoordenboek:Pagina's met sjabloon zonder ingevulde taal, hebben nu allemaal een taalcode toegevoegd gekregen met mijn bot. Daarmee is dit voorstel, op wat vreemde zaken na die nog besproken moeten worden, afgerond. Romaine 5 feb 2012 02:11 (CET)

Voorstel 2: contextlabels

Voorstel: overal de labels omzetten van de taalnaam in de taalcode, dus: {{biologie|lang=Nederlands}} -> {{biologie|nld}}.

Graag reactie! Romaine 13 jan 2012 14:11 (CET)

 Steun Ik heb er al heel wat gedaan met mijn bot, maar dit zal wellicht niet alles geweest zijn (of het wordt nog altijd gebruikt). Annabel_(overleg) 13 jan 2012 17:10 (CET)

 Steun, waarbij wel opgemerkt moet worden dat er een paar sjablonen zijn waar de oude syntax om technische redenen gehandhaafd is. Zo uit mijn hoofd weet ik niet welke, maar het is wel zinnig de vervanging sjabloon voor sjabloon te doen. Contextsjablonen en woordsoortsjablonen kunnen al wel.

Aanvulling: Ik denk dat het goed is om als overal de |lang= is omgezet het gebruik van deze parameter niet meer mogelijk te maken, of is dat bezwaarlijk? Romaine 13 jan 2012 18:31 (CET)

Het zou wenselijk zijn, maar er zijn inderdaad wat problemen. Vooral als het sjabloon een hele zooi parameters heeft wordt het snel verwarrend te veel onbenoemde parameters (d.w.z. 1,2,3) te hebben. {{noun-form}} is daar een voorbeeld van. Een alternatief zou zijn om de |lang= parameter te vervangen door een |ISO= parameter die de isocode als invoer vraagt in plaats van de hele taalnaam. Jcwf 14 jan 2012 18:14 (CET)

Het gaat hier in het voorstel alleen om contextlabels en met die sjablonen zullen we niet veel last krijgen van een te veel aan parameters denk ik. Romaine 14 jan 2012 18:41 (CET)

Als je alleen de contextlabels bedoelt, dan mag na de omzetting wat mij betreft de functie |lang= onmogelijk gemaakt worden. -- Curious 16 jan 2012 22:15 (CET)

 Steun Aanhakend bij Jcwf, bijv. bij Sjabloon:noun-form is het nog niet mogelijk om |lang= te vervangen door de ISO-code. Er zijn er vast enkele meer... -- Curious 13 jan 2012 19:26 (CET)

 Steun —CodeCat 14 jan 2012 13:54 (CET)

Gedaan: Moedersjabloon geschikt gemaakt voor aparte afwikkeling twee invulmanieren ({{{1}}} en {{{lang}}}) en daarmee centrale omvorming van de taalcode naar taalnaam. Daarnaast een reroutering van parameters binnen contextlabels: in plaats van dat {{{1}}} wordt omgevormd in {{{lang}}}, worden beide invulmogelijkheden apart doorgestuurd naar het moedersjabloon. Beide invulmanieren werken nog. Romaine 5 feb 2012 02:59 (CET)

• Voor alsnog Sjabloon:toponiem overgeslagen wegens de afwijkende situatie en de beperkte mate waarin het sjabloon gebruikt wordt. Romaine 5 feb 2012 03:18 (CET)
• Indien er problemen mochten zijn (ik verwacht ze voor alsnog niet), laat me dit dan weten! Romaine 5 feb 2012 03:18 (CET)

Ziet er goed uit! Wat toponiem betreft: het is denk ik wat handiger dan specifiek stad,dorp,regio,(gebouw?) enz. bijvoorbeeld omdat wat vroeger een dorp was nu best een stad kan zijn. Verder: wat moet je anders aan met zoiets als Pentagon? Bekend genoeg, met een overdrachtelijke betekenis en zo. Maar een categorie "gebouw" lijkt me niet zo handig. Dan kunnen we dadelijk het hele telefoonboek met alle adressen er wel in gaan zetten. Jcwf 5 feb 2012 13:39 (CET)

Dat lijkt me een prima idee! Het Pentagon is een typisch militair iets, lijkt me minder een toponiem. Ik zal dorp, stad en regio overal wel om gaan zetten. Romaine 5 feb 2012 21:11 (CET)

Kunnen we Sjabloon:eiland, Sjabloon:provincie en Sjabloon:gemeente, wellicht ook Sjabloon:rivier, samenvoegen in het contextlabel toponiem? Romaine 6 feb 2012 03:29 (CET)

 Tegen de gedane wijzigingen door Romaine(Bot).  Tegen enige andere verdere wijziging door Romaine(Bot) waarbij er vooraf geen fatsoenlijk overleg met de gemeenschap heeft plaatsgevonden. -- Curious 6 feb 2012 16:40 (CET)

Waar heb je het over?????????????????????? Ik heb exact gedaan wat er is voorgesteld, daar was iedereen het mee eens en heb vervolgens stap voor stap beschreven wat ik gedaan heb om daartoe te komen. Dit vindt ik echt totale onzin... Romaine 6 feb 2012 16:53 (CET)

Gedaan: Alle contextlabel-sjablonen met aan taal-label hebben nu in plaats van de taal de taalcode overal ingevoegd gekregen. Om een of andere reden lijken er nog series van taal-invullingen uit het niets op te duiken af en toe die de software dan alsnog in de categorie plaatst. Romaine 6 feb 2012 04:37 (CET)

• Aanvulling: vergeten nog te vermelden dat ik aan een hele serie woordenboekingangen automatisch contextlabels voor toponiemen heb toegevoegd waar die ontbraken. Romaine 6 feb 2012 16:58 (CET)

Gedaan: Alle taallabels Sjabloon:auxl, Sjabloon:copl, Sjabloon:ditr, Sjabloon:erga, Sjabloon:inerg, Sjabloon:intr, Sjabloon:modl, Sjabloon:onpr, Sjabloon:ov, Sjabloon:rcpq, Sjabloon:refl zijn waar ingevoegd ook omgebouwd van taalnaam naar taalcode. Romaine 6 feb 2012 16:03 (CET)

• Ik denk dat het goed is als we mogelijk afspreken om zo veel mogelijk overal de 1e parameter te reserveren voor de taalcode, en de andere parameters meestal een naam te geven in plaats van slechts een numerieke positie. Of zijn er sjablonen die een taallabel benodigen waar dat problemen geeft? Romaine 6 feb 2012 16:03 (CET)
  • Ja, dingen als noun-form hebben meestal het hoofdwoord waar het onderhavige een vorm van is als eerste parameter. Jcwf 6 feb 2012 16:48‎ (CET)

Voorstel 3: taalspecifieke onderwerpcategorieën en taalspecifieke grammaticacategorieën

Voorstel: Sjabloon:ISOc toevoegen aan alle taalspecifieke categorieën waaronder de diverse onderwerpcategorieën en grammaticacategorieën.

Graag reactie! Romaine 13 jan 2012 14:11 (CET)

 Steun Annabel_(overleg) 13 jan 2012 17:10 (CET)

 Steun Jcwf 13 jan 2012 18:02 (CET) Hoewel dat niet mijn oorspronkelijke bedoeling was, zie ik er ook niet echt bezwaren tegen. Wel is het zo dat de links waarschijnlijk doorklikken naar de taalfamilie pagina zeld en niet naar een onderwerp of zo. Is niet echt een probleem denk ik.

Voorstel 4: taalpagina's

Voorstel: Sjabloon:ISOc toevoegen aan alle taalpagina's.

Graag reactie! Romaine 13 jan 2012 14:11 (CET)

 Steun Annabel_(overleg) 13 jan 2012 17:10 (CET)

 Steun Ook hier weet ik niet wat er bij doorklikken precies gebeurt, maar dat is denk ik niet zo'n probleem Jcwf 13 jan 2012 18:05 (CET)

 Steun —CodeCat 14 jan 2012 13:55 (CET)

 Steun Curious 14 jan 2012 20:17 (CET)

Aanvullende voorstellen

Als we nu dan toch bezig zijn... zou ik aanvullende voorstellen willen doen (voor voorstel 3 en 4). De mijne sluit die van Romaine niet uit, het zou desgewenst ook gecombineerd kunnen worden. -- Curious 13 jan 2012 20:09 (CET)

Voorstel 3b

Voorstel: Een sjabloon gebruiken voor alle categorieën in de vorm van "Categorie:Onderwerp in het Taalnaam" en "Categorie:Woordsoort in het Taalnaam", dus bijv. voor Categorie:Anatomie in het Nederlands en Categorie:Voorzetsel in het Nederlands. Wanneer we dit soort categorieën aanmaken, moeten we nu een hele lap tekst typen/kopiëren/aanpassen, bijv. voor de eerstgenoemde voorbeeldcategorie:

[[Categorie:Onderwerpen in het Nederlands]]

[[Categorie:Anatomie|Nederlands]]

[[Categorie:Medisch in het Nederlands]]

[[Categorie:Biologie in het Nederlands]]

Andere wiki's hebben dat een stuk handiger opgelost, die typen bijv.:

• {{categoria-tópico|Anatomia|nl}}, zie pt.wikt
• {{topic cat|nl|Anatomy}}, zie en.wikt

Bij ons zou dat bijv. kunnen worden: {{topic cat|Anatomie|nld}}. Het sjabloon zal dan vervolgens deze categorie automatisch in de juiste moedercategorieën plaatsen. De omzetting is eenmalig wat werk, maar ik denk dat het zeker de moeite waard is. Graag jullie mening. -- Curious 13 jan 2012 20:09 (CET)

 Steun met als aanvulling: een sjabloon voor de onderwerp-taal-categorieën: {{Onderwerpen naar taal}}, een sjabloon voor de woordsoort-taal-categorieën: {{Woordsoorten naar taal}} en een sjabloon voor woorden naar taal categorieën: {{Woorden naar taal}}. Opzet: {{Naam sjabloon|onderwerp|taalcode}} Een dergelijk sjabloon zorgt er voor dat er altijd de juiste categorieën op een categorie te vinden zijn. Dit kan mijn bot prima doen denk ik. Romaine 13 jan 2012 21:00 (CET)

Akkoord. (Valt er nog te onderhandelen over kortere sjabloonnamen? ;) ) -- Curious 13 jan 2012 22:59 (CET)

 Steun maar ik zou dan wel willen voorstellen om voorlopig alleen de oudercategorieën in het systeem op te nemen en niet meer. Het Engelse systeem is bijvoorbeeld verschrikkelijk ingewikkeld in elkaar gezet en we kunnen het hier best wat simpeler gebruiken. Overigens zou ik zelf liever de taalcode als eerste parameter hebben maar dat is een klein detail. —CodeCat 14 jan 2012 14:01 (CET)

Waarom eerst de taalcode? Standaard hebben alle categorieën een opzet van Onderwerp in Taal, het lijkt mij dan logisch die volgorde aan te houden. Romaine 14 jan 2012 18:36 (CET)

Aanvulling: (Gespiekt van pt.wikt...) Ik heb sjabloon {{test-sjab}} aangemaakt om uit te proberen. Groente, fruit, voeding, medisch en wetenschap zou nu moeten werken. test1, test2. Wat vinden jullie ervan? -- Curious 14 jan 2012 19:47 (CET) Doorgestreept, Romaines sjabloon hieronder lijkt me beter. Curious 15 jan 2012 12:55 (CET)

Dat is erg omslachtig en kan veel simpeler. Slechts voor enkele afwijkende categorieën is er een switch nodig. Romaine 15 jan 2012 00:01 (CET)

Een switch is bovendien erg slecht schaalbaar omdat het steeds langzamer wordt naarmate er meer categorieën zijn. Misschien kun je sub-sjablonen gebruiken, zoals de Engelse Wiktionary ook doet? —CodeCat 15 jan 2012 01:30 (CET)

Aangemaakt: Sjabloon:Onderwerpen naar taal, eerst nog even testen. In het sjabloon zijn Sjabloon:ISOc en Sjabloon:beschrijf opgenomen, zodat dezelfde gegevens maar 1x hoeven worden opgegeven. - Romaine 15 jan 2012 02:36 (CET)

Eigenlijk zie ik hier 't nut niet van in.. We hebben toch sjablonen als template:luchtvaart? Het zou veel makkelijker zijn als we in deze sjabloon gewoon het stukje tekst [[Category:Luchtvaart in het {{{1}}}}]] zouden plaatsen.... --Ooswesthoesbes 15 jan 2012 09:50 (CET)

@OWTB: met sjabloon {{luchtvaart}} kun je pagina's categoriseren, bijv. vliegveld, helikopter. Met dit nieuwe sjabloon willen we categorieën categoriseren, bijv. Categorie:Luchtvaart in het Nederlands, Categorie:Luchtvaart in het Engels. Het bespaart het typwerk van de hele riedel die nu op "Categorie:<Onderwerp> in het <Taal>" staat... -- Curious 15 jan 2012 13:06 (CET)

test1, test2 Is volgens mij in orde. :)

Ik vraag me wel af of het nodig is om op elke categoriepagina sjabloon {{ISOc}} te zetten. Mag van mij weggelaten worden. Of als het al gewenst is, dan misschien liever sjabloon ISO (voorbeeld). Sjabloon ISOc vraagt ook om een tweelettercode, en het niet invullen daarvan suggereert dat er geen tweelettercode bestaat. Daarnaast linkt sjabloon ISO direct naar het woordbestand. -- Curious 15 jan 2012 13:39 (CET)

Zie #Voorstel 3: taalspecifieke onderwerpcategorieën en taalspecifieke grammaticacategorieën -> Daar wordt ISOc voorgesteld toe te voegen. Het hoeft voor mij niet ISOc te zijn, maar wel de duiding tot welke ISO 639-3 code deze categorie verwijst. Dan is sjabloon:ISO prima: ik heb ISOc eruit gehaald en vervangen door het sjabloon met de variant zonder ISO 639-1. Romaine 15 jan 2012 14:17 (CET)

Start: ik hoop dat ik niet te voorbarig ben, maar ik wil zometeen mijn bot starten om met deze klus te starten. Er lijkt me voldoende voor te zijn. Romaine 15 jan 2012 14:19 (CET)

Sjabloon:tegen De bedoeling was om het aanmaken van onderwerpscats eenvoudiger te maken, niet om het aantal onderwerpen drastisch in te perken en dat is wat je sjabloon doet, Romaine. Stout, heel stout.... Verder bevat {{ISO}} een verwijzing naar de categorie Zelfstandig naamwoord in het Nederlands die dus nu ook op Fruit in het Russisch te vinden is. Er is ook een reden waarom die verwijzing erin staat. Taalnamen hebben geen meervoud of verkleinwoord en om telkens -nlnoun- te gebruiken alleen maar om het lemma in de categorie Zelfstandig naamwoord in het Nederlands te plaatsen was wat moeizaam. Nu die cat ook met {{-noun-|nld}} geschreven kan worden is dat niet meer nodig, maar als je de verwijzing uit {{ISO}} sloopt verdwijnen er wel een hoop lemma's uit categorie Zelfstandig naamwoord in het Nederlands. Jcwf 15 jan 2012 14:59 (CET)

"het aantal onderwerpen drastisch in te perken" -> wat bedoel je?

{{ISO}} heb ik er nu uitgehaald en heb nu de ISO-tabelcode rechtstreeks ingevoegd. Als later Sjabloon:ISO aangepast is kan het eventueel vervangen worden. Romaine 15 jan 2012 15:17 (CET)

Eerlijk gezegd vind ik het behoorlijk voorbarig om de bot te starten. :( Het voorstel met het concrete sjabloon staat hier nog niet eens 24 uur. Een deel van de reguliere gebruikers heeft zelfs nog geen kennis kunnen nemen van dit sjabloon. Wat mij betreft zitten we nog steeds in de brainstormfase (Is het echt een goed idee? Zijn er misschien technische bezwaren? Valt er misschien nog iets te verbeteren aan het plan? Is een totaal andere aanpak misschien beter? etc.) Misschien is het bij Wikipedia anders, maar hier is het vrij normaal dat er bij dit soort voorstellen toch minimaal een week (soms veeeeeeel langer) gelegenheid is voor iedereen om te kunnen reageren, om bezwaren te uiten, om andere voorstellen te doen, om verbeteringen aan te dragen, whatever. Waarom zo'n haast? Alsjeblieft, laat het plan rustig rijpen... -- Curious 15 jan 2012 15:43 (CET)

Sorry, dat heet enthousiasme en zin om iets te doen, en ik weet niet of ik die zin volgende week nog heb, die begint nu al af te nemen. En de meeste actieve gebruikers hadden reeds een reactie gegeven en gezien eerdere voorstellen verwacht ik niet veel meer reacties, (geen idee wat dat rijpen verder inhoudt, met eerdere voorstellen niets van gemerkt, na een eerste reacties volgen vaak weinig nieuwe reacties). Het de uitwerking van dit idee heeft in mijn hoofd al 2 jaar gerijpt hoe dit technisch gezien het meest efficiënt kon. Verder had ik w:en:Wikipedia:Be bold en w:Wikipedia:Voel je vrij en ga je gang in gedachten. Dat zijn uitgangspunten die ik prettig vind omdat ik daarmee enthousiasme direct (of na korte tijd) kan omzetten in resultaat, iets wat na een week al niet meer gaat. Met de reactie van Jcwf had ik de gedachte te starten wederom in de ijskast gezet, omdat er blijkbaar nog steeds onduidelijkheden zijn. Zucht... Romaine 15 jan 2012 16:01 (CET)

Voorstel 4b

Voorstel: Een sjabloon gebruiken voor alle taalpagina's. We typen toch elke keer hetzelfde, dat zou je ook in een sjabloon kunnen zetten. Dus bijv. i.p.v.:

* [[w:nl:Duits|Wikipedia-artikel over het Duits]]
* [[Duits]]
* [[:Categorie:Woorden in het Duits|Woordenlijst]]
<noinclude>[[Categorie:WikiWoordenboek:Taalpagina|Duits]]</noinclude>

typen we nu: {sjabloonnaam|deu}. Sjabloon ISOc kan er natuurlijk ook gewoon bij. -- Curious 13 jan 2012 20:19 (CET)

Een andere of aanvullende optie is om de taalpagina's af te schaffen en de inhoud ervan over te hevelen naar de Categorie:Woorden in het <taal>. Voor mij is het al jaren verwarrend/onhandig dat we apart een woordenlijst en apart een taalpagina hebben. Ik denk dat we beter overal rechtstreeks kunnen linken naar de Categorie:Woorden in het <taal> waar bovenaan de informatie staat die nu apart op een taalpagina staat. Dat zou mijn inziens de navigatie verbeteren. Romaine 13 jan 2012 20:26 (CET)

Mag van mij ook... (tenzij er een of andere technische reden is om het niet te doen, al kan ik niks verzinnen..) -- Curious 13 jan 2012 20:50 (CET)

 Steun —CodeCat 14 jan 2012 14:01 (CET)

Taalsjablonen

Bij het nalopen van de taalsjablonen en het bijwerken van de ISO 639-tabellen kwam ik 6 taalcodes tegen die niet geduid kunnen worden bij SIL/ISO en artikelen hebben waarop deze taalsjablonen toegevoegd zijn. Het gaat om:

• Berbers: {{ber}} / {{=ber=}}: het Berbers is geen zelfstandige taal maar een verzameling van talen, aldus ISO/SIL.
• Maya: {{myn}} / {{=myn=}}: [1] identiek.
• Sami: {{smi}} / {{=smi=}}: [2] identiek. Op de categorie staat nota bene "Van deze woorden is niet duidelijk tot welke taal zij precies behoren omdat "smi" een taalcollectief betekent." Dat lijkt me echt geen goede situatie.
• Germaans: {{gem}} / {{=gem=}}: [3] identiek.
• West-Germaans: {{gmw}}: [4] identiek.
• Indo-Europees: {{ine}}: [5] identiek.
• Romansh: {{rsh}}: [6] identiek.

Het gaat hier 7 keer niet om een taal maar om een collectief van talen. Ik denk dat het nodig is dat een woordenboekingang echt aan een specifieke taal kan worden toegeschreven en niet enkel aan een collectief. Alle taalcodes zijn ISO 639-3-codes en indentificeren elk een individuele taal. De 7 codes zijn geen ISO 639-3-code. Ik denk dat er twee mogelijkheden zijn: ofwel deze taalcode hernoemen naar een die niet drieletterig is om geen ISO 639-3 te suggereren. Ofwel het toewijzen van de betreffende artikelen aan een specifieke taal uit dit taalcollectief de sjablonen verwijderen. Mijn inziens is een andere naam minstens noodzaak.

• Andere sjablonen die geen ISO 639-3-taalcode hebben, maar wel als zodanig gebruikt worden zijn: Sjabloon:alp-nc, Sjabloon:art-sl, Sjabloon:zh-sc en Sjabloon:zh-tc.

Voorstel: de betreffende sjablonen laten voorafgaan door een X (of andere letter) zodat het een vierletterige code wordt en duidelijk is dat er iets mee aan de hand is. Op die manier blijft het spectrum van drielettersjablonen zuiver. Eventueel de vier andere sjablonen ook een X meegeven. Romaine 14 jan 2012 01:28 (CET)

PS: Met Categorie:Woorden in het Boerjatisch is ook iets mis met de taalsjablonen (bua). Romaine 14 jan 2012 01:38 (CET)

gem, gmw en ine zijn (geldige!!!) 639-5 codes voor taalfamilies. Ik heb voor -5 codes zoiets als {{ine:}} met een dubbele punt in het leven geroepen. De andere zijn macrotalen en dat is een hele lastige zaak omdat ISO nogal de neiging heeft om aan allerlei dialecten voor de zekerheid toch maar een code toe te kennen. Van sommige van deze entiteiten hebben we enig materiaal waarvan we niet weten tot welke variëteit het behoort en ontbreekt het ons (vooralsnog) aan de kennis om dat op te lossen. Tot dusver hebben we dat gewoon laten staan in de hoop dat er nog eens iemand langs komt die daar meer van weet. Ik zie eerlijk gezegd niet wat daar mis aan is. Jcwf 14 jan 2012 01:40 (CET)

ISO 639-2 en ISO 639-5 zijn nog geen ISO 639-3. Op dit moment wordt door het aanhouden van Sjabloon:gem de indruk gewekt dat dit een ISO 639-3 sjabloon is, terwijl dat niet het geval is. Om dat duidelijker te maken wil ik dus een X aan de sjabloonnaam toevoegen, dan blijft het sjabloon en alles gewoon bestaan, maar is wel duidelijk dat ISO 639-3 (waarop alle andere taalsjablonen gebaseerd zijn) geen gem, ber, ine, etc kent. Romaine 14 jan 2012 01:56 (CET)

Op de Engelse Wiktionary wordt voor gereconstrueerde talen een code gebruikt die afgeleid is van de taalfamilie en die eindigt met -pro, bijvoorbeeld gem-pro en ine-pro (voor Proto-Germaans en Proto-Indo-Europees). Dit lijkt mij hier ook wel handig? —CodeCat 14 jan 2012 14:04 (CET)

Dat laatste is voor lemma's met gereconstrueerde vormen misschien zo gek nog niet, hoewel de naamgeving wel verwarrend is. Het prefix proto wordt namelijk op verschillende manieren gebruikt. Soms bedoelt men ermee de vroege stadia van het Indo-Europees of de taal waar het uit ontstaan is. Dan weer bedoelt men er de gereconstrueerde taal (talen?: er zijn meerdere reconstructies) mee om deze te onderscheiden van hoe de historische taal werkelijk geweest moge zijn. Beetje gemiereneuk dat laatste eigenlijk want zodra je *dit schrijft is het toch duidelijk dat iets gereconstrueerd is.

Er is denk ik wel behoefte aan twee verschillende sjablonen: een voor de taalfamilies (en dat is er al, zie {{ine:}}, {{afa:}} enz, een ander voor gereconstrueerde vormen. Waarom niet *ine, *afa en als kopnaam *Indo-Europees? En dan consequent de ster gebruiken voor alles was gereconstrueerd is.

Strict gesproken gelden de -5 codes overigens voor taalfamilies en niet voor reconstructies en verder zijn ze hopeloos incompleet en vrij willekeurig gecreëerd. Er is bijvoorbeeld een code voor Prakrits maar of de Nieuwindische talen daar nu weer een subgroep van zijn is niet duidelijk. Ik heb er dat maar wel van gemaakt. Jcwf 14 jan 2012 18:04 (CET)

In de taalkunde is een proto-taal meestal een gemeenschappelijke voorouder. Het Proto-Germaans is de gemeenschappelijke voorouder van de Germaanse talen, het Proto-Noords die van de Noordse talen (oftewel Proto-Noord-Germaans) en het Proto-Romaans die van de Romaanse talen (vreemd genoeg is dit niet hetzelfde als Volkslatijn). Voor de vroegere stadia wordt meestal het prefix pre- gebruikt, zoals Pre-(Proto-)Indo-Europees of in het Engels 'Pre-Old English'. —CodeCat 14 jan 2012 18:17 (CET)

Woordsoortsjablonen voor telwoordsubcategorieën

Hallo,
mir ist aufgefallen, dass die woordsoortsjablonen voor telwoordsubcategorieën bisher nicht vollständig existieren. Beispiel: Onbepaalde hoofdtelwoorden wird angesteuert über -num-|indef=1. Eigentlich ist die sjabloon -num- für hoofdtelwoorden kreiert.
Verwendet man bei -num-|indef=1 das Länderkürzel, zum Beispiel 'deu' (-num-|deu|indef=1), dann wird das Wort der Categorie:Hoofdtelwoorden in het Duits zugeordnet, obwohl es zu der Categorie:Onbepaald hoofdtelwoord in het Duits gehört. Diese Zuordnung kann man nur mit einer zusätzlichen Kategorieanweisung im Artikel erreichen (siehe: zigtausend).
Für einige telwoordsubcategorieën existieren noch keine woordsoortsjablonen, außer -num-distr- (verdelingsgetal) und -num-int- (vragend telwoord). Rangteelwoorden sind nicht über -num-, sondern mit einer gesonderten Schablone (-ordn-) geregelt.
Vielleicht kann sich jemand mit besseren Programmierkenntnissen als ich um dieses Thema kümmern. -- Cadfaell 14 jan 2012 12:38 (CET)

Het lijkt me het makkelijkst om een nieuw sjabloon aan te maken, bijv. {-num-indef-}, zodat {-num-indef-|deu} is te gebruiken. -- Curious 16 jan 2012 20:51 (CET)

Ja, bei vorig (Onbepaald rangtelwoord) gibt es ebenfalls keine woordsoortsjabloon, so dass die woordsoort-Überschrift mit
====''[[WikiWoordenboek:Rangtelwoord|Onbepaald rangtelwoord]]''==== gebildet wurde. Da fehlt auch noch eine Schablone. -- Cadfaell 16 jan 2012 21:11 (CET)

Ik heb sjabloon {{-num-indef-}} en {{-ordn-indef-}} gemaakt, waar je ook de taalcode aan toe kunt voegen, zie zigtausend en vorig. Als men i.p.v. deze 2 nieuwe sjablonen toch liever sjabloon {{-num-}} & {{-ordn-}} zou willen aanpassen kan dat natuurlijk ook, maar ik dacht dat het misschien beter te verwerken zou zijn voor bots, als we niet al te veel parameters meer hangen aan de woordsoortsjablonen, zodat bots zo nodig makkelijk taalcodes kunnen toevoegen. -- Curious 21 jan 2012 22:18 (CET)

Geen sjablonen gebruiken op een kop toe te voegen

We gebruiken nu sjablonen die zelf een kop aan het artikel toevoegen, zoals {{=nld=}} of {{-noun-}}. Het nadeel van dergelijke sjablonen is dat als je op 'bewerken' klikt voor die sectie, je naar de bewerkingspagina van het sjabloon wordt gestuurd in plaats van die van de pagina. Dat vind ik zelf erg vervelend werken, en dat is ook niet intuitief voor gebruikers die andere wiki's gewend zijn. Daarom zou ik willen voorstellen om {{=nld=}} steeds te vervangen door =={{=nld=}}== en de kop uit het sjabloon te verwijderen. Hetzelfde zou dan ook gebeuren voor alle andere sjablonen die koppen toevoegen. —CodeCat 14 jan 2012 14:08 (CET)

..als je op 'bewerken' klikt voor die sectie... Tja die knop hoort er dus helemaal niet zijn! We hebben namelijk overal NOEDITSECTION in staan om dat te onderdrukken en dat heeft tijdenlang uitstekend gewerkt. Om een of andere duistere reden werkt dat nu ineens niet meer... Dit is een oeroeroeroude discussie trouwens en ja we kunnen het Franse voorbeeld wel volgen maar het is wel een gigantische operatie en daarmee een zware belasting van het systeem. Eerlijk gezegd heb ik liever al die sectieknoppen niet, ze zijn niet echt nodig, ze leiden tot inconsistenties op de pagina omdat een verandering in de ene sectie vaak een verandering in een latere nodig maakt en verder maakt het de pagina er onnodig onrustig uitzien. Jcwf 14 jan 2012 17:43 (CET)

Eh... ik zie geen sectie-editknopjes meer... -- Curious 14 jan 2012 20:12 (CET)

Hebben we al een sjabloon voor het geluid van een brekende klomp? Jcwf 14 jan 2012 21:38 (CET)

Announcing Wikipedia 1.19 beta

Wikimedia Foundation is getting ready to push out 1.19 to all the WMF-hosted wikis. As we finish wrapping up our code review, you can test the new version right now on beta.wmflabs.org. For more information, please read the release notes or the start of the final announcement.

The following are the areas that you will probably be most interested in:

• Faster loading of javascript files makes dependency tracking more important.
• New common*.css files usable by skins instead of having to copy piles of generic styles from MonoBook or Vector's css.
• The default user signature now contains a talk link in addition to the user link.
• Searching blocked usernames in block log is now clearer.
• Better timezone recognition in user preferences.
• Improved diff readability for colorblind people.
• The interwiki links table can now be accessed also when the interwiki cache is used (used in the API and the Interwiki extension).
• More gender support (for instance in logs and user lists).
• Language converter improved, e.g. it now works depending on the page content language.
• Time and number-formatting magic words also now depend on the page content language.
• Bidirectional support further improved after 1.18.

Report any problems on the labs beta wiki and we'll work to address them before they software is released to the production wikis.

Note that this cluster does have SUL but it is not integrated with SUL in production, so you'll need to create another account. You should avoid using the same password as you use here. — Global message delivery 15 jan 2012 17:25 (CET)

Aanmelden

Ik ben eigenlijk een gebruiker van Wikipedia, maar zo te zien kun je hier ook inloggen! Da's handig! Ik heb hier al mijn gebruikerspagina gemaakt. W.G.J. heeft dit kopje aangemaakt.

Ik kijk of dat de bedoeling is. Of wil een van de andere gebruikers hier op reageren of andwoorden? ik zelf weet namelijk niet of dat de bedoeling is...

Zeker! Je bent van harte welkom! Jcwf 16 jan 2012 21:08 (CET)

Verontrustend nieuws

Ook hier in de VS is wikimedia niet veilig en Woensdag is de Engelse Wikipedia van plan alles te verduisteren. Het lijkt me zinnig te bepalen wat nl.wiktionary daarmee aanmoet <gebruiker: Jcwf>

Een berichtje bovenaan de pagina's, zoals destijds bij het Italiaans protest, lijkt me zinvol. Hoe meer mensen op de hoogte komen van deze belachelijke wetgeving, hoe beter. Jammer dat Jimmy Wales niet alle Wikiprojecten platgooit... -- Curious 16 jan 2012 21:46 (CET)

Ik heb op w:en:Wikipedia:SOPA_initiative/Action ook mijn mening geuit en gestemd (beetje vreemd dat het op enwiki is ipv meta, maar soit). Annabel_(overleg) 17 jan 2012 06:55 (CET)

Oeps 't is al beslist. Annabel_(overleg) 17 jan 2012 06:59 (CET)

Op nl-wiki ben ik bezig geweest met het maken van een landingspagina: w:Wikipedia:SOPA. Anderen hebben een banner gemaakt. Dat kunnen we ook op WikiWoordenboek doen! Romaine 18 jan 2012 02:10 (CET)

Limburgse projecten hebben al beslist niets te gaan doen, omdat het ons toch niet treft. Nl-wp en nl-wikt heeft natuurlijk een andere situatie. --Ooswesthoesbes 18 jan 2012 10:23 (CET)

Dat het ons niet zou treffen is niet waar. Allereerst, als Amerikaanse websites op zwart moeten: de servers staan op Amerikaanse bodem die wij dan ook niet kunnen bereiken. Verder is een deel van de informatie in Europa van Amerikaanse oorsprong. Tevens is er in Engeland door de VS een uitleververzoek ingediend tegen een Engelse jongeman die nog nooit in de VS is geweest, maar enkel links naar bepaalde bestanden op zijn website had staan. Daarnaast wordt er ook in Europa en andere landen in de wereld gesproken en nagedacht over het inbeperken van internetvrijheden. Het op zwart gaan/banner tonen is een signaal van bezorgdheid omdat het direct onze projecten schaadt, onder meer op het vlak van neutraliteit. Romaine 18 jan 2012 17:45 (CET)

Goed werk, Romaine. :) -- Curious 18 jan 2012 21:48 (CET)

Sjabloon {nodef}

Soms kom ik een pagina tegen waarop al tekst staat voor een buitenlandse taal, maar nog niet voor het Nederlandse woord, zie bijv. expertise. Ik zet daar wel eens een {nodef}-sjabloon op. Is dit wenselijk (om dit soort pagina's zonder Nederlands woord te kunnen opsporen), of is dit alleen maar irritant? (Idealiter zou ik het Nederlandse lemma natuurlijk zelf moeten aanmaken, maar ja... ik ben niet zo heel goed in het verzinnen van woorddefinities... :S ) -- Curious 18 jan 2012 23:20 (CET)

Van mij mag je, lijkt me niet onredelijk. Desnoods vul ik op die plekken de Nederlandstalige versie wel in. Romaine 19 jan 2012 02:20 (CET)

Te ontdekken via: Categorie:WikiWoordenboek:Ontbrekende_definitie. Annabel_(overleg) 19 jan 2012 07:15 (CET)

De sjabloon is goed. Men kan niet altijd alle woorden zelf aanmaken. Met de sjabloon is er een vlag. -- Cadfaell 19 jan 2012 07:25 (CET)

Zeker, ik doe dat ook geregeld. Anders vergeten we die woorden. Op li.wikt gebruik ik daar ook een sjabloon voor. --Ooswesthoesbes 19 jan 2012 09:34 (CET)

Ok, duidelijk. :) Curious 19 jan 2012 22:00 (CET)

Update uitbreidingen

Dag allen

Ik zag iets in de documentatie van mediawiki waardoor laden van uitbreidingen een stuk sneller verloopt, oftewel mediawiki werkt sneller. Enfin, ik heb de uitbreidingen voor woordenboek.org, transtool en de interwikicontrole dus geupdated. Je ziet nu geen knopjes meer bovenaan in de linkerbalk. Deze zijn vervangen door blauwe links analoog aan de andere in de linkerbalk en zijn terug te vinden onder "hulpmiddelen" waar ze thuishoren. Bovendien is er nu een sneltoetscombinatie mogelijk:

• alt + shift + v: opent transtool (de v van vertalingen)
• alt + shift + o: open de gelijknamige ingang op woordenlijst.org (de o van woordenlijst.org
• alt + shift + i: open de interwikicontrolepagina (de i van jawel interwiki)

Annabel_(overleg) 22 jan 2012 12:19 (CET)

PS: indien je de links al dan niet wil uitschakelen, dit kan op Speciaal:Voorkeuren in het tabblad "Uitbreidingen"

Ziet er weer goed uit. Bedankt. :) Curious 22 jan 2012 22:53 (CET)

150.000

Weer een mijlpaal. Yay! Dankjewel Difool(bot)! Jcwf 22 jan 2012 15:33 (CET)

Gefeliciteerd mensen! :) --Ooswesthoesbes 22 jan 2012 18:13 (CET)

Applaus! Kijk ook eens in de achteruitkijkspiegel, we hebben sv.wikt ingehaald en plaats nr. 19 ingenomen. [7] Curious 22 jan 2012 22:47 (CET)

Joepie! Op naar de 200.000! Difool 24 jan 2012 00:53 (CET)

Was hij maar ..., kwamen ze maar!

Dit soort zinnen ingeluid door een verleden tijd zijn toch vrij algemeen in het Nederlands en ik vraag we af wat er mee aan moeten. Ik denk dat het grammaticaal een gebiedende wijs verleden tijd is. Historisch zal het wel de functie van een aanvoegende wijs verleden tijd "Ware hij maar; gave hij maar" overgenomen hebben. Het is meestal 3e persoon enkel- of soms meervoud, maar 2e en zelfs 1e is mogelijk: "Reden we maar wat harder!", "Kwam je maar op tijd!". Had ik hier maar een oplossing voor! Gaven jullie maar een mening over de vraag of dit ook in de lemma's reden, kwam en gaven opgenomen dient te worden... Jcwf 23 jan 2012 18:15 (CET)

De ANS houdt zich aardig op de vlakte en noemt het gewoon een verleden tijd... Jcwf 23 jan 2012 19:43 (CET)

Interessant. Als gewone piwi die geen talen gestudeerd heeft, maar bovenal van taal houdt, heb ik er geen verstand van en vind ik het een bijzonder interessante vraag. Zowieso wel moeilijk te vermelden in het woordenboek. Is niet iets voor aparte woordenboekingangen, maar voor een algemeen beschrijvende pagina ... Annabel_(overleg) 23 jan 2012 20:29 (CET)

De meervoudsvormen «gaven» zijn sowieso al aanvoegende wijs, maar «kwam» niet, dat is «kwame». Bij «gaven» dus vermelden en bij «gaf» niet. --Ooswesthoesbes 24 jan 2012 11:10 (CET)

Verouderde vorm / ontbrekende sjablonen

Tijdens de botrun van vandaag in Categorie:Werkwoordsvorm kwam ik een serie pagina's tegen waar geen sjablonen gebruiken, waarvan ik denk dat die daar juist wel gebruikt horen te worden. Alsmede worden er regelmatig categorieën handmatig ingevoegd, wat mijn inziens veel beter via de (ontbrekende) sjablonen kan gebeuren. Ook komen er links naar WikiWoordenboek-pagina's voor die beter via sjablonen kunnen lopen. De lijst die ik tegenkwam is: будем, будет, будете, будешь, буду, is, faller, fått, går, meint, meinte, mener, ment, mente, sa, sagt, sang, ser, sett, skal, skriver, sov, såg, tapa, tapet, var, vet, vil, villet, åker, åkt, åkte, åtvar, åtvara, maqan, maqani, maqanki, munan, munani, munanki, riman, rimani, rimanki, tusun, tusuni, tusunki, zijt, zul, bakt, bakte, alfabetizo, dove, lever, was, wees, weest, lekte, lekt, were, wilt, zakkenvullend, docht, dele, ment, mistte, vis, vil, koomt in, kun, kunt, kam, mag, ment, mis, scratchend, spottend, beliefde, ben, benieuwde, benieuwt, bent, torn, gescratcht, hebbend, betaamde, begaan, inkoomt, is, herstellend, kan, gjekk, gått, har, bad, bar, betala, blotta, braut, er, fekk, flaut, fraus, får, føydd, føydde, gav, has, kokar, kom, lek, leker, had, stirring, accedo, est - Wie wil dit oppakken? - Romaine 30 jan 2012 00:31 (CET)

Er zullen altijd onregelmatige vormen in alle talen van de wereld blijven, Romaine. Een vorm als буду is daar een voorbeeld van. Het is orspronkelijk een vorm "zijn" die een rol speelt in de vorming van de toekomende tijd. En nee andere Russische werkwoorden hebben zo'n vorm niet. Het is een ondoenlijke en onpraktische zaak om zo iets te willen vangen in een sjabloon omdat zoiets juist de regelmaat van een taal weerspiegelt. Handmatige invoer moet daarom m.i. niet verboden worden. Als er oudere bijdragen zijn die gemakkelijk in sjablonen gevangen kunnen worden is het natuurlijk zinnig om ze te herschrijven maar er zullen er altijd overblijven waar dat niet zo is. In het Nederlands is zoiets als "kun" een goed voorbeeld. Het is alleen 2e persoon en dan in inversie. Volstrekt uniek. Jcwf 30 jan 2012 02:53 (CET)

Oke, dank voor de uitleg! Romaine 30 jan 2012 03:25 (CET)

Ook bij de bijvoeglijke naamwoordsvormen kwam ik wat afwijkenden tegen: blonde, blondest, blåe, enige, minst, opi, småe, sterke, illegale, lokalere, lokale. Als iemand ooit een sjabloon weer toe te voegen zou dat handiger zijn, anders laten we het zo. Romaine 30 jan 2012 04:06 (CET)

Mijn bot past een aantal van deze vormen aan (zoals polysemen en beken). Zouden de vormen zoals bij dieren en schoppen ook vervangen moeten worden? Difool 3 feb 2012 22:39 (CET)

interwiki's

Er gaat iets helemaal mis met de interwiki's! Jcwf 1 feb 2012 01:12 (CET)

Er wordt aan gewerkt zie Jcwf 1 feb 2012 01:31 (CET)

Er is momenteel een technische storing gaande op diverse projecten met interwiki's, problemen zijn breeduit gemeld bij de technici. (De interwiki's worden als rode links onderaan een pagina getoond in plaats van in de sidebar.) Aan het probleem wordt gewerkt en zal vast snel verholpen zijn. Romaine 1 feb 2012 01:34 (CET)

gewraakte trappen

Op de WikiWoordenboekpagina van het woord "gewraakt" zijn de vergrotende en overtreffende trap gegeven van het bijvoeglijk naamwoord "gewraakt(e)", dat afgeleid is van het voltooid deelwoord "gewraakt". Uiteraard kunnen deze trappen taalkundig geconstrueerd worden, maar semantisch is het onzin. Iets of iemand kan net zo min gewraakter als afgekeurder of geliefkoosder zijn. De vergrotende en overtreffende trap bestaan derhalve niet. Ik ben toevallig op deze fout gestuit en ik verwacht dat deze ook wel op andere WikiWoordenboekpagina's is gemaakt. Ik heb geen ervaring met het bewerken van pagina's en durf dat nog niet aan. Wil een meer ervaren Wikibewerker de gewraakte trappen van vergelijking van de pagina wijderen?

Uitgevoerd -- Curious 1 feb 2012 22:43 (CET)

Voorstel 5: samenvoegen tot één contextlabel toponiem

Er zijn momenteel verschillende contextlabels in gebruik voor toponiemen, bijvoorbeeld voor provincies. Provincies komen in tal van landen voor, naast gemeenten, regio's, mesoregio's, microregio's, gewesten, gouvernementen, kantons, prefecturen, parishes, arrondissementen, counties, deelstaten, departementen, districten, divisies, gemeenten, oblasten, bezirken, stadsbezirken, comarca's, deelgemeenten, bestuurlijke regio's, woiwodschappen, powiats, en nog andere bestuurlijke gebieden. Het lijkt me geen goed idee om voor iedere variant een eigen contextlabel te maken, alsmede lijkt het mij geen goed idee voor slechts een willekeurige variant een contextlabel te hebben. Tevens zijn vele van deze vormen al enige tijd via het contextlabel toponiem gelabeld en gecategoriseerd. Omdat er gigantisch veel toponiemen in de wereld zijn en het een overdosis is om alle toponiemen van de wereld per taal in één categorie te plaatsen, hebben we reeds enige tijd een onderverdeling per werelddeel en verdere onderverdeling per land, ieder naar taal. Mij lijkt het goed om alle plaatsen, bestuurlijke eenheden en andere toponiemen in die categorieboom te situeren. Echter bestaan er momenteel aparte contextlabels en categorieën voor eilanden, provincies, gemeenten, rivieren, en al deze toponiemen staan dus echter niet in de categorieboom van de toponiemen. Het voorstel concreet om de categorieën en contextlabels voor eilanden, provincies, gemeenten, rivieren (heb ik er nog gemist?) samen te voegen in Sjabloon:contextlabel met bijbehorende categorieboom. (Dit is reeds wellicht wat te snel al gebeurd voor stad, regio en dorp, zie voorstel 2.) Ik ben in ieder geval verre van gelukkig met de huidige situatie en vreemde opdeling zoals die nu is met de verschillende contextlabels voor toponiemen. De situatie dient mijn inziens te zijn dat voor specifiek aan continenten en/of landen toe te wijzen geografische onderwerpen {{toponiem}} wordt gebruikt gespecificeerd per land/werelddeel en voor alle andere aardrijkskundige onderwerpen {{aardrijkskunde}} wordt gebruikt. Een vraag die daarbij open staat is of ook woordenboekingangen over landen en werelddelen in deze categorieboom thuishoren of een zelfstandige categorie dienen te behouden? Graag reactie! Romaine 7 feb 2012 20:20 (CET)

Ik zou het jammer vinden als alle aardrijkskundige namen in één toponiem-vergaarbak zouden komen. Labels als regio, rivier, stad, land zijn veel informatiever dan het vrij nietszeggende label toponiem. Ik heb er niet zo'n moeite mee als de hierboven (in de 2e zin) genoemde varianten voor regio's elk een eigen contextlabel zouden hebben. Ook als het wat ingeperkt wordt tot bijv. alleen (ik zeg maar wat) provincie, regio, zou ik dat nog altijd nuttiger vinden dan alleen "toponiem", waarbij je geen flauw benul hebt waar het om gaat.

Via sjabloon:toponiem ontstaan er nu een hele hoop categorieën in de vorm van "Categorie:Aardrijkskunde van <land> in het <taal>". Ik schat zo in dat de meeste van deze categorieën voorlopig alleen één of twee pagina's zullen bevatten (waarschijnlijk vooral het land en/of de hoofdstad ervan). Ik neem een willekeurige categorie eigennamen, Categorie:Eigennaam in het Deens: er zijn nu 83 pagina's, en mogelijk ontstaan er bijna evenveel categorieën in de vorm van "Categorie:Aardrijkskunde van <land> in het Deens>". Ik vraag me af of dit (op dit moment) nuttig is. (Op de lange termijn, als we weer een aantal jaren verder zijn, en er heel wat meer aardrijkskundige namen zijn toegevoegd, wordt het waarschijnlijk wel weer nuttig om deze categorieën aan te maken.) -- Curious 7 feb 2012 23:03 (CET)

Rivieren, zeeën, bergen enz zou ik ook niet wegdoen. Het gaat mij meer om dingen die door ons mensen in het leven geroepen zijn zoals gemeentes, dorpen, provincies enz. Die veranderen namelijk nogal met de politiek en de geschiedenis. Is Nederlands-Indië een land bijvoorbeeld? Is het wel geweest, maar ja... Het probleem daarbij is dat we ook >4000 jaar taalgeschiedenis meenemen. Toponiemen in het Oud-Nederlands kunnen best op gehuchten slaan of een enkele boerderij en hun equivalent in 2012 is misschien een grote stad of bestaat helemaal niet meer. Jcwf 8 feb 2012 06:22 (CET)

Bedoel je met het voorbeeld met Nederlands-Indië dat ook sjabloon:land ongewenst is? Ja, landen veranderen soms van naam, er komen soms andere grenzen, sommige gebieden worden betwist als land etc., maar goed, ondanks dat gebruiken we in het dagelijks leven toch het begrip land. Voor Nederlands-Indië zouden we het misschien kunnen oplossen door bijv.:

1. (historisch), (land) -omschrijving- ; OF:
2. (historisch), (toponiem) -omschrijving-

Maar ik zou het jammer vinden als we vanwege politiek en geschiedenis de huidige situatie ook niet meer kunnen aanduiden en bijv. Nederland, Canada, Brazilië etc. niet meer als land kunnen benoemen. Als een of andere taal een spellingwijziging doorvoert, dan kunnen we ook ons hele bestand gaan aanpassen; is dat met wijzigingen in topografische namen ook niet hetzelfde? -- Curious 8 feb 2012 22:20 (CET)

Mijn voorstel lijkt het niet te halen, wat ik erg jammer vind, want de huidige situatie vind ik een slecht georganiseerde bende. Bovenal denk ik dat met de gegeven tegenargumenten we voorbijgaan aan de kern van een contextlabel. Een contextlabel is bedoeld om aan te geven binnen welke context een bepaald woord bedoeld is, dus de aanduiding toponiem geeft dan een verklarende context. Erachter wordt vervolgens de verklarende betekenis vermeld. Wanneer er echter als contextlabel provincie bijstaat, dan geeft dat geen context, omdat de aanduiding provincie de letterlijke betekenis is, en daarmee schiet mijn inziens de aanduiding provincie, maar ook rivier en anderen, hun doel voorbij, want die aanduidingen horen nou net gegeven te worden als verklarende betekenis en niet als context. Een verklarende betekenis en een context(label) hebben een totaal verschillende functie, die met deze labels te veel door elkaar loopt. groetjes - Romaine 9 feb 2012 03:54 (CET)

Het verschilt een beetje per wikti wat er precies wordt gedaan met de contextlabels. Bijv. bij en.wikt is het (als ik het goed begrijp) de bedoeling dat je alleen een contextlabel plaats als het woord niet in de normale dagelijkse taal wordt gebruikt, maar alleen in een bepaalde specifieke context. Hier bij nl.wikt gebruiken we de contextlabels om ook gewoon categorieën aan te maken, bijv. fruit, groente, kleding etc. -- Curious 11 feb 2012 21:07 (CET)

Verwijzing naar Wikispecies in lopende tekst

Zie bijv. akkerdoornzaad. Mijn vraag; is het wenselijk/gebruikelijk om op deze manier interne links naar andere projecten zoals Wikispecies te maken in een definitie? Normaal gesproken hoort zoiets toch ofwel in de zijbalk, ofwel kan het als illustratie worden toegevoegd. Wikiwoordfanaat 9 feb 2012 17:33 (CET)

Dat zat ik me idd ook af te vragen. Eigenlijk vind ik het er zo niet zo mooi uitzien. Zijn daar afspraken over? GRUNNEN ^OVERLEG 9 feb 2012 17:39 (CET) (gewoon even mijn indruk, ik laat de beslissing verder aan jullie hoor)

Het is hier al enige tijd gebruikelijk. En wat mij betreft ook wenselijk omdat het de meest directe wijze is om de definitie keihard neer te spijkeren. En daar gaat het toch om in een definitie, lijkt mij en niet zo zee aan het ons confomeren aan wat andere projecten allemaal voor gewoontes hebben ontwikkeld. Jcwf 9 feb 2012 17:43 (CET)

Ik heb me in het verleden ook wel verbaasd over het plots verschijnen van deze links in definities. Als ik echter alles bij elkaar bekijk, volg ik wel Jcwf's zienswijze. Het staats onmiddellijk bij een verklaring en ik kan me wel inbeelden dat eenzelfde begrip nog naar 2 verschillende pagina's op wikiscpecies zou kunnen verwijzen. En wat doe je als een verklaring hebt die een soortnaam is en een andere verklaring iets totaal anders. Dan staat een link in de linkerbalk niet op zijn plaats ... Annabel_(overleg) 9 feb 2012 21:34 (CET)

Encyclopedie?

Wat moeten we met definities als alfalfa en aloë vera? Dit lijkt me niet geschikt voor een woordenboek. --Ooswesthoesbes 11 feb 2012 16:37 (CET)

Die Frage verstehe ich nicht. Ein Wörterbuch erfasst Wörter und Phrasen. Warum diese Wörter nicht? Sie werden wie alle Wörter kurz erklärt, nicht lexikalisch? Alfalfa ist eine Zutat beim Kochen und aloë vera eine Pflanze. -- Cadfaell 11 feb 2012 17:39 (CET)

Het was voornamelijk een formaatprobleem: in plaats van een harde definitie plus een wat zachtere voorbeeldzin stond er een stukje encyclopische tekst die echter gemakkelijk om te zetten was in ons lexicale formaat. Owtb heeft wel gelijk dat wij ons aan een lexicaal formaat moeten houden dat de volgende doelen heeft

• eenduidig vastleggen wat een woord betekent (definitie)
• een eenvoudig voorbeeld geven van hoe het woord in het spraak- of schrijfgebruik gebruikt wordt of kan worden. (voorbeeldzin)

Het laatste is vooral bedoeld om het eerste te ondersteunen maar als de voorbeeldzin extra informatie rond het woord verschaft is dat m.i. een nuttige bonus, ook al schept dat wat overlap met de encyclopedische behandeling. Tenslotte begint ook ieder wikipediaverhaal met een soort lexicale definitie: het spiegelbeeld van nuttige en noodzakelijke overlap. Zo lang het hoofddoel maar duidelijk blijft (lexicaal in ons geval en encyclopedisch voor wiki) heeft dat nooit problemen gegeven. Doel van het al is immers vooral de lezer die soort informatie te beiden die deze verwacht en verder een doorklik te bieden naar andersoortige info indien de lezer dit wil.

Jcwf 11 feb 2012 18:03 (CET)

Aanvullend op het bovenstaande: net deed Kvdrgeus deze en deze toevoegingen. Ongetwijfeld goed bedoeld, maar het toevoegen van dit soort gedetailleerde informatie lijkt me hier niet de bedoeling. Daar zijn zusterprojecten als wikipedia en wikibooks immers voor. Wikiwoordfanaat 12 feb 2012 13:25 (CET)

Fout geschreven woorden

Hebben we ook een sjabloon/categorie voor fout geschreven woorden, die toch worden gebruikt in de Nederlandse taal? Denk bv aan arreslee. Romaine 11 feb 2012 20:26 (CET)

Nee, volgens mij is de overeenstemming al heel lang dat deze woorden niet opgenomen worden in het woordenboek. Het is ook niet nodig, want met de nieuwe zoeksuggesties is het niet meer zo lastig de goede variant te krijgen. --Ooswesthoesbes 12 feb 2012 08:25 (CET)

arreslee is geen goed voorbeeld van een fout geschreven woord. Net als bijv. pannekoek en insekt is het alleen maar een niet meer officieel toegestane schrijfwijze. Dat soort schrijfwijzen wordt wel gewoon opgenomen, met een speciaal sjabloon om aan te geven dat het een verouderde spelling is. Wikiwoordfanaat 12 feb 2012 09:29 (CET)

En dat sjabloon is? ah: sjabloon:oudeschrijfwijze

We hebben trouwens ook nog het groene boekje en het witte boekje, twee spellingsvarianten. Romaine 12 feb 2012 19:31 (CET)

Ja, dat klopt. Alleen is het hier op wikiwoordenboek voorgeschreven om de spellingsregels van de TU - en dus het Groene Boekje - als de enige officiële aan te houden. Zelf vind ik dat overigens nogal vergezocht, de spelling van het alternatieve Witte Boekje wordt zelfs door kranten als de NRC gewoon aangehouden. Daarnaast vind ik persoonlijk verschillende van de sinds 1995 doorgevoerde spellingregels zoals die voor de tussen-n (waar dus bijv. de schrijfwijze arrenslee uit is voortgekomen) een nachtmerrie, dat mag van mij liever vandaag weer worden teruggedraaid dan morgen. Maar goed, dit terzijde. Wikiwoordfanaat 12 feb 2012 19:42 (CET)

MediaWiki 1.19

(Apologies if this message isn't in your language.) The Wikimedia Foundation is planning to upgrade MediaWiki (the software powering this wiki) to its latest version this month. You can help to test it before it is enabled, to avoid disruption and breakage. More information is available in the full announcement. Thank you for your understanding.

Guillaume Paumier, via the Global message delivery system (wrong page? You can fix it.). 12 feb 2012 16:12 (CET)

Misbruik van gebruikerspagina's

Ik weet het, ik weet het, gebruikerspagina's zijn heilig en daar mogen we niet aankomen, maar kunnen we Gebruiker:Infoalgerie dit nu echt accepteren? Of moeten we deze gebruiker maar gewoon blokkeren en de pagina leegmaken? We hebben op dit punt niet echt een sluitend beleid. Jcwf 13 feb 2012 14:56 (CET)

Een gebruikerspagina is bedoeld ter ondersteuning van een gebruiker op dit project, bv omdat die interwikilinks legt of kenbaar maakt op welk ander project van de Wikimedia Foundation die actief is. Gebruiker is echter niet actief én heeft behalve zijn gebruikerspagina niets bijgedragen én niet vermeld op welk ander project die actiefis. Geen van dit alles doet deze gebruiker en heb daarom de pagina verwijderd omdat daar een gebruikerspagina niet voor is. Romaine 13 feb 2012 15:08 (CET)

Precies. Voor linkspam of opiniestukken is geen plaats op het WikiWoordenboek, ook niet als "gebruikers"pagina. Voor zoiets zijn er alternatieven die men hostingsites noemt. Annabel_(overleg) 13 feb 2012 15:24 (CET)

Mee eens. Dit is een woordenboek; geen reclamefolder, profielensite, cv-bank, column, of privéwebsite. Het lijkt me terecht dat we dat soort pagina's onverbiddelijk wissen. Mocht een gebruiker volharden in het plaatsen van het ongepaste materiaal, dan lijkt me de volgende stap om de gebruiker dan maar helemaal te blokkeren. -- Curious 13 feb 2012 23:32 (CET)

architect en bouwmeester

Sinds vandaag is er de pagina bouwmeester, die dit begrip volledig gelijkschakelt met architect. Vraag: is dit terecht? Voor mijn gevoel is er een licht verschil in nuance, getuige een zin als Opvallend is dat ook de Vlaamse overheid zelf vragende partij was om een praktiserend architect aan te stellen als bouwmeester, [8]. Denkt men bij een bouwmeester misschien eerder aan iemand die concreet aanwezig is en leiding geeft? Wikiwoordfanaat 14 feb 2012 19:21 (CET)

"Denkt men bij een bouwmeester misschien eerder aan iemand die concreet aanwezig is en leiding geeft?" Ja, dat is wel waar ik eerder aan zou denken. -Grunnen

Voorstel 6: naamgeving van sjablonen

In de voorbije weken ben ik bij het invullen van taalcodes op talloze sjablonen gestuit voor bv het meervoud/verkleinwoord van zelfstandige naamwoorden, waarbij tweeletterige taalcodes om-het-even afgewisseld worden door drieletterige taalcodes. Tevens is er geen eenduidige manier waarop de naam van alle sjablonen tot stand komt. Het is een zooitje en gaf mij regelmatig verwarring. Ik denk dat de naamgeving van sjablonen veel overzichtelijker, duidelijker en logischer kan. Zodoende onderstaande voorstellen. Voor categorieën hebben we reeds een standaard opbouw van naamgeving, mij lijkt het tijd dat dat ook komt voor sjablonengroepen. Romaine 15 feb 2012 06:24 (CET)

Bedankt voor de nieuwe reeks voorstellen, Romaine! -- Curious 15 feb 2012 22:10 (CET)

Ik twijfel nog. Enerzijds heeft Romaine gelijk dat we alles consistenter kunnen maken, anderzijds is het een enorme operatie (zowat alle pagina's en sjablonen moeten aangepast worden) terwijl alles op dit moment prima werkt en er geen directe noodzaak is voor wijzigingen. -- Curious 16 feb 2012 22:52 (CET)

Ik zou hieraan willen toevoegen dat je alle boteigenaars mee moet hebben (waaronder ForkBoy en mezelf). Wat mij betreft, weet ik niet of ik met alle diepgaande wijzigingen meekan. Als transtool voor vertalingen kapot gaat, blijft die kapot. Daar heb ik gewoon geen tijd voor om aan te passen (normaal zou dit voorstel geen probleem mogen opleveren, maar hoe noemt die wet over een mug ook alweer?). Verder heb ik ook botcode voor het toevoegen van lettergrepen en het ingeven van vervoegingen/verbuigingen. Daar voorzie ik wel problemen en van de mate van wijzigingen met de plaats van taalcode en type (ISO 639-1 of ISO 639-3) zal het afhangen of die na kapotgaan gereanimeerd zal worden. (eveneens bij gebrek aan programmeertijd) Annabel_(overleg) 16 feb 2012 23:21 (CET)

(na bwc) Ik ben het in grote lijnen eens met Curious. Het voorstel van Romaine waar ik me redelijk in kan vinden is het grotendeels afschaffen van de streepjes voor en achteraan in het sjabloon {{-...-}}, maar voor de rest vind ik het sop dus eigenlijk gewoon de kool niet waard. Het overal doorvoeren van een driecijferige taalcode lijkt me zelfs ronduit een verslechtering. Iets anders overigens: volgens mij zou het pas echt rendement opleveren als de syntax voor het linken vanaf een pagina naar een overeenkomende pagina op een ander wikimediaproject buiten wikipedia kon worden vereenvoudigd, zodat je bijv. alleen met een B of een Q al naar wikibooks of wikiquote zou kunnen linken en de code ook niet standaard zou zijn gekoppeld aan het sjabloon {{-info-}}. Nu is dat nog bijv. als volgt voor het linken naar wikiquote: {{-info-|Q=XXX}} Wikiwoordfanaat 16 feb 2012 23:26 (CET)

Ik was er vanuit gegaan dat dit karwei puur door mij uitgevoerd zou worden. Voor mijn bot is dit veel eenvoudiger te doen dan het overal invullen van de taalcodes in sjablonen en ook dat is me prima gelukt. Ik denk dat we ons over de omvang/uitvoer geen zorgen dienen te maken, ik heb met dit soort veranderingen redelijk wat ervaring. En mochten er toch zorgen zijn, desnoods wordt het gefaseerd doorgevoerd.

Een veel belangrijkere vraag die we ons moeten stellen is hoe eenvoudig/overzichtelijk/etc willen we dit project hebben? Een van de dingen die me al een tijd opvalt is dat er naar mijn indruk bijzonder weinig nieuwe gebruikers actief worden, terwijl ik in feite denk dat de inhoud van dit project eigenlijk heel eenvoudig en helder is. Waarom vraag ik me af? Nieuwe gebruikers zullen tegen meer dingen aanlopen dan meer ervaren gebruikers, wellicht handig dan eens te kijken waar een ervaren gebruiker tegenaan loopt, omdat daar een nieuwe gebruiker wellicht ook last heeft. Ik ben zelf redelijk ervaren maar loop toch tegen dingen aan:

• Alles zit zowat in sjablonen, dat heeft duidelijk voordelen, maakt het op een aantal vlakken veel eenvoudiger, maar tegelijkertijd bijzonder ontoegankelijk als je niet weet welk sjabloon je gebruiken moet. Ik wilde laatst een vervoeging van een werkwoord aanmaken, toen ik het sjabloon er voor niet kon vinden heb ik het opgegeven.
• Er is geen handige manier secties aan pagina's toe te voegen.
• Zeer inconsistente en gebrek aan logische opbouw in de naamgeving van sjablonen.
• En nog wel meer...

Dit zijn mijn problemen, waarbij behalve het tweede punt denk ik dat een kwestie is van een gebrek aan organisatie in sjablonen. We hebben maar wat aangerommeld. Wikipedia-nl is natuurlijk een heel ander project met een andere soort inhoud en opbouw van artikelen, toch denk ik dat we van dat project wat kunnen leren. In 2007 is er op nl-wiki geconstateerd dat sjabloonnaamruimte een grote chaos was, met onder andere problemen met sjablonen, geen consistentie in het uiterlijk, onduidelijk hoe sjablonen gebruikt moesten worden en gigantisch veel onduidelijke sjablonen en sjabloonnamen. Er is toen overleg geweest om alle sjablonen (waar zinvol en mogelijk) een vast voorvoegsel te geven met daarachter een logische opbouw in de naamgeving. Daarna is begonnen met het hernoemen van sjablonen, waarbij tevens uitleg is gegeven over het gebruik van sjablonen met parameters, de opmaak meer gelijkgetrokken is zodat de sjablonen een meer consistent geheel vormen, zijn er problemen uit sjablonen gehaald en op die manier de hele sjabloonnaamruimte overzichtelijker is gemaakt. Een van de uitgangspunten van de hernoemingen was dat bij het bewerken van een pagina de naam van het sjabloon relatief duidelijk moest zijn, grotendeels al geregeld door middel van een vast voorvoegsel dat ook de functie van het sjabloon aanduidde. Een navigatiebalk kreeg "navigatie" als voorvoegsel, een infobox het voorvoegsel "infobox", een tabel het voorvoegsel "tabel", positiekaarten het voorvoegsel "positiekaart", enzovoorts. En dit blijkt een doorslaand succes! Sjablonen zijn hierdoor eenvoudiger en begrijpelijker geworden.

Een duidelijk systeem van hoe we sjablonen benoemen met een voorvoegsel is ook op WikiWoordenboek mogelijk. We moeten ons alleen wel realiseren dat WikiWoordenboek een heel ander type informatie bevat en een andere opzet heeft in pagina's en manier van werken. Toen ik met mijn botrun voor voorstel 1 de talloze inconsequenties en chaos tegenkwam ben ik gaan nadenken over wat het sjabloonprobleem zou kunnen reduceren of oplossen. Daarbij heb ik een serie afwegingen gemaakt waarbij ik met alles rekening heb proberen te houden (zo kort als mogelijk weergegeven):

1. Een nieuw systeem of het bestaande systeem van Wikipedia overnemen? Wikipedia heeft een zeer goed werkend systeem, maar de inhoud van Wikipedia in artikelen is van een heel ander type. Als we het systeem van Wikipedia letterlijk overnemen, zou dat werkbaar zijn? Nee, omdat dan ieder sjabloon een totaal andere naam krijgt. Conclusie: nieuw systeem dat zo veel als mogelijk lijkt op de bestaande situatie op WikiWoordenboek, daardoor herkenbaar en eenvoudiger om te schakelen.
2. Zijn vaste voorvoegsels zinvol en zo ja welke? Zomaar wat vaste voorvoegsels afspreken is niet zinvol, ze dienen afgestemd te zijn op het project en de inhoud van de pagina's en de sjablonen. Het eerste woord van het sjabloon is het meest belangrijke woord (vooraan = belangrijker): daar valt als eerste de aandacht op en moet meteen de functie duidelijk maken van het sjabloon. Conclusie: vast voorvoegsel is zinvol mits afgestemd op inhoud project. Zover ik kan bedenken zijn er drie opties om standaard als vast voorvoegsel te kunnen gebruiken: taalcode als voorvoegsel, onderwerp als voorvoegsel, of een ander woord als voorvoegsel (bv de functie).
   • Het belangrijkste kenmerk van een sjabloon is niet de taal waar die in is, maar het onderwerp. Bv Sjabloon:-denoun-, qua inhoud komt dit sjabloon overeen met Sjabloon:-nnnoun-, veel meer dan Sjabloon:-denoun- vergeleken met Sjabloon:-destam-. Het eerste woord in de naam van een sjabloon zou echt generiek moeten zijn, van toepassing op meerdere overeenkomstige sjablonen. (Tevens is het voor het oog praktisch en overzichtelijk als bij ieder sjabloon visueel gezien de taalcode op dezelfde plek zich bevindt: ergens meer naar achteren en niet in het ene sjabloon achteraan (ingevuld als taalcode) en bij het andere vooraan.) Conclusie: niet de taalcode, die is daarvoor niet geschikt: daarvoor verschilt de inhoud van Sjabloon:-denoun- te veel met Sjabloon:-destam- en is er te weinig generieke waarde.
   • Een andere optie is een nieuw vast voorvoegsel bedenken, bijvoorbeeld "tabel". Het duidelijke voordeel hieraan is dat de functie meteen duidelijk wordt, zeker als consistent . Op zich een heel goed idee, al betekent dit echter wel meer typwerk en wijkt heel erg af van wat we gewend zijn. Dat hoeft geen reden te zijn, maar het meest handige zou zijn wanneer een optie meer zou aansluiten op de bestaande situatie. Verder denk ik dat het onderscheid tussen tabel- en niet-tabelsjablonen weinig toevoegt gezien mijn ervaring met voorvoegsels, terwijl woordsoorten als voorvoegsel gebruiken (zie volgende punt) sterk aansluit op de bestaande situatie en ook zinvoller onderscheid lijkt te maken. Conclusie: woordsoort is zinvoller dan een ander voorvoegsel.
   • De bestaande manier van onderscheid maken is op het vlak van noun, verb, adjc, adverb, conj, num, ordn, prep, art, etc. Ook binnen de sectie van een taal kunnen meerdere woordsoorten voorkomen en is het woordsoort het belangrijkste verschil tussen twee sjablonen. Ook al zijn er verschillen tussen talen, de verschillen zijn erg beperkt en veel kleiner dan tussen een stam (van verb) en noun. En met deze optie blijft de nieuwe naam vergelijkbaar met de oude naam en door die herkenbaarheid eenvoudiger eigen te maken. Conclusie: woordsoortbenamingen als voorvoegsel zijn het meest duidelijk, relatief weinig verandert en met het beste onderscheidende resultaat. Het systeem is verder erg eenvoudig en overzichtelijk.
3. Welke taalcodes? We hebben nu een heel goed werkend systeem van drieletterige taalcodes, waarbij zeer consistent steeds drie letters gebruikt worden. Het lijkt mij vreemd van een goed werkend systeem af te stappen, beter lijkt het mij juist om daarop aan te sluiten. Hoe dingen buiten WikiWoordenboek zijn staat op zich los van de interne organisatie.

Dit is in het kort een overzicht van afwegingen. Het is misschien moeilijk uitgelegd, onvolledig of niet helemaal te volgen, maar wil hierbij wel aangeven dat ik het zeer nauwgezet doordacht heb met alle gevolgen in het oog proberen te houdend. Ik begrijp dat het nog moeilijk te zien is omdat het er (nog) niet is. Ik zie het zelf wel voor me, mede met de ervaring die ik heb op het gebied van de naamgeving van sjablonen op nl-wiki.

Ik denk ook dat het zinvol is om dit totale pakket van wijzigingen in één keer doorgevoerd zou moeten worden, al kan de definitieve omschakeling (dus met overgangsfase) nog wel een tijd wachten. Ik denk dat het handig is in één keer een goed systeem te krijgen.

Ondertussen vraag ik me af of dit voorstel ooit uitgevoerd gaat worden en/of dat er echt verbetering op dit vlak gaat komen. Het is logisch dat diverse gebruikers een mening geven, daarvoor is het een samenwerkingsproject, maar als er geen overeenstemming komt zal het blijven aan rommelen en het een zooitje blijven, die zooi werd ik zat en demotiveerde me, ik zou hem graag opruimen. Ieder heeft een persoonlijke smaak en persoonlijke voorkeuren, en daardoor een andere mening, en alleen als we inzien dat we een probleem hebben met de huidige situatie en onze meningsverschillen trachten te overbruggen om tot een weldoordachte oplossing te komen, denk dat we dit project echt kunnen verbeteren en toegankelijker kunnen maken van andere gebruikers. Groetjes - Romaine 18 feb 2012 14:52 (CET)

Voorstel 6a: driecijferige codes

Voorstel: we koppelen alle woordenboekingangen en vele categorieën reeds aan de driecijferige taalcodes (met de taalkop, woordsoortsjablonen en contextlabels), laten we aan diezelfde taalcodes ook de sjablonen ophangen. Dit betekent dat waar er in de sjabloonnaam thans een tweeletterige taalcode wordt gebruikt, daar voortaan een drieletterige taalcode gebruikt gaat worden.
Aanvullende reden: Door overal een drieletterige code te gebruiken vergemakkelijkt dat de identificatie van de bedoelde taal. Ik heb het bv verwarrend ervaren dat het sjabloon:esadjc is en er geen spa gebruikt wordt in de naam, de overal gebruikte taalcode voor Spaans.

Graag reactie! Romaine 15 feb 2012 06:24 (CET)

• Zeker voor. Op li.wikt gebruiken we (of ja.. "we" is 'n groot woord :P) al heel lang alleen maar driecijferige codes (m.u.v. de iw's dan, maar daar valt weinig aan te doen). Dat ene lettertje meer typen zal echt geen dramatische gevolgen hebben. --Ooswesthoesbes 15 feb 2012 18:03 (CET)
• Geen reden om te veranderen. Tweecijferige taalcodes hebben we bijvoorbeeld ook gewoon nodig bij vertalingen. Niks aan de hand met het gebruik van ISO 639-2. Annabel_(overleg) 15 feb 2012 20:00 (CET)
  • Als er ergens aanpassing plaatsvindt door een der voorstellen, dan is het eenvoudig mee te nemen. Waar ik me vooral aan erger is de totale inconsequente manier van werken ten aanzien van taalcodes. We gebruiken voor het Spaans op de ene plek spa en op een andere plek es, ik vind dit een puinzooi. Verder heb ik gemerkt dat we met de taalsjablonen en de invullingen van taalcodes in contextlabels en andere sjablonen een zeer degelijk systeem hebben gecreëerd. Dat degelijke systeem zou ik graag breder gebruikt zien worden, onder meer door overal te refereren aan dezelfde taalcode. Voor een woordenboek dat verschillende talen bevat is het heel belangrijk te kunnen duiden welke taal een item toe hoort, en dat kan mijn inziens alleen goed met een eenduidig systeem aan taalcode-referentie en taal-identificatie. Romaine 16 feb 2012 17:47 (CET)
    • Misschien. De regel is nochthans eenvoudig. Spreken overtwee- versus drieletterige taalcodes is overigens foutief. We gebruiken historisch ISO 639-1, maar door de veelheid aan talen die we tegenwoordig behandelen bestaan de sjablonen voor de taalkopjes (deze met = =) uit ISO 639-3 codes omdat het niet anders kan. Persoonlijk vind ik ISO 639-1 handiger, wat ook in de vertalingen nog altijd nodig is om door te linken naar de andere wikis. (deze site is toch ook niet nld.wiktionary.org ?) Annabel_(overleg) 16 feb 2012 20:45 (CET)
• Tegen. Mij lijkt dat door overal driecijferige taalcodes door te voeren de boel eerder juist ingewikkelder wordt. Ik zou er dan eerder voor pleiten de tweecijferige taalcode universeel te maken, hoewel ik met de huidige situatie evenmin moeite heb. Wikiwoordfanaat 15 feb 2012 21:15 (CET)
  • Wat is makkelijker? esnoun op het ene moment en noun|spa op het andere moment, of op beide momenten spa gebruiken? De beide sjablonen staan vaak vlak boven elkaar vermeld. Romaine 16 feb 2012 17:47 (CET)
• Ik zou liever de tweelettercodes gebruiken waar mogelijk. In het geval van Mandarijn moet dat dan wel verhelderd worden want zh en cmn zijn niet hetzelfde (de Engelse Wiktionary zit momenteel met hetzelfde probleem). —CodeCat 16 feb 2012 14:12 (CET)
  • Ik liever niet, een beetje van dit en een beetje van dat vind ik rommeliger dan overal op de wiki hetzelfde taalcode systeem te gebruiken. Romaine 16 feb 2012 17:47 (CET)
• Enige consequentie zou inderdaad welkom zijn. Overal drieletterige codes gebruiken is sowieso niet haalbaar (zoals Annabel aangeeft in verband met de vertalingen), maar op z'n minst zouden de bestaande sjablonen een gelijk systeem moeten volgen Sjabloon:-srnoun- naast Sjabloon:-bosnoun- lijkt mij onzinnig, aangezien beide talen een tweeletterige code hebben. Het voordeel van drieletterige codes zou dan wel zijn dat ook talen zonder tweelettercode in het systeem passen. Wikibelgiaan 20 feb 2012 01:15 (CET)

Voorstel 6b: streepjes voor/achteraan

Voorstel: De streepjes vooraan en achteraan een sjabloon {{-.....-}} alleen gebruiken als een sjabloon daadwerkelijk een kopje is, zoals dat initieel bedoeld was. Momenteel zijn er sjablonen die geen kopje hebben maar wel de streepjes.
Aanvullende reden: Regelmatig heb ik bij het bewerken van een artikel terug moeten kijken hoe het artikel eruit ziet door het inconsequente gebruik van de streepjes in de naam van sjablonen.

Graag reactie! Romaine 15 feb 2012 06:24 (CET)

• Klinkt logischer, dus ik vind 't goed. --Ooswesthoesbes 15 feb 2012 18:04 (CET)
• Voorlopig niet pro: graag voorbeelden ter verduidelijking waartoe dit kan leiden. Annabel_(overleg) 15 feb 2012 19:56 (CET)
  • Alles wat geen kopje is geen streepjes. Dat betekent bijvoorbeeld dat -nlnoun- -> nlnoun wordt, want dit is een tabel en geen kopje. Romaine 16 feb 2012 17:52 (CET)
    • Ik zie in dat dit de duidelijkheid kan bevorderen, al kan ik niet bevatten welke impact dit op de werking van de wiki zal hebben (sjablonen + afhangende bots). Enthousiast kan ik dan ook niet zijn (maar tegen zijn daarentegen ook niet). Annabel_(overleg) 16 feb 2012 20:46 (CET)
• Aan die inconsequentie ben ik schuldig: ik heb heel lang niet geweten dat de streepjes bedoeld waren gereserveerd te zijn voor een kop. Maar dat dat problemen geeft is echter geheel nieuw voor mij. Van mij mogen de streepjes overigens best weg, hoewl Annabel wel gelijk heeft dat we dat moeten afwegen tegen de zwaarte van de operatie om het allemaal om te gooien. Waar je mee te maken hebt is gewoon de wordingsgeschiedenis. Historisch is zoiets als adjcomp het oudste, later ontstond er behoefte aan taalspecificatie en heb ik er dus zoiets als -nlnoun- van gemaakt; daarna zijn we pas overgaan van nl naar nld en ik moet zeggen dat ik daar een beetje spijt van heb omdat wikimedia daar nooit mee mee zal gaan; een naam als "nl-noun" (zoals op het Engelse net) is nóg jonger. Achteraf gezien zou dat misschien handiger geweest zijn, maar dat is wel achteraf praten. Jcwf 15 feb 2012 21:03 (CET)
• Ik vind dit wel een goed idee, zo zie je straks bijv. in de bewerkingssamenvattingen beter waar de verschillende kopjes beginnen en ophouden. Wikiwoordfanaat 15 feb 2012 21:15 (CET)
• Ik wist dit ook niet, dus als het doorgevoerd moet worden lijkt het me handig als dit ook duidelijk wordt aangegeven. —CodeCat 16 feb 2012 14:13 (CET)
  • De sjablonen met = en = zijn de hoofdkopjes waar alles onder behoort te vallen, het niveau eronder zijn de - en - kopjes, en de sjablonen zonder kopjes zouden eigenlijk geen = of - voor/achteraan moeten hebben was lang het uitgangspunt. Romaine 16 feb 2012 17:52 (CET)
• A priori ben ik volledig voor (ik wist ook niet dat die streepjes kopjes aanduidden), maar ik vrees dan wel dat de helft (of meer?) van de pagina's veranderen zal moeten ondergaan. Dan lijkt een sjabloon als adjcomp (zonder taalaanduiding) mij verwarrender qua titel dan de streepjeskwestie. Wikibelgiaan 20 feb 2012 01:19 (CET)

Voorstel 6c: taalcode duidelijk gescheiden van rest sjabloonnaam

Voorstel: De taalcodes in de sjabloonnaam scheiden van de rest van de sjabloonnaam door middel van een streepje. Momenteel staan ze regelmatig met streepje, maar ook regelmatig gewoon aan elkaar, duidelijkheid komt dat niet ten goede. Een ander teken dan een streepje kan ook, zoals bijvoorbeeld een schuine streep: /, als het maar niet aan de rest van de naam vast zit.
Aanvullende reden: Met scheidingsteken tussen de taalcode en de naam is een sjabloon duidelijker te identificeren behorende tot een bepaalde taal.

Graag reactie! Romaine 15 feb 2012 06:24 (CET)

• Ik zou voor een koppelstreepje gaan. Een schuine streep is niet zo praktisch, omdat het bij het bewerken van de pagina uitziet als een afgeleide van een onbenoemd sjabloon. --Ooswesthoesbes 15 feb 2012 18:05 (CET)
  • Daar heb je een punt, dank voor het melden. Romaine 16 feb 2012 18:06 (CET)
• Nergens voor nodig om dit aan te passen wat mij betreft. Welke sjablonen zijn er overigens met een schuine streep? Annabel_(overleg) 15 feb 2012 19:57 (CET)
  • Op zich is er nooit iets nodig om aan te passen, maar dan wordt het er ook nooit beter op. En met de huidige situatie denk ik dat er héééél veel beter kan. In de eerste plaats gaat het hier om een teken dat tussen de taalcode en de rest van de sjabloonnaam komt te staan. Uitgaande van de huidige situatie is dat een horizontaal streepje, iets anders kan eventueel ook. Ik ken geen voorbeelden van het gebruik van een schuine streep, maar als we echt een eenvoudig helder systeem willen hebben kan dat overwogen worden. Romaine 16 feb 2012 18:06 (CET)
  • Wat mij betreft niet (zoals hierboven geschreven), maar indien besloten wordt dit aan te nemen, dan is het voor mij wel gekoppeld aan deelvoorstel e met de typenaam achteraan: sjabloontype - liggend streepje - taalcode. Annabel_(overleg) 16 feb 2012 20:50 (CET)
• Historisch was de norm: gewoon ervoor plakken en wel de tweelettercode als die er was. Dat hield de boel kort en bondig zoals bij -nlnoun- maar het vervelende daarvan was dat je monsters krijg als svpronom-indef of gaanatomie-schedel of zo. Wat dat betreft is er wel wat voor te zeggen on ze er standaard achter te plakken na een een streepje. (Of iets anders? _nld of zo? Dan heb je onderscheid met andere streepjes in de naam: anatomie-schedel_nld of zo? Een schuine streep heeft denk ik te zeer een eigen betekenis zoals OWTB zegt. Oh je wilt juist naar subsjablonen! Daarover hieronder.Jcwf 15 feb 2012 21:27 (CET)
  • Met dit (deel)voorstel wilde ik enkel zorgen dat er tussen de taalcode en de rest van de naam van het sjabloon een streepje of iets dergelijks komt te staan, omdat ik me er ondertussen al meermaals op verkeken heb. Dus bv van -nlnoun- -> -nl-noun-, van nnnoun -> nn-noun Romaine 16 feb 2012 18:06 (CET)
• Voor, dit verduidelijkt het zeker. —CodeCat 16 feb 2012 14:14 (CET)

Voorstel 6d: taalcode gescheiden door schuine streep

(vervolg op 6c)
Voorstel: De taalcode duidelijk gescheiden van de rest van de sjabloonnaam door middel van een schuine streep. In de informatie worden bestandsnamen en mappen gescheiden van elkaar door middel van een schuine streep, alsmede is dit op een wiki mogelijk. Zie bijvoorbeeld het sjabloon w:Sjabloon:Hoofdpagina/Projecten, direct onder de titel staat daar het sjabloon gelinkt waar het bij hoort. Op die manier kan er meer overzichtelijkheid gecreëerd worden, kan men gemakkelijker navigeren en zijn sjablonen en informatie beter terug te vinden.
We hebben bijvoorbeeld Sjabloon:anatomie-schedel en een hele serie sjablonen in de vorm Sjabloon:anatomie-schedel-eng met eng als de taalcode. Door van de naam Sjabloon:anatomie-schedel/eng te maken is duidelijker dat /eng de taalspecifieke variant is en Sjabloon:anatomie-schedel het hoofdsjabloon voor dat onderwerp.

Graag reactie! Romaine 15 feb 2012 06:24 (CET)

• Ik zie geen echt voordeel hierin. Het is zo denk ik ook wel duidelijk genoeg. Verder komt het systeem zo nog overeen met li.wikt en dat is - voor mij - dus makkelijker werken. --Ooswesthoesbes 15 feb 2012 18:07 (CET)
• Onnodig en onzinnige extra belasting van de wiki met al die extra bewerkingen. Annabel_(overleg) 15 feb 2012 20:01 (CET)
  • Inderdaad, nieuwe gebruikers kunnen totaal niet overweg met ons huidige systeem, daar dus meer logica in de naamgeving van sjablonen brengen dan zou alleen maar resulteren dat meer nieuwe gebruikers nieuwe woordenboekingangen zouden inbrengen omdat de sjabloonnamen duidelijker en helderder worden. Dat wordt echt een te grote belasting voor de servers als we meer gebruikers krijgen. (Verder hebben de technici die de servers onderhouden duidelijk gesteld dat we moeten kijken naar wat nodig is voor een project, en dat serverbelasting tenzij zij dat aangeven geen issue dient te zijn.) Romaine 16 feb 2012 18:14 (CET)
    • Dat argument ken ik ook. Waar het over gaat, is dat je geen botbewerkingen moet doen om er te doen. Als ik het zo'n beetje goed overzie ligt de gemiddelde botbewerkingsgraad van een woordenboekingang tussen 3 en 4 (exclusief bewerkingen voor interwiki's). Oftewel, op de gemiddelde pagina zijn er zo'n drie bewerkingen afkomstig van het herwerken van de wiki. Verder, een schuine streep: nee, dat niet vanwege de speciale betekenis (voor subpagina's). Punt. Annabel_(overleg) 16 feb 2012 20:41 (CET)
• Kan straks een enkele keer misschien idd. iets schelen qua leesgemak, maar om hier nu echt een grootschalige wijziging door te gaan voeren... is het middel dan niet eigenlijk gewoon erger dan de kwaal, zogezegd? Wikiwoordfanaat 15 feb 2012 21:15 (CET)
• Tja, dat is natuurlijk wat meer dan alleen hoe-noemen-we-het-beestje-precies... Eerlijk gezegd kan ik niet goed overzien hoe dat zou werken en welke onvoorziene mogelijk- of moeilijkheden dat oproept. Je zou dit idee misschien eerst eens moeten uitproberen, blijvoorbeeld op de anatomie-schedel sjablonen. Je zou zelfs kunnen denken aan anatomie/schede/nld versus anatomie/oog/eng of zoiets. Je krijgt dan hierarchie in de sjablonen. Interessant idee, maar dan kun je natuurlijk ook gaan denken aan kop/noun/nld of zo of /kop/voornaamwoord/bezittelijk/nld. Zou best mooi kunnen zijn maar het is wel een erg grondige verandering. Nogmaals: eerst maar eens een experimentje om te zien was de gevolgen zijn want ik kan dat niet overzien zo. Jcwf 15 feb 2012 21:40 (CET)
• Subsjablonen kunnen helpen, maar ik weet niet of het echt nodig is. Een koppelstreepje werkt ook lijkt me. —CodeCat 16 feb 2012 14:15 (CET)
• Zo'n hiërarchie van sjablonen is in theorie heel mooi, maar dan moet er wel een plek gevonden worden voor de talrijke sub-subsjablonen zoals -lanoun-1, -lanoun-2-us, enz. (en zo zijn er voor vele talen). Hoe zou je dat dan doen? Iets als noun/lat/1, noun/lat/2/us? Nu nog tijd vinden om de structuur in de praktijk uit te werken (en tegelijk tijd te steken in de echte uitbreiding van het woordenboek...). Wikibelgiaan 20 feb 2012 01:27 (CET)
• Het lijkt me beter om niet te beginnen aan een systeem met subsjablonen (en sub-subsjablonen etc.) Ik denk dat het systeem dan onnodig ingewikkeld gemaakt wordt. Zoals Jcwf zegt, zal het in ieder geval van tevoren getest moeten worden of alles nog wel blijft werken zoals we bedoelen dat het werkt. Ik zie eigenlijk geen voordelen aan sub(sub)sjablonen, maar als die er zijn, dan laat ik me graag overhalen. -- Curious 21 feb 2012 22:21 (CET)

Voorstel 6e: volgorde opbouw sjabloonnaam

Voorstel: De taalcode komt achteraan in de sjabloonnaam te staan, waarbij dus het onderwerp van het sjabloon vooraan staat. De opbouw van een sjabloonnaam is momenteel erg wisselend, dan staat de taalcode achteraan, dan weer vooraan.
Aanvullende reden: We hebben een aantal generieke sjablonen en series taalspecifieke sjablonen. Door steevast de taalcode achteraan achter de generieke sjabloonnaam te zetten wordt duidelijker gemaakt bij welk onderwerp een sjabloon hoort. Handig is om hierbij vaste voorvoegsel te creëren. Mij lijkt de woordsoorten noun, verb, adjc, etc, en ook de onderwerpen, het meest handig om als voorvoegsel te houden met daarachter dan de taalcode. Alle zelfstandignaamwoordsjablonen beginnen dan met noun, alle werkwoordsjablonen met verb, etc. Vergelijk bijvoorbeeld:

{{noun-nld}} of {{noun/nld}} met

{{-noun-|nld}}

Tegenwoordig vullen we als eerste parameter op de meeste plekken de taalcode in, door op die vergelijkbare plek de taalcode te zetten oogt het mijn inziens overzichtelijker en in vergelijking met de overal in te vullen taalcodes ook duidelijker.

Graag reactie! Romaine 15 feb 2012 06:24 (CET)

• Zou je een concrete voorbeeld kunnen leveren van hoe het verschil eruit komt te zien? Ik zie nu namelijk al -noun-|nld staan. --Ooswesthoesbes 15 feb 2012 18:11 (CET)
  • Nu staat er:

    {{-nlnoun-|{{pn}}|{{pn}}en|{{pn}}tje|{{pn}}tjes}}

    {{-noun-|nld}}

  • Dat zou dan veranderen in:

    {{-noun-nld-|{{pn}}|{{pn}}en|{{pn}}tje|{{pn}}tjes}}

    {{-noun-|nld}}

  • In plaats van vooraan dan overal op dezelfde plek: achter de naam van het sjabloon. Op die manier kan de taalcode ongeveer op dezelfde plek verwacht worden. Romaine 16 feb 2012 18:20 (CET)
    • -noun-nld- of noun-nld? Het tweede lijkt me logischer. --Ooswesthoesbes 16 feb 2012 19:18 (CET)
      • Als voorstel 6b aangenomen wordt: noun-nld. Romaine 16 feb 2012 21:32 (CET)

• Sorry, maar ik begrijp dit niet. Heb je het nu over -noun- dat een kop genereert of -nlnoun- dat een tabelletje genereert? Verder begrijp ik niet hoe je xxx|yyy kunt vervangen met xxx/yyy, want het eerste luidt een parameter in van het xxx sjabloon. Het tweede genereert -denk ik- een nieuw sjabloon data xxx/yyy heet. Ik denk dat ik inmiddels beter begrijp wat je bedoelt, hoewl ik niet kan overzien hoe dat dan precies gaat met parameters op de diverse niveaus van de sjablonen. Wil je wel twee sjablone handhave, een voor de kop en de ander voor het blok of gaan we er nu een geheel van maken? Jcwf 15 feb 2012 20:50 (CET)
  • Wat ik bedoel voor te stellen is in plaats van {{-nlnoun-}} -> {{-noun-nl-}}. Momenteel lopen die twee posities van taalcodes door elkaar, bij het ene sjabloon staat het vooraan in de sjabloonnaam, bij de ander achteraan. Ik zou graag voor de taalcode één plek zien. Romaine 16 feb 2012 18:20 (CET)
• Mocht dit voorstel doorgaan... Voor taalspecifieke sjablonen lijkt het me overzichtelijker om de taalcode vooraan te zetten. Elke taal heeft zijn eigen eigenaardigheden en daarom ook een stel eigen sjablonen die andere talen niet zullen hebben. Ik pak zomaar wat sjablonen uit het Spaans:
  • {{-esverb-ar-}}
  • {{-esverb-ar-1-}}
  • {{-esverb-ar-2-}}

De opbouw van sjabloonnamen blijft logischer als je (van groot naar klein) eerst de taal noemt, dan de woordsoort, dan de subgroep van de woordsoort, dus bijv. {spa-verb-ar-1}. Dit heeft ook als voordeel dat je alle sjablonen voor een bepaalde taal kunt terugvinden door op voorvoegsel te zoeken. (Zoeken op voorvoegesl "verb-ar-1" heeft geen enkel nut, aangezien Spaans waarschijnlijk de enige taal is die dit sjabloon heeft.) Anders gezegd, het achteraan zetten van de taalcode zou ik een enorme verslechtering vinden van wat we nu hebben. Mocht dit wijzigen, dan graag de taalcode vooraan houden. -- Curious 16 feb 2012 23:21 (CET)

Voorstel 7

Aan de sjablonen -noun-, -adverb-, -prep-, -verb- een parameter toevoegen die het mogelijk maakt koppen (en categorieën) toe te voegen als Naamwoordelijke uitdrukking, Bijwoordelijke uitdrukking, Werkwoordelijke uitdrukking etc.

Motivering. M.i. zijn er zaken die niet onder de huidige koppen te plaatsen zijn omdat zij uit meer dan één woord bestaan, maar wel een vaste betekenis en rol in de taal hebben. Een goed voorbeeld is het Franse il y a. Het is soms een voorzetseluitdrukking in bijvoorbeeld La France d'il y a dix ans, het Frankrijk van tien jaar geleden (en wordt ook op fr.wikti als zodanig geanalyseerd). Soms is het een predicaat dat "er is" betekent: "Il y deux arbres", er staan twee bomen. Een werkwoordelijke uitdrukking dus. Ook het Nederlands heeft zat voorbeelden, bijvoorbeeld omwille van is een voorzetseluitdrukking en het woord omwille komt alleen in deze uitdrukking voor.

Jcwf 21 feb 2012 03:13 (CET)

Ik zou liever gewoon aparte sjablonen zien als -noun-expr-, -adverb-expr-, -verb-expr- ofzoiets. --Ooswesthoesbes 21 feb 2012 14:44 (CET)

Dan lijkt het voorstel van Jcwf mij iets economischer (al sluit die discussie aan bij wat Romaine beoogt met haar voorstellen). Wikibelgiaan 21 feb 2012 16:43 (CET)

Ik vermoed dat het handiger is om er een apart sjabloon voor aan te maken, zoals Ooswesthoesbes suggereert. Ik denk dat dat zeker handig is wanneer er door middel van dit sjabloon een andere categorie ingevoegd wordt dan dat -noun-, -adverb-, -prep-, -verb- invoegen. Romaine 21 feb 2012 19:13 (CET)

Goed idee om dit soort uitdrukkingen als zodanig te benoemen. Zowel aparte sjablonen als een extra parameter in sjablonen als -noun-, -verb- vind ik best. (Misschien zijn aparte sjablonen wel makkelijker te begrijpen voor de nieuwste gebruikers?) -- Curious 21 feb 2012 22:11 (CET)

Het grote nadeel van een paramter is dat iedereen misschien andere namen gaat hanteren en verder is typefouten kan leiden die misschien niet opgevallen worden. --Ooswesthoesbes 22 feb 2012 09:32 (CET)

Pagina's als 4

Weet iemand hoe je een getal met een streep erboven in een paginatitel kunt krijgen? In kristallografie hebben dat soort symbolen een specifieke betekenis (een viertallige inversieas) Jcwf (overleg) 2 mrt 2012 04:31 (CET)

Er zijn wel combinerende overlijnen zoals U+0305 maar dat geeft zoiets als ̅33̅.

Met een gecombineerd teken werkt goed, zie ook sv:o̲. --Ooswesthoesbes (overleg) 2 mrt 2012 16:39 (CET)

Met de overlijn krijg ik het niet voor elkaar Jcwf (overleg) 3 mrt 2012 01:52 (CET)

Precies erboven op lukt niet, maar ongeveer gaat wel: 4̅. --Ooswesthoesbes (overleg) 3 mrt 2012 11:59 (CET)

Dan zal ik dat maar gebruiken, maar het lijkt me dat er hetzij op wikimedia hetzij op unicode enig schoon werk te doen valt. Jcwf (overleg) 4 mrt 2012 19:05 (CET)

Dit zal unicode moeten oplossen, maar dat zal niet erg snel gebeuren aangezien ze eerst nog een tientallen buitenlandse schriften zoals Tulu moeten toevoegen... --Ooswesthoesbes (overleg) 4 mrt 2012 19:08 (CET)

Verdelingsgetal

Ik snap niet wat een verdelingsgetal is of wanneer/hoe het gebruikt wordt. Verdelingsgetallen hebben we op dit project alleen in het Latijn, maar uit hoe het daar beschreven wordt kom ik er niet echt uit wat er precies mee bedoelt wordt. Bijvoorbeeld undeni: telkens elf -> wanneer gebruiken we dat? In welk zinsverband wordt zoiets bijvoorbeeld toegepast. Heeft iemand een idee? Kan iemand een voorbeeld geven? Dank! Romaine (overleg) 2 mrt 2012 19:21 (CET)

Een Latijns voorbeeld zou ik niet weten, is Turks ook goed? Bijv.:

• Çocuklara iki elma verdi.
  • Hij gaf de kinderen twee appels. (= in totaal 2 appels voor alle kinderen samen)
• Çocuklara ikişer elma verdi.
  • Hij gaf de kinderen elk twee appels. (= elk kind krijgt 2 appels)

In het tweede voorbeeld is ikişer een verdelingsgetal, of distributief. Bij het verdelen wordt er uitgedeeld per twee tegelijk. -- Curious (overleg) 2 mrt 2012 21:43 (CET)

Curious heeft gelijk; de situatie in het Turks is blijkbaar net dezelfde als in het Latijn. Om toch een Latijns voorbeeld te geven:

• Pueris mala duo dedit.
• Hij gaf de kinderen twee appels.
• Pueris mala bina dedit.
• Hij gaf de kinderen elk/telkens twee appels.

De vertaling met "telkens" is degene die in alle woordenboeken wordt gehanteerd. Wikibelgiaan (overleg) 3 mrt 2012 17:47 (CET)

Rare jongens, die Romeinen en Turken. Zal wel door die olijfolie komen. Jcwf (overleg) 3 mrt 2012 18:02 (CET)

In het Nederlands kan het redelijk makkelijk zijn om "telkens" te omzeilen: Hij gaf beide kinderen twee appels i.t.t. Hij gaf de kinderen twee appels. In plaats van het telwoord te veranderen, veranderen wij het lidwoord. --Ooswesthoesbes (overleg) 3 mrt 2012 18:09 (CET)

Dank allen! Ik heb met deze informatie verdelingsgetal aangemaakt en ik zag dat Jcwf WikiWoordenboek:Verdelingsgetal aangemaakt heeft. Mooi project zo! :-) Romaine (overleg) 3 mrt 2012 22:26 (CET)

Wow! :) Curious (overleg) 4 mrt 2012 23:20 (CET)

Weghalen telling wel degelijk invloed op paginatelling

Alhowel in de statistieken geen verandering te zien is worden pagina's niet meer geteld door verschillende bot-genereerde bronnen zoals Wikistats, aangezien deze "minstens één interne link" als maatstaf voor artikelen nemen. Concreet betekent dit dat alle pagina's zonder interwiki niet meer meetellen in deze statistieken. --Ooswesthoesbes (overleg) 3 mrt 2012 16:13 (CET)

Ja. Daarover had ik al enig e-mailcontact met Zachte, maar ik weet niet of er verandering in gaat komen. Jcwf (overleg) 3 mrt 2012 17:14 (CET)

@Ooswesthoesbes: een interwiki is in het normale taalgebruik niet gelijk aan een interne link, maar is een interwiki een link naar een ander project (vaak in de Sidebar onderaan). Je bedoelt dus denk ik dat er pagina's zonder (interne) link niet meer meetellen in deze statistieken. Interwiki's hebben nooit meegeteld voor statistieken.

@algemeen: ik denk overigens dat we veel meer zouden moeten linken, zodat als woorden op een pagina onduidelijk zijn direct aanklikbaar opgezocht kunnen worden wat ze betekenen. Romaine (overleg) 3 mrt 2012 22:39 (CET)

..Interwiki's hebben nooit meegeteld voor statistieken... Eh, dat is niet waar hoor. Een iw bevat dubbele haken en daarop werd geteld.

Meer linken is natuurlijk prachtig, maar op lemmata met woordvormen is dat niet altijd mogelijk of zelfs maar nuttig. Jcwf (overleg) 3 mrt 2012 22:55 (CET)

Precies, strict genomen noemen we het geen interne links, maar een autogenereerde programma neemt die definitie niet mee "[[" betekent interne link volgens haar.

Linken kan inderdaad op pagina's met een hoofddefinitie (en dat wordt mijns inziens veel te min gedaan), maar op vervoegingspagina's is het met het sjablonensysteem dat gehanteerd wordt op nl.wikt niet mogelijk, tenzij je anagrammen of gelijke vormen ("ge waart" bij "je was" bv.) gaat noteren. --Ooswesthoesbes (overleg) 4 mrt 2012 10:52 (CET)

class=infoboxlinks in sjabloon:hierotable

Om een of andere reden genereert infoboxlinks een hele zooi kadertjes om hiërogliefen gegenereerd met WikiHiero tags. Ik heb het voorlopig weer teruggezet naar de oude syntax, maar dat geeft wel weer rare lijntjes. Jcwf (overleg) 3 mrt 2012 17:59 (CET)

Ik zie geen oplossing. Die hiero-extensie genereert nogal wat (m.i. overbodige en rare) HTML-code die voor problemen zorgt en waar waar ik niet rond kan werken. Annabel_(overleg) 3 mrt 2012 22:34 (CET)

auw. Nou ja, dan moeten we de oude syntax maar handhaven, dikke lijntjes incluis. Misschien even melden bij de WikiMedia mensen?

Bedankt voor de poging Annabel. Jcwf (overleg) 3 mrt 2012 22:57 (CET)

yel en yell

Hebben we een sjabloon om lezers attent te maken op beide vormen? --Ooswesthoesbes (overleg) 4 mrt 2012 15:37 (CET)

Bedoel je zoiets als sjabloon {{zie-ook}}? -- Curious (overleg) 4 mrt 2012 15:51 (CET)

Waarschijnlijk wel :) --Ooswesthoesbes (overleg) 4 mrt 2012 16:04 (CET)

Nog een lastige: / als pagina

Is er een manier om een pagina aan te maken met / als titel? Het is een symbool in de kristallografische notatie (en een hoop andere dingen) kunnen we een ampersand-notatie gebruiken? Kaal gaat niet want dan krijg je een subpagina. Jcwf (overleg) 4 mrt 2012 19:42 (CET)

Dat is onmogelijk i.v.m. wiki-software. Andere wiki's gebruiken daar speciale pagina's, zie bv. sv:Övriga tecken. --Ooswesthoesbes (overleg) 4 mrt 2012 19:55 (CET)

Ik zie nu neet dat de scheve streep nog wel gaat, maar als we dus pagina's als [ willen aanmaken, zal dat anders moeten. --Ooswesthoesbes (overleg) 4 mrt 2012 19:56 (CET)

Ja, met ampersand #47; gaat dit nog wel; andere symbolen kan best wel eens lastig worden. Jcwf (overleg) 4 mrt 2012 20:24 (CET)

Gelijk uiterlijk toch verschil?

Heeft er iemand een idee wat het verschil is tussen µ en μ. Ze lijken er hetzelfde uit te zien, maar zijn toch verschillend? Welke is de Griekse en wat is dan de andere letter? Romaine (overleg) 4 mrt 2012 21:36 (CET)

U+00B5: micro sign µ

U+03BC: Griekse letter mu μ

Heel vervelend die unicodejongens... Jcwf (overleg) 4 mrt 2012 23:56 (CET)

Als ik me niet vergis staat microteken gewoon op het VS-toetsenbord onder alt+m: µ. --Ooswesthoesbes (overleg) 5 mrt 2012 09:53 (CET)

Survey invitation

First, I apologize that part of this message is in English. If you can assist by translating it for your local community, I would greatly appreciate it.

The Wikimedia Foundation would like to invite you to take part in a brief survey.

Met dit onderzoek hoopt de Wikimedia Foundation uit te vinden welke middelen Wikimedianen willen en nodig hebben (in sommige gevallen is er financiering nodig), en welke prioriteit ze daaraan willen geven. Dit onderzoek gaat niet over alle programma's van de Wikimedia Foundation - kernactiviteiten worden uitdrukkelijk uitgesloten - maar alleen over middelen die individuele gemeenschapsleden of aan Wikimedia gerelateerde organisaties, zoals chapters, zouden kunnen vragen.

Het doel hier is om te bepalen waarin u (of groepen zoals chapters en clubs) geïnteresseerd bent door de mogelijkheden op voorkeur te rangschikken. We hebben in deze lijst dingen als "houd de servers draaiende" niet opgenomen, omdat individuele gemeenschapsleden of vrijwilligersorganisaties hiervoor niet verantwoordelijk zijn. Deze vragenlijst is bedoeld om uit te vinden over welke financieringsprioriteiten gemeenschapsleden het eens zijn en niet eens zijn.

To read more about the survey, and to take part, please visit the survey page. You may select the language in which to take the survey with the pull-down menu at the top.

This invitation is being sent only to those projects where the survey has been translated in full or in majority into your language. It is, however, open to any contributor from any project. Please feel free to share the link with other Wikimedians and to invite their participation.

If you have any questions for me, please address them to my talk page, since I won’t be able to keep an eye at every point where I place the notice.

Thank you! --Mdennis (WMF) (overleg) 5 mrt 2012 22:45 (CET)

Yasser Arafat

Verplaatste discussie:

Tja willen we dit eigenlijk wel? Een algemene naam als Yasser of Henk or zo lijkt me wel lexicografisch te noemen maar dit is toch eerder encyclopedisch denk ik. Jcwf 31 okt 2011 06:12 (CET)

Nee, Yasser kan, Arafat zou eventueel kunnen en mischien als we het echt niet omheen kunnen Yasser Arafat onder "Arafat" vernoemen. Deze pagina moet i.e.g. weg. --Ooswesthoesbes 31 okt 2011 06:53 (CET)

Dit is inderdaad niet voor een woordenboek. Annabel_(overleg) 31 okt 2011 08:09 (CET)

Just with foreign names people have spelling problems and there are different spellings in different langauges. This is a spelling problem not a lexigraphic one. So human names should not generally become banned from the dictionaries. With first names, like John, Frans or Maria we see no problems in the Dutch dictionary, so we can take Yasser (how OWHB says) and give "Yasser Arafat" as a example into this article. In this we as well can cover the spelling of from human names derived street or other names like "Yasser Arafat Street", "Goethestraat", Konrad-Adenauer-Flughafen or "Luchthaven Parijs-Charles de Gaulle". -- Cadfaell 31 okt 2011 09:51 (CET)

Which you then describe in an encyclopedia ... Annabel_(overleg) 31 okt 2011 10:01 (CET)

I'm writing here about the spelling of names, not about a lexigraphic description. Spelling is the task of the dictionaries. We have the lemma Frans, why shouldn't we build a) a lemma with Yasser and b) put "Yasser Arafat" as example in it? -- Cadfaell 31 okt 2011 13:27 (CET)

Like I said, this spelling issue with different spelling for a single name is something for an encyclopedia discussing a single person. In a dictonary, you describe transliteration in general (so not only for names, but all words in general). You do not have entries for all names, nor for people's names. There are etymological dictionaries though describing the origin of a name, but that is not the case here. This (case) is about something else. Annabel_(overleg) 31 okt 2011 16:57 (CET)

There is a principal difference between this Dutch Dictionary and an encyclopedia. In this dictionary we have many language parts (nld-nld / nld-eng / nld-deu, nld-nor ...) with many words in many languages. An encyclopedia normally is only written in one language. So it is a normal situation that we find in this dictionary a word in many variations in different languages (water - Wasser - vann - vatn - eau ...). The name Yasser, too, has different forms in different languages: spa: Yasir / deu: Jassir / nor: Yasir ... I cannot see a reason not to build lemmas in this Duch Dictionary for this first name in different languages. With Frans and Franz and others we do the same. -- Cadfaell 31 okt 2011 17:32 (CET)

(Sorry, ik ben te lui om in het Engels te schrijven.. ) Er zijn hier denk ik verschillende vragen:

1. Willen we een pagina "Yasser Arafat"?
2. Willen we een pagina "Yasser"?
3. Willen we een pagina "Arafat"?
4. Als 2 en/of 3 ja is, is op die pagina een voorbeeld met "Yasser Arafat" dan gewenst?

Persoonlijk zou ik zeggen: 1) nee; 2) ja, mag; 3) twijfel; 4) maakt me niet uit. En jullie? Curious 31 okt 2011 20:13 (CET)

Volgens mij: 1) nee; 2) ja; 3) nee; 4) ja; of voor twee andere gevallen: "Koningin Beatrixstraat" als mogelijk voorbeeld voor Beatrix of Konrad-Adenauer-Flughafen als mogelijk voorbeeld voor Konrad ). -- Cadfaell 31 okt 2011 21:52 (CET)

Ik ben het met Curious eens, maar ik zou geen geografische termen als voorbeeld nemen. De voorbeelden dienen juist om aan te geven hoe het woord in een zin gebruikt wordt en bij een geografische naam is het woord meestal weggestopt in een groter geheel. --Ooswesthoesbes 1 nov 2011 06:56 (CET)

Wat mij betreft 1) Nee, 2 Ja, alleen etymologisch en 3) Ja, alleen etymologisch. Annabel_(overleg) 1 nov 2011 08:47 (CET)

1) Nee, 2+3) Misschien deze wel, maar niet voor alle namen die ooit verzonnen zijn - Difool 2 nov 2011 01:34 (CET)

Dus...

Het lijkt dat we hierboven toch wel aardig tot de consensus zijn gekomen dat deze pagina weg kan. Misschien kan een administrator ons hierbij helpen? :) Een klein verzoekje: ik zou graag de discussie willen behouden, misschien kunnen we die ergens in de WikiWoordenboek-naamruimte kwijt. --Ooswesthoesbes (overleg) 9 mrt 2012 13:19 (CET)

Nog even over die voornamen: ik snap dat die in een gewoon woordenboek niet staan. Maar stel je deze situatie even voor: iemand leest een Italiaans artikel zonder perfect Italiaans te begrijpen. Is die persoon er dan niet bij gebaat als hij kan opzoeken dat "Girolamo" gewoon Hiëronymus is? Wikibelgiaan (overleg) 9 mrt 2012 19:01 (CET)

Ik ben er ook helemaal voor om (veel voorkomende) voornamen gewoon op te nemen met alles d'r op en d'r aan. --Ooswesthoesbes (overleg) 10 mrt 2012 12:35 (CET)

Ik ben het in deze geheel eens met Annabel en Ooswesthoesbest. Voor het beschrijven van bekende personen is er al een ander wikiproject, namelijk wikipedia. Wikiwoordenboek heeft daarentegen zijn eigen functie, en het einde is anders immers in feite zoek op deze manier. Wikiwoordfanaat (overleg) 10 mrt 2012 16:00 (CET)

You rule

Hope you like it: In praise of Wiktionary. --Amir E. Aharoni (overleg) 24 mrt 2012 16:59 (CET)

Thanks Amir, I'm glad you find us useful. It is in part with people like you in mind that we do all this and it is good to know it is finding use. I completely agree that the wiki software was not as suitable for writing a dictionary, which explains the heavy reliance on a plethora of templates and categories. That does have the advantage that we can shape our environment to our needs as we go along, but yes it would be nice if the developers would take notice of our specific needs and our experiences a bit more. An example: it is pretty cumbersome to use the search button for things like categories or templates. It is really necessary to have to prefix template:xxx or category:xxx all the time or could there be a tick box underneath or so? Jcwf (overleg) 24 mrt 2012 19:12 (CET)

Voorstel sitenotice

Ik denk dat we de hulp van bezoekers heel goed kunnen gebruiken. Ik wil daarom voorstellen om een permanente annon/sitenotice bovenaan pagina's te plaatsen met een oproep om fouten, ontbrekingen, onvolledigheden en alternatieve betekenissen, enzovoorts te melden. Ik denk dat de voordelen, kwaliteitverbetering, ruimschoots opwegen tegen het één keer wegklikken voor wie het niet wil zien. We moeten dan wel enkele keuzes maken:

• Alleen voor anonieme gebruikers of ook voor geregistreerde gebruikers?
• Naar welke pagina linken we waar gebruikers het kunnen melden?

Reacties graag! Romaine (overleg) 30 mrt 2012 21:03 (CEST)

Voor anoniemen lijkt me dat wel nuttig. Het Engelse net heeft zoiets in de linkerbalk als je niet ingelogd bent. Ik heb geen idee waar de info heengaat als je daar als anon commentaar levert. Een site notice kan ook, maar je wilt wel de mogelijkheid behouden bij bijzondere gebeurtenissen daar een mededeling te kunnen plaatsen, lijkt me. Jcwf (overleg) 31 mrt 2012 04:40 (CEST)

Er zou misschien een pagina WikiWoordenboek:Feedback aangemaakt kunnen worden. De al bestaande WikiWoordenboek:Helpdesk kan misschien ook wel, of anders linken naar de overlegpagina van de desbetreffende pagina? Als de oproep tot feedback in de vorm van een annon/sitenotice bovenaan de pagina komt, dan graag iets sobers, een grote oproep kan misschien al snel als schreeuwerig of irritant worden ervaren, denk ik. Een link in de linker zijbalk is m.i. in ieder geval nuttig. Als iemand daarvoor de kennis in huis heeft om het te maken, is een feedbacksysteem als bij de Engelsen natuurlijk ook helemaal goed. -- Curious (overleg) 31 mrt 2012 21:49 (CEST)

Onvoledige werkwoorden

Er zijn een heel stel werkwoorden, voornamelijk ontstaan door samenstelling, bijvoorbeeld koppensnellen, discuswerpen die niet altijd een volledig stel vormen hebben. Welke vormen er wel en welke niet gebruikt worden verschilt van werkwoord tot werkwoord. Meestal is het in het begin alleen een onbepaalde wijs. Eerst als naamwoord, later ook in bijvoorbeeld de toekomende tijd. Soms ontstaan er dan een scheidbare "te" vorm, zoals "Koppen te snellen" Soms komen er scheidbare vormen naast onscheidbare voor. In bijzinnen verschijnen er dan eerder vervoegde vormen dan in hoofdzinnen. Scheidbare vervoegde vormen in hoofdzinnen lijken het laatste te ontstaan. Hoe ver dit proces voortgeschreden is verschilt van werkwoord tot werkwoord.

Het lijkt me dat een woordenboek weer hoort te geven hoe het er onder de taalgebruiker mee staat en niet via een vervoegingssjabloon net doen alsof alle vormen bestaan. Er zijn echter een heel stel van dat soort tabellen aangemaakt. Ik wel best uitzoeken wat daar mee moet, maar niet als er via een bot dan weer zo'n tabel neergepoot wordt. Jcwf (overleg) 31 mrt 2012 05:18 (CEST)

Misschien zouden bots/boteigenaren Categorie:Onvolledig werkwoord in het Nederlands kunnen overslaan. Een ander signaal voor overslaan kan gevonden worden in sjabloon {{-nlstam-}}, als daarin voorkomt "k=onv" of "{{nlonv}}". Als dat gewenst is voor bots, zouden we voortaan bijvoorbeeld ook expliciet zoiets als "nobot" kunnen vermelden. Misschien dat boteigenaren even kunnen melden wat het handigst werkt?

Bij deze trouwens ook mijn dank voor de botmatige aanmaak van pagina's (ww, zn, bn..), dat scheelt zo ontzettend veel handmatig werk! -- Curious (overleg) 22 apr 2012 15:49 (CEST)

Zover ik kan zien slaat mijn bot onvolledige en onregelmatige werkwoorden over, dus in dit geval zullen verwijderde vervoegingen niet opnieuw worden aangemaakt. Een expliciete nobot flag is inderdaad misschien een idee, al vind ik dat eigenlijk al duidelijk zou moeten zijn dat er in deze gevallen niets zinnigs te genereren is. Difool (overleg) 22 apr 2012 23:45 (CEST)

agent noun

Weet iemand wat een agent noun (Wikipedia) in het Nederlands is? Romaine (overleg) 7 apr 2012 06:56 (CEST)

• Ik weet er geen oorspronkelijk Nederlands woord voor; "nomen agentis" is het gangbare begrip, dat ook in Van Dale staat. --MarcoSwart (overleg) 14 apr 2012 09:04 (CEST)
  • Lijkt me naast "nomen actionis" geen slechte kreet. Daar heb ik maar "naamwoord van handeling" van gemaakt. Jcwf (overleg) 14 apr 2012 21:21 (CEST)
    • Interessant! Hoe zou dan bijvoorbeeld de etymologiesectie gaan luiden van (ik noem maar wat) bakker of wandelaar? -- Curious (overleg) 14 apr 2012 23:09 (CEST)
      • Het enige alternatief van eigen bodem dat ik tegenkwam was "doenerwoord". Een beetje erg uit de klei getrokken misschien. Van mij mag het, maar ik kan me voorstellen dat er ook zijn die liever Latijn zien. "Naamwoord van handeling" werd overigens al in de 19e eeuw gebruikt. De etym zou zoiets worden als:

• {{nomen agentis}} van [[bakken]] {{suff|nld|-er}}.

Jcwf (overleg) 14 apr 2012 23:23 (CEST)

• Lastig, die naamgeving. De wikicode is wel handig. :) -- Curious (overleg) 15 apr 2012 00:01 (CEST)

nepgebruikers

Op het Engelse net lijkt het of er iemand botmatig nepgebruikers aan het aanmaken is. zie. Misschien moet er een captcha komen om dit te verhinderen? Jcwf (overleg) 14 apr 2012 21:21 (CEST)

Vragen van Kvrdgeus

Begin verplaatsing vanaf Overleg gebruiker:Wikiwoordfanaat

Afgelopen weekend heb ik systematisch wat aanpassingen gedaan in woorden die ik ooit had toegevoegd en zodoende de lay-out aangepast aan de manier zoals jullie dat doen. (of zoals ik denk dat jullie dit willen)
Het betreft hier de invoegingen, achtervoegsels en voorvoegsels.
Daarbij ben ik op wat problemen gestoten die ik hieronder zal aangeven:

invoegingen
http://nl.wiktionary.org/wiki/goederenstroom is de infix hier -eren- (bestaat nog niet) of is het goeder en stroom met het invoegsel -en- echter het enkelvoud van goederen is goed.

achtervoegsels
1. http://nl.wiktionary.org/wiki/Categorie:Achtervoegsel_-grafie_in_het_Nederlands heb ik toegevoegd maar is nog niet aanwezig bovenin bij:
http://nl.wiktionary.org/wiki/Categorie:Achtervoegsel_in_het_Nederlands 2. is de suffix correct bij: http://nl.wiktionary.org/wiki/rechtaan?
3. Ik wilde invoeren:
"Naamwoord van handeling" + achtervoegsel bij: flu•o•res•cen•tie
Naamwoord van handeling van fluoresceren {{suff|nld|-entie}} echter -entie bestaat niet dus dit zal wel onzin zijn.

graag toelichting

4. Vanochtend was ik aan het stoeien met het woord 'gram' en heb ik een derde betekenis toegevoegd. (zie http://nl.wiktionary.org/wiki/gram) Het kan zijn dat dit weer beter gedefinieerd kan worden als een achtervoegsel (net zoals 'graaf')

voorvoegsels
Ik zag wat mijns inziens onzinnige voorvoegsels:
zonne- is dit iets anders dan zon infix 'e' ?
kinder-
zeehonden-
milieu-
kalfs-
huis-
Verder heb ik 1 nieuw voorvoegsel ingevoerd te weten tele-

Bovendien heb ik gedacht aan de volgende nieuwe:
elektro-
chrono-
epi- woord epigram is van Griekse oorsprong (ἐπίγραμμα) en betekent letterlijk 'opschrift' dus epi = op

Verder zag ik dat video- en audio- niet meer als voorvoegsel aanwezig zijn. Het is mij niet erg duidelijk wanneer iets nu een voegsel is en wanneer niet. Tevens is het me onduidelijk wat voor soort woord dit nu is (zelfstandig nmw of bijv. naamwoord) en verder of video en audio nu wel of niet eigenschappen van een bijv. naamwoord hebben in samenstellingen zijnde:
audio geluids-
video beeld-

Groet, --Kvdrgeus (overleg) 18 apr 2012 11:38 (CEST)

Einde verplaatsing vanaf Overleg gebruiker:Wikiwoordfanaat

Bij goederenstroom is alvast helemaal geen sprake van een infix; goederen is een zogeheten stapelmeervoud en behoort tot dezelfde categorie meervouden als bijvoorbeeld kinderen en eieren (vgl. de Duitse vormen Güter, Eier, Kinder, waar het oorspronkelijke achtervoegsel nog duidelijk is). Verder is -entie (als in fluoresc-entie) ook geen echt bestaand achtervoegsel in het Nederlands. Het is een Latijns achtervoegsel, dat slechts in enkele in het Nederlands geleende woorden voorkomt (bijv. ook in adolescentie). Wikiwoordfanaat (overleg) 18 apr 2012 16:40 (CEST)

Lastige vragen, Kvdrgeus! Volgens mij hebben we nog niet zo heel veel afspraken over etymologie, vandaar dat niemand een pasklaar antwoord heeft...

Ik sluit me aan bij de opmerking over zonne-, kinder-, zeehonden-, milieu-, kalfs-, huis-: dit zijn m.i. geen voorvoegsels; de informatie op die pagina's kan denk ik beter verplaatst worden naar zon, kind, zeehond etc.

De etymologiesectie is nu een mix van twee dingen: 1) woordopbouw, en 2) woordherkomst. Bij een woord als telefoon zou je dat bijvoorbeeld kunnen beschrijven als:

• 1) Samenstelling van het voorvoegsel tele- met het achtervoegsel -foon. (=woordopbouw)
• 2) Van het Franse téléphone, gevormd uit het Griekse τῆλε (tele) en φωνή (foon). (=woordherkomst)

Tja, we gebruiken beide soorten omschrijvingen, soms het een, soms het ander... Als we het onszelf gemakkelijk willen maken, zouden we kunnen afspreken om in elk geval de woordopbouw (dus 1)) te beschrijven, dan komen alle woorden ook keurig in de juiste categorieën terecht (in dit voorbeeld, telefoon, dus in "Categorie:Voorvoegsel tele- in het Nederlands" en "Categorie:Achtervoegsel -foon in het Nederlands"). Als iemand daarnaast ook de woordherkomst (dus 2)) erbij wil zetten, zou dat denk ik een mooie aanvulling zijn.

Van de voorbeelden die Kvdrgeus hierboven noemt, zou ik (denk ik):

• tele-, elektro-, chrono-, epi-, video-, audio-: beschouwen als voorvoegsel,
• -gram, -graaf, -grafie, -scoop, -entie: beschouwen als achtervoegsel.

Wat vinden jullie? -- Curious (overleg) 24 apr 2012 20:30 (CEST)

Ik ben het met het meeste eens, alleen lijkt -entie me zoals gezegd geen bestaand Nederlands achtervoegsel. Dan zou het in principe namelijk ook productief moeten zijn, maar dat is het - voor zover ik weet - niet, ik ben het althans nog nooit zo tegengekomen. Wikiwoordfanaat (overleg) 24 apr 2012 22:08 (CEST)

tendentie, leverantie misschien? Difool (overleg) 24 apr 2012 22:28 (CEST)

Ik dacht aan woordkoppels als assisteren / assistentie, adverteren / advertentie, concurreren / concurrentie, refereren / referentie, corresponderen / correspondentie, maar misschien is dat geen juiste gedachte van me. Streep -entie in dat geval maar door. :) Curious (overleg) 24 apr 2012 22:57 (CEST)

Mijn kennis van de morfologie van het Nederlands schiet hier toch even te kort, helaas. Op het eerste gezicht zou ik zeggen dat dit gewoon allemaal (Romaanse) leenwoorden zijn die op dezelfde manier aan de fonotactiek van het Nederlands zijn aangepast. In ieder geval vind ik zo geen bronnen voor -entie als bestaand Nederlands achtervoegsel. Is er nog iemand anders in de zaal die wil opstaan? Wikiwoordfanaat (overleg) 26 apr 2012 20:11 (CEST)

etymologiebank.nl: assistentie zn. ‘hulp, bijstand’. Mnl. assistencie ‘id.’ [1488; MNW ontlastinge]. Al dan niet via Oudfrans assistence [1387; Rey] ontleend aan middeleeuws Latijn assistentia, afleiding van assistere

"assitentie" ist demnach eine Entlehnung aus dem Lateinischen, von "assistentia", das von "assistere" kommt. Nach meiner Meinung ist "assistentie" heute ein niederländisches Wort, das nach allgemeinen niederländischen Regeln zerlegt wird: assist- / -ere / -ent / -entie (= Suffixe). -- Cadfaell (overleg) 26 apr 2012 20:42 (CEST)

-> zonnebloem (en andere) Samenstelling van zon en bloem met het invoegsel -e- (tussen-e) en medeklinkerverdubbeling (regel 2.B).

zonnebloem is een samenstelling van het middeleeuwse Nederlandse woord "zonne" en het woord "bloem". De etymologie van zonne kan je vinden onder http://gtb.inl.nl/iWDB/search?actie=article&wdb=WNT&id=M089570. De moderne vorm van zonne is "zon". De samengestelte woorden met "zonne" hebben zich niet veranderd in een moderne vorm. Bij zonnebank heb ik het al gewijzigd. -- Cadfaell (overleg) 27 apr 2012 18:15 (CEST)

creëren

Dit woord krijgt altijd een grote lading treffers en dat is al heel lang zo. Enig idee waarom? Jcwf (overleg) 22 apr 2012 01:54 (CEST)

Gokje: de spelling? (hoeveel eeeee's? wel/geen trema? welke e krijgt de trema?) Lastig hoor: creëren - creëerde - gecreëerd... :) De vervoegingspagina wordt ook goed bekeken: [9] .

Leuke fluctuatie in de grafieken trouwens, je kunt precies zien wanneer het weekend is. :) -- Curious (overleg) 22 apr 2012 15:27 (CEST)

Roemeense letters

Zie hier: Overleg:braț . Ik denk dat ik ze maar allemaal ga omzetten dan. Dus:

• ţ > ț
• ş > ș -- Curious (overleg) 1 mei 2012 22:01 (CEST)

Achtervoegsel -iseren

Ik heb me de afgelopen dagen bezig gehouden met het voorvoegsel de- en kom nu op een achtervoegselprobleem.

voorbeeld: de etymologie van deactiveren is nu als volgt gedefinieerd:
afgeleid van actief met het voorvoegsel de- met het achtervoegsel -eren
Dit kan ik begrijpen.

lastiger wordt het met de volgende woorden:
decentraliseren en centraliseren
afgeleid van centraal met het voorvoegsel de- en met het achtervoegsel -eren
moet dit niet zijn -iseren ? hetzelfde geldt voor:
demagnetiseren en magnetiseren
destaliniseren en staliniseren
alfabetiseren
minimaliseren
mobiliseren
totaliseren
verbaliseren
Het achtervoegsel -iseren tref ik echter niet aan in de lijst op http://nl.wiktionary.org/wiki/Categorie:Achtervoegsel_in_het_Nederlands Ik heb inmiddels gemerkt dat deze woorden uit het Frans afkomstig zijn en daarmee kom ik op het volgende:
voor het woord 'monteren' heb ik momenteel staan:

*afgeleid van het Franse [[monter]] {{suff|nld|-eren}}  <br>

Bij de etymologie van 'demonteren' staat momenteel

*afgeleid van het Franse [[monter]] {{pref|nld|de-}} en {{suff|nld|-eren}}      <br>

en bij 'demontering' staat:

*{{nomact}} van [[monteren]] {{pref|nld|de-}} en {{suff|nld|-ing}}      <br>

de woorden zoals 'decentraliseren' zijn nu geen probleem meer want dat wordt:

*afgeleid van het Franse [[centraliser]] {{pref|nld|de-}} en {{suff|nld|-eren}} <br>

graag commentaar --Kvdrgeus (overleg) 5 mei 2012 23:26 (CEST) Het lijkt me dat je best een cat -iseren kunt aanmaken. Of dat nu op het Frans teruggaat of eigenlijk op Latijn -isare is denk ik minder van belang. Misschien is de kreet "opgebouwd uit" beter dan "afgeleid uit" in dit soort gevallen, omdat dat naar de structuur ipv de historische etymologie verwijst. Jcwf (overleg) 6 mei 2012 19:15 (CEST)

oen

Er is iets raars met dit woord. Ik heb er wat wijzigingen in aangebracht en nu kan het systeem het lemma niet terugvinden.. Jcwf (overleg) 6 mei 2012 19:10 (CEST)

Oh, nu weer wel... Wat raar!

Achtervoegsel -eren

Hallo,

Ik heb afgelopen weekend wat gerommeld met de uitgang -eren voor zover die gerelateerd is aan Franse werkwoorden. Dit heeft geresulteerd in het onder ' Afgeleide begrippen' staande aantal werkwoorden (ongeveer 1250 stuks) bij http://nl.wiktionary.org/wiki/-eren Het is duidelijk dat nog niet bij alle werkwoorden de juiste -etym- staat bv. bij 'abandonneren' staat nog niet

{{-etym-}}
*afgeleid van het [[Frans]]e [[abandonner]] {{suff|nld|-eren}} <ref>[http://www.etymologiebank.nl/trefwoord/abandonneren etymologiebank.nl]</ref>

Ik weet niet of iemand zich geroepen voelt om dit af te ronden. Ik heb zelf maar een beperkte hoeveelheid tijd en heb me al voorgenomen om de uitgangen -graaf, -grafie, -loog, -logie, -scoop, -scopie af te maken.

In principe kan ik het volgende aanleveren: Een file met de opmaak van deze werkwoorden die zó is voorgekookt dat een woord met slechts kleine aanpassingen kan worden ingevoerd of aangepast. Ook kun je alleen een file krijgen waarin de Franse woorden staan waarvan IK denk dat die zo zouden moeten zijn. (let wel, die lijst is automatisch vervaardigd)

Verder was ik van plan om vanaf nu steeds een verwijzing naar www.etymologiebank.nl aan te brengen als die voor dat woord bestaat. Dit heb ik reeds gedaan bij bv. http://nl.wiktionary.org/wiki/adresseren

Als iemand van mening is dat bij http://nl.wiktionary.org/wiki/-eren nog meer woorden horen of dat er woorden opstaan die er niet horen zou het prettig zijn dit even aan mij door te geven dan kan ik wat bestanden aanpassen. (Je kunt natuurlijk ook gewoon alles weghalen)

Wie trouwens behoefte heeft aan een wat ongewone vraag die de behandeling van veel gegevens vereist, kan altijd contact met me opnemen. Ik beschik o.a. over alles wat op http://woordenlijst.org staat en kan makkelijk een programma maken om hieruit iets te selecteren. Groet, --Kvdrgeus (overleg) 9 mei 2012 17:08 (CEST)

Voorstel: Sjabloon:etymologiebank & Sjabloon:RAE

Toen ik bezig was met het aanbrengen van de verwijzingen realiseerde ik me trouwens dat het veel beter is om dit anders te realiseren. Op dit moment wordt er een referentie geplaatst die ook nog eens voor ieder woord hetzelfde is en de volgende inhoud heeft:

<ref>[http://www.etymologiebank.nl/trefwoord/{{pn}} etymologiebank.nl]</ref>

Een bezwaar hiervan is dat e.e.a. de mist ingaat als ooit de www.etymologiebank.nl verdwijnt of verhuist. Alle duizenden verwijzingen in de webpagina's zijn dan waardeloos geworden. Als we dit probleem oplossen met één of andere macro Sjabloon:etymologiebank is dit probleem verdwenen. Deze macro compileert steeds de op dat moment geldige verwijzing in de webpagina´s. Verandert er ooit wat, hoeven de pagina´s alleen te worden gerecompileerd. Ook als het instituut geheel verdwijnt is er geen probleem de Sjabloon:etymologiebank wordt dan door het systeem genegeerd. Hetzelfde speelt bij http://nl.wiktionary.org/wiki/índice waar een verwijzing aanwezig is als volgt:

{{refs}}
* [[w:Real Academia Espanõla|Real Academia Espanõla]], ''[http://buscon.rae.es/draeI/SrvltGUIBusUsual?LEMA={{pn}} Diccionario de la lengua española - Vigésima segunda edición]''

Ook hier geldt dat bij verandering alle referenties waardeloos zijn dus stel ik voor om een macro Sjabloon:RAE te definiëren.

Misschien zijn er meer plekken waar dit principe kan worden toegepast. Het gaat hierom om zeer veel verwijzingen naar dezelfde plek (een ander woordenboek etc.)

Groet --Kvdrgeus (overleg) 10 mei 2012 19:54 (CEST)

Op zich een goed idee K., maar ik vraag me af hoe het met de auteursrechten zit. Naar oude woordenboeken kunnen we met gerust hart verwijzen, maar naar Van Dale lijkt me niet bepaald zo'n goed idee. Ik kijk daar eerlijk gezegd ook nooit in omdat het geen vrije bron is. Met etymologiebank is dat natuurlijk ook zo, maar zij zijn geen woordenboek, zoals WikiWoordenboek en Van Dale wél zijn. Wat dat betreft heeft Van Dale natuurlijk alle reden om met argusogen te kijken of wij geen plagiaat plegen. Hun definities overnemen moeten we vooral niet doen. (Verzin ze dus zelf!) Jcwf (overleg) 24 mei 2012 02:05 (CEST)

---

Berichtje van de zuidoosterburen

Na efkes een inhaalslag gedaan te hebben is een belangrijke mijlpaal gehaald op li.wikt. vach is ons 100.000e artikel! :) --Ooswesthoesbes (overleg) 19 mei 2012 14:38 (CEST)

Proficiat! Op naar de 200k! - Warddr (overleg) 19 mei 2012 18:55 (CEST)

Gefeliciteerd OWTB. Wat een prestatie in je eentje! -- Curious (overleg) 20 mei 2012 20:15 (CEST)

Bedankt :) Ik wil niet helemaal met de eer strijken è, ik heb slechts 80.000 pagina's op m'n naam staan ;) --Ooswesthoesbes (overleg) 20 mei 2012 21:03 (CEST)

Gefeliciteerd OWTB Jcwf (overleg) 24 mei 2012 01:57 (CEST)

Mal berichtje

Waar komt eigenlijk dat malle berichtje "Op deze pagina kunt u de recentste wijzigingen in deze wiki bekijken. " vandaan dat nu bovenaan de pagina met de recente wijzigingen prijkt? Het lijkt me wat overbodig maar ik weet niet waar het gegenereerd wordt. Jcwf (overleg) 24 mei 2012 01:57 (CEST)

Via MediaWiki:Recentchanges-summary, ik heb hem nu leeggemaakt. Romaine (overleg) 24 mei 2012 21:38 (CEST)

Interwiki's en Oudgrieks

Zou het kunnen dat geen enkel interwiki-botje omkan met Oudgrieks? Het lijkt erop dat die interwiki's (bijvoorbeeld voor ἀξία) nooit aangemaakt worden en alles handmatig doen is nu niet bepaald handig. Wikibelgiaan (overleg) 24 mei 2012 16:42 (CEST)

Hmm, heeft dat te maken met accenten en spiritus? Anders zou ik het niet weten. Hebben de Grieken hier geen ervaring mee? Lou of zo? Jcwf (overleg) 24 mei 2012 20:10 (CEST)

Sjabloon:-info dp-

{{-info dp-}} schijnt opeens niet meer te werken, net als het sjabloon {{Tl|-info dp-|W=AlternatievePagina}}. Kan iemand hier eens naar kijken? Wikiwoordfanaat (overleg) 25 mei 2012 09:58 (CEST)

Zo te zien heb je het zelf al opgelost. :) -- Curious (overleg) 25 mei 2012 22:58 (CEST)

Drie plaatsen gestegen op minder dan een maand

Voor de mensen die graag al eens wat statistieken zien, in mei zijn hier meer dan 10 000 artikels aangemaakt [10], en zijn we van de 20e naar de 17e plaats gegaan in de lijst van wiki woordenboeken volgens aantal goede pagina's. Proficiat! - Warddr (overleg) 25 mei 2012 15:22 (CEST)

Het gaat erg hard tegenwoordig. Waar is de tijd gebleven dat we na een heeele tijd dan eindelijk weer eens de volgende 10.000 gingen vieren? :) Gefeliciteerd allen! -- Curious (overleg) 25 mei 2012 23:03 (CEST)

Gefeliciteerd :) Hopelijk krijgen we li.wikt volgende maand weer terug op plaats 25, waar hij vroeger ook stond :) --Ooswesthoesbes (overleg) 28 mei 2012 09:16 (CEST)