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