WikiWoordenboek:De Kroeg/archief18

125k

Proficiat! Music maestro! Annabel_(overleg) 18 sep 2011 11:25 (CEST)

PS: nummer 125k is door Jcwf aangemaakt en is teurel‎. Annabel_(overleg) 18 sep 2011 11:28 (CEST)

Jippiiieeej! :) Curious 18 sep 2011 16:40 (CEST)

Gefeliciteerd! Wat een typisch woord trouwens. Klinkt ook een beetje als een Nederlands woord, een soort logatoom. Wikiwoordfanaat 18 sep 2011 16:52 (CEST)

Gefeliciteerd :) --Ooswesthoesbes 19 sep 2011 09:29 (CEST)

Uitspraak Noord-Nederland

Ik heb een paar woordjes waar ik al gelange tijd over de Noordse uitspraak twijfel. Deze woorden zijn vaak hier een beetje buiten de spelling gevallen en daarom weet ik niet precies hoe de situatie er bij jullie voorstaat. Enkel voorbeelden met Limburgse uitspraak en gegokte Noordse uitspraak d'rachteraan:

• bugel: /ˈbyː.ɣəl/ (N: /ˈby.χɔɫ/)
• communie: /kɔ.ˈmyː.nɪə̯/ (N: /kɔ.ˈmy.ni/)
• familie: /fa.ˈmiː.lɪ̯ə/ (N: /fɑ.ˈmi.li/)
• fanfare: /foɱ.ˈfaːr/ (N: /fɑɱ.ˈfa.rə/)
• kastdeur: /kəz.ˈdøːr/ (N: /ˈkɑst.dʏːr/)
• meubilair: /ˌmøː.by.ˈlæːr/ (N: /ˌmøː.bi.ˈlæːr/)
• minuscuul: /ˌmɪ.ny.ˈskyl/ (N: /ˌmi.ny.ˈskyɫ/)
• slijtage/bagage/etc: /ˈslɛɪ̯.taːʃ/ - /ba.ˈɣaːʃ/ (/ˈslɛɪ̯.ta.ʒə/ - /ˈbɑ.χa.ʒə/)

Als iemand deze Noordse even kan controleren, dan kunnen we ze toevoegen bij de woordenpagina's :) --Ooswesthoesbes 20 sep 2011 15:55 (CEST)

Spreektaal?

Hallo iedereen,

Het is weer een tijdje geleden sinds ik hier nog actief was, maar ik heb een klein vraagje. Onlangs wilde ik in een bepaalde situatie het woord "inpakken" gebruiken. In Vlaanderen heeft "inpakken" in de spreektaal een tweede betekenis naast iets in folie/inpakpapier te wikkelen. Kijk eens naar het voorbeeld:

Die ploeg speelde zo slecht dit weekend, die kunnen inpakken.

Met inpakken wordt hier bedoeld: vertrekken, oprotten, verkassen. De uitdrukking wordt vooral gebruikt in de sportwereld, als iemand of een ploeg een slecht resultaat behaalde. Ook 'inpakken en wegwezen' ligt hier dichtbij.

De vraag is nu: is het gebruikelijk dat we hier op Wiktionary ook betekenissen in de spreektaal vermelden ? Of beperken we ons tot geschreven Nederlands ? Hoe doet men dat dan met Schweizerdeutsch/Zwitsers Duits ? Da's officiëel enkel een spreektaal, maar ondertussen zal men ook al geschreven Zwitsers Duits hebben, zeker de jongere generatie ..

Andere voorbeelden rond (Vlaamse) spreektaal vinden we bij de VRT: http://www.vrt.be/taal/ . Misschien ook voer om eens over na te denken ? --Btrs 20 sep 2011 17:07 (CEST)

Deze betekins van 'inpakken' is zeker niet beperkt tot Vlaams en kan denk ik zonder meer als betekenis toegevoegd. Jcwf 20 sep 2011 17:15 (CEST)

En om je vraag te beantwoorden: we beschrijven hier de Nederlandse taal als geheel en hebben voor dingen die eerder spreek- and schrijftaal zijn sjablonen zoals {{informeel}}. We zijn echter nogal voorzichting met plakkers zoals 'Vlaams' of 'Zuidnederlands' omdat dit vaak tot een soort taalapartheid leidt. (Wel een plakker voor iets uit het zuiden en niet voor iets dat alleen in het noorden gebruikt wordt is wat asymmetrisch, niet?) Jcwf 20 sep 2011 17:21 (CEST)

Jcwf, ik snap wat je bedoelt. Maar in je uitleg vinden we ook al een mooi voorbeeld: "plakker" is ook geen standaardnederlands, of wel ? Dan zou eerder "etiket" beter passen. Maar goed, hier ben ik echt aan het muggenziften.--Btrs 20 sep 2011 18:18 (CEST)

Ach ja die 'standaardtaal' die geen hond spreekt, zelfs Taalunie niet, denk ik. Jcwf 20 sep 2011 19:51 (CEST)

In een andere taal

Beste mensen, bij 'willekeurig woord' kom ik soms Albanese en/of Turkse woorden tegen. Mijn vraag is of er ook Syrische woorden mogen worden toegevoegd. Ik kan hier namelijk aan bijdragen. Een tweede vraag is of er daar uberhaupt wel een behoefte aan is. Ik zie jullie antwoorden tegemoet. Met vriendelijke groet, Michaelovic 21 sep 2011 16:02 (CEST)

ZEKER!! Graag zelfs. Behoefte? Tja, onder de 6 miljard mensen op deze planeet kan er best eens iemand zijn die daar heel blij mee is. Dat weet je maar nooit. Verder is het een (infinitesimale) vergroting van wat je met Nederlands kunt doen: bijvoorbeeld makkelijker Syrisch leren of ontcijferen. Er zijn bijvoorbeeld wellicht mensen die religieuze geschriften willen bestuderen die daar heel blij mee zijn. Veel mensen? Nee dat verwacht ik niet, maar dat is eigenlijk niet zo belangrijk. Het mooie aan WikiMedia is dat ook kleine minderheden aan bod komen en niet in het geschreeuw van de massa hoeven onder te gaan. Jcwf 21 sep 2011 16:43 (CEST)

Beste Jcwf, bedankt voor je overtuigende antwoord. Ik wilde het voor de zekerheid vragen voordat de aangemaakte pagina's verwijderd zouden worden. Ik heb gemerkt dat de pagina's bij wikiwoordenboek anders zijn dan bij wikipedia. Bij het Arabische woord العربية zie ik bijvoorbeeld erg veel sjablonen zoals {{=ara=}} en {{WikiW|IPA}}: {{IPA|/alʕaraˈbiːjə/}}. Ik weet nu even niet welke sjablonen ik eerst moet aanmaken voordat ik werkelijk kan beginnen met woorden toevoegen. Zou jij mij wellicht daarin kunnen helpen? Met vriendelijke groet, Michaelovic 21 sep 2011 16:53 (CEST)

Beste Jcwf, ik zie dat je alvast wat sjablonen hebt aangemaakt voor Syrisch en klassiek Syrisch, waarvoor mijn grote dank. Ik weet alleen niet of het in de praktijk verstandig zal zijn om die splitsing te maken. Het Syrisch is immers een taal waarin het klassiek Syrisch een onderdeel van is. Modern Syrisch wordt vrijwel niet geschreven. Wanneer men Syrisch schrijft, dan schrijft men in het klassiek Syrisch. Dit is vergelijkbaar met de vele Arabische (gesproken) dialecten, terwijl in schriftvorm enkel het Modern Standaard Arabisch wordt gehanteerd. Mijn voorstel is om de syc code te gebruiken, aangezien die schriftvorm wordt gebruikt. Echter dan wel onder de naam Syrisch (dus niet 'klassiek' ervoor), aangezien we dit ook niet doen bij het [Modern Standaard] Arabisch. Lijkt dit je een goed voorstel? Michaelovic 21 sep 2011 19:20 (CEST)

Bij nader inzien, misschien is het toch beter als we beide hanteren. Groet, Michaelovic 21 sep 2011 19:56 (CEST)

Wat we als beleid hebben is dat we ISO 639-3 volgen. Er zijn voor zover ik weet twee codes (syc en syr). Wat voor Neerlandse naam we daaraan plakken laat ik graag aan iemand over die er verstand van heeft (Je bent dus bij deze tot expert gebombardeerd ) We zouden best syc "Syrisch" kunnen noemen en bijvoorbeeld syr "Modern Syrisch" of zo. Ga je gang en voel je vrij wat dat betreft. Het aanmaken van de sjablonenkraam is altijd een beetje bewerkelijk dus dat zal ik wel doen. Laat maar weten hoe je het wilt. We gebruiken inderdaad nogal wat sjablonen hier en ik hoop dat je wat in de uitlegbladzijden wilt snuffelen die het welkomsjabloon op je overleg propageren. Uiteraard verbeteren we newbee's graag in het begin maar hopen dat ze bereid zijn het aan te leren. Er is nog niets voor Syrisch en dat betekent dat we waarschijnlijk wel wat sjablonen voor naamwoords- of werkwoordsvormen zullen moeten aanmaken. Vertel me maar hoe je het wilt of -als je goed in sjablonen bent- maak maar wat aan. Jcwf 21 sep 2011 20:06 (CEST)

Strikt gezien is syc klassiek Syrisch en syr 'gewoon' Syrisch. Syr bestaat echter uit meerdere dialecten. Ik heb er even goed over zitten nadenken hoe we dit moeten aanpakken. Ik denk dat het beter is om de ISOcode syc aan te houden, maar daarbij wel het etiket Syrisch aan vastplakken. Modern Syrisch lijkt mij niet echt een goed plan, aangezien dit uit meerdere Neo-Syrische dialecten bestaat die niet gestandaardiseerd zijn (lees: iedereen - als er al wordt geschreven - schrijft op zijn/haar eigen manier). Daar komt nog eens bij dat elk dialect een woord anders uitspreekt. Dat wordt een te ingewikkeld proces wat nog eens moeilijk bij te houden is. Wat ik er wel in zou willen hebben is een kopje vocalisatie waarin zowel de oostelijke als de westelijke vocalisatie aan bod komen. Sowieso zullen lemma's ongevocaliseerd zijn, aangezien we anders een zoeknachtmerrie krijgen. Als ik verder wat nodig heb, dan vraag ik het wel. :-) Met vriendelijke groeten, Michaelovic 21 sep 2011 21:18 (CEST)

Welkom welkom! :) Curious 21 sep 2011 21:26 (CEST)

ISO stelt dan ook dat syr een "macrotaal" is en geeft een verwarrend aantal sub-talen (die je best dialecten mag noemen: ISO is nogal scheutig in wat ze een taal noemen) met geldige ISO-codes. Als je een van die sub-talen machtig bent staat het je natuurlijk vrij om ook daarin bijdrages te leveren, bijv onder "tru" voor Turoyo. Geldige ISO-code is voor ons "taal" per definitie. Je zou ook alles onder syr kunnen houden en dan specificeren welk dialect of zo. Dat gebeurt ook wel met bijvoorbeeld Koerdisch of Nahuatl/ Het feit dat "er weinig in geschreven wordt" lijkt me op zich geen bezwaar om er zelf wel in te gaan schrijven. Voor de overlevingskansen van je taal lijkt me dat zelfs een grote noodzaak. Een taal kan niet altijd op oude botten blijven knagen, hoe eerbiedwaardig die botten ook zijn. Jcwf 22 sep 2011 00:03 (CEST)

Klopt, zelf ben ik een Turoyo spreker, maar dit dialect wordt niet geschreven. Neo-Syrische talen hebben erg veel invloed gehad van het Turks, Koerdisch en Arabisch. Ik zou echt niet weten hoe een aantal woorden in dat dialect geschreven moet worden. Men hanteert daarom ook altijd het klassiek Syrisch aan als het op schrijven aankomt. Hoewel het 'klassiek' heet (en daarom lijkt alsof het niet wordt gebruikt), wordt deze vorm tegenwoordig nog in grote mate gebruikt in literatuur en liturgie. Het zijn misschien oude botten, maar in ieder geval nog wel levende en stevige ;-). Waar heb je trouwens gevonden dat tru onder de macrotaal syr valt? Volgens ISO is dat niet zo. Ik heb ooit contact met hun gehad of ze tru konden onderbrengen bij syr, maar dit hebben ze geweigerd. Gek, want ik ben toch echt een spreker van het Syrisch. Michaelovic 22 sep 2011 00:58 (CEST)

Ook het Engelse net heeft hierover gebakkeleid, zie en:Wiktionary:Grease_pit_archive/2011/June#Template:syc Jcwf 22 sep 2011 04:10 (CEST)

Bedankt voor de link. Grappig om te lezen dat het daar eigenlijk er net zo aan toe ging. Michaelovic 22 sep 2011 13:32 (CEST)

’apostrof en 'apostrof

Om een of andere duistere reden staan onze Franse collega's (of moet ik zeggen collega’s) erop om een andere apostrof te gebruiken dan de rest van de mensheid. Ze komen dan hier om interwiki's aan te leggen vanaf fr:’s-Hertogenbosch naar 's-Hertogenbosch. De Taalunie gebruikt ' en ik vind het een beetjes vreemd dat de Fransen dat anders willen doen. Meningen?

Jcwf 24 sep 2011 05:51 (CEST)

In het Limburgs staat zelfs geschreven in de spelling dat de apostrof een rechte streepje is, dus <'>. En in het Nederlands staat ook in ieder woordenboek dat ik bezit <'>. --Ooswesthoesbes 24 sep 2011 08:50 (CEST)

Interwiki's worden normaal geplaatst tussen twee pagina's die op exact dezelfde wijze zijn geschreven, dus het lijkt me terecht dat bovenstaand voorbeeld is teruggedraaid.

Over de apostrof, tja, eigenlijk zou het me niet veel kunnen schelen welk van de twee er wordt gebruikt, maar ja, als je een woordenboek maakt, zul je je toch moeten houden aan de bestaande spellingsregels: de Taalunie heeft de rechte apostrof... Het zou prettig zijn als fr.wikt de spelling van de Taalunie zou willen respecteren, maar ik vrees dat je dan weer discussies krijgt in de trant van "wie is de Taalunie dan wel niet?", en "kijk, hier zie ik ook een gekrulde apostrof en daarom is dat ook een juiste schrijfwijze". :( Curious 24 sep 2011 11:35 (CEST)

De Taalunie gebruikt ook de ’ U+2019. Zoek s-Hertogenbosch in [1], [2], [3] (Technische Handleiding) en [4], of ’ in [5] en [6] (Technische Handleiding).

En Unicode zegt [7] :

0027 APOSTROPHE

• 2019 is preferred for apostrophe

Jullie kunnen U+0027 gebruiken, veel mensen doen dat. Maar het is onzin te zeggen dat U+2019 vreemd is, of dat Fransen (of anders) willen anders doen.

Beide apostrofs zijn correct. U+2019 is typografisch en U+0027 is historisch (ASCII en schrijfmachines). Lees w:en:Apostrophe#Typographic_form --Moyogo 26 sep 2011 08:09 (CEST)

Vanuit Technische Handleiding: regels voor de officiële spelling van het Nederlands, juni 2009, Taalunie, p.20 [met ’ U+2019 en niet ' U+0027] :

’ apostrof; ten behoeve van sommige afkortingen, meervoudsvormen of genitieven;

--Moyogo 26 sep 2011 09:04 (CEST)

Jcwf linked to the online official wordlist of the Taalunie and said that the Taalunie uses ' (true). I said that it is a spelling rule, but that assumption is probably not true. My apologies.

At nl.wikt we always follow that wordlist, and I think we should continue to do that, including the apostrophe and including any other non-letter characters.

About the interwiki link that started this whole story: it's probably not such a good idea to have interwikis between pages that are not written with the exact same characters. I am sorry if there are differences in opinion between fr.wikt en nl.wikt. -- Curious 26 sep 2011 21:03 (CEST)

I'm sorry, we should have asked beforehand if we could create redirects for one apostrophe to the other. We might have assumed it was OK, for us the equivalence of both apostrophe is not an issue. But I think it's pretty obvious some of the reason you have against the other apostrophe are plain wrong, as the Taalunie uses one in its wordlist and another in its set of rules who's to say only one apostrophe is official and correct. I think it pretty closed minded to just assumed we were imposing some French views, when it's just a matter of typography and character encoding. Maybe the Taalunie could clarify that, but seeing what is said in Unicode and what is done in Word processor or other places, one can only come to the conclusion that both apostrophe characters are correct. You are free to keep the one you have, we respect that, there's nothing wrong with it (we just have a preference for the other one). You are free to refuse any redirects, but at least don't deny the fact that both apostrophes are correct and that not admitting the other type is a problem (how you choose to solve it or ignore it is your choice). We just want to make it easier for the user to get from one wiki to another, redirects do that. In a perfect world we wouldn't have to use redirects, but until MediaWiki handles the character equivalence in a nice way we have to find solutions. We're open to suggestions. --Moyogo 26 sep 2011 23:32 (CEST)

Alright here is a simple suggestion: use ' like everybody else. Including e.g. the Bretons or the Occitans. Jcwf 26 sep 2011 23:52 (CEST)

?

I don't understand that link. I quite frankly don't know what to say without you being aggresive-ish. --Moyogo 27 sep 2011 11:05 (CEST)

In any case, at least now you know why we use ’ U+2019, and you know that the Taalunie does too. Btw other Wiktionaries do to. So you initional question has been answered. I hope the redirects from fr:’s-Hertogenbosch to 's-Hertogenbosch doesn't get removed by a bot because that seem to be a reasonable solution. --Moyogo 27 sep 2011 11:32 (CEST)

Hi everybody, sorry to intervene here but (and I don't intend to be rude or hurt anyone) well since I am not Dutch I can probably give you, and your French colleagues, an opinion that you could deem unbiased (even if the fact that I come from the Occitan/Catalan wikis, among other things, might not play in my favor...). I think you do not grasp the real issue, and worse you all keep on insisting... Let's put this into another context, how would you, in the French wiktionary, appreciate having four people or more from the English wiktionary tell you that you do not write the vowels properly, that you use way too often open vowels in languages like Italian, Greek and so on, with some kind of hasty behavior that keeps on insisting that you do not know enough (the rules of) your own language and so on...

It is more the fact that you intervened as a "pack" and lecturing people than the things you are telling actually. I suppose that when you go to someone's house, you don't tell them how they should arrange their furniture except if there is a certain confidence between you and these people, and man even in this case I wouldn't probably dare... so imagine that after yout first comment you came back some other day and brought a whole team of decorators wishing to change the house (or a part of it...), even if you are convinced you are right and that the previous atmosphere was bad... I just let you imagine what can happen...

Moreover, you should know that the interventions of a group are sorely appreciated and can also/even be perceived as some kind of "threat" as was the intervention of a bunch of Occitan people in order to avoid the erasure of an article not that long ago in the French Wikipedia; in our specific case it even came to appear in one question of the Stewards election namely: "You find out that some editors from a regional language community are on a mission to vandalize the French language projects - they use all the tricks they can find to vandalize. They are constructive on their own language Wikipedia."; so you can have an idea how any interventions can be perceived even if this community is not as terrible, threatening or hostile as the Occitan hordes usually are...!

To come to my last point, I think we all have more pressing things/matters to do than writing here endlessly; let's improve our wiktionaries and borrow what is good or interesting from one another; I suppose we all are good willed persons, I trust the Dutch team here to be intelligent and sound people (I know for sure they are nice, hardworking and really open to small or minorized languages...), and well if they someday feel the urge to change the apostroph they will do it by themselves. I think they have understood what you said and meant, but well as I also think the apostroph is not this important an issue to deal with right now (moreover conventions can change from time to time as it happened in German, or even in French, according to the needs/use of the speakers/writers or forced by academies) you should concentrate on other issues; furthermore the importance of its typographical form seems to matter more in French than in other languages... so only time will tell... I wish you all the best. Bonne journée et bon travail! Claudi/Capsot 27 sep 2011 12:42 (CEST)

I totally agree with your last point. I was just answering the initial question and correcting false statements. I am sorry those things have happened to you. If some users gang up to patronize you that is wrong, but it seems, at least here, it was not a gang effort, but rather users individually assuming things allowed on other wikis were also allowed here. From what I have seen they have stopped once they knew what the rule was here. --Moyogo 27 sep 2011 13:51 (CEST)

Ha, I also hope no bots add non identical interwiki here, since it's a rule not to have them here (I had almost forgotten). --Moyogo 27 sep 2011 14:40 (CEST)

In theorie is het correct(er) om de U+2019 als apostrof te gebruiken, zeker in gedrukte teksten/woordenboeken (ik heb hier alleen een Latijns woordenboek liggen, daar wordt ook de U+2019 gebruikt). Maar zodra mensen moeten kunnen zoeken in de lijst is het veel handiger om de ASCII apostrof te gebruiken (bv. het U+2019 karakter kan niet met één enkele toetsaanslag gemaakt worden).

Maar kunnen er problemen ontstaan als er interwiki's aangelegd worden die op karakter niveau niet gelijk zijn? -- Difool 27 sep 2011 20:49 (CEST)

Voor zover ik weet koppelen interwikibots op dit moment alleen pagina's die exact hetzelfde zijn geschreven, en (afhankelijk van de instellingen?) verwijderen ze mogelijk niet exact dezelfde pagina's. Maar helemaal zeker weet ik dat niet. Curious 27 sep 2011 20:57 (CEST)

Voor zover ik weet, is je beschrijving correct, Curious. Annabel_(overleg) 27 sep 2011 21:50 (CEST)

Ik begrijp niet zo goed waarom U+2019 'beter' zou zijn. Als de Taalunie op hun webstek met 'officiële' spellingen gewoon het ASCII-tekentje gebruiken, vermoed ik zo dat de Taalunie dat ook niet zo ziet. Waarom ik 'aggressive-ish' om word? Tja, misschien wel omdat mensen die hier zelden of nooit komen hier wel komen om uit niets een probleem te maken. Als de Franse wiki/wikti zo nodig een andere apostrof wil dan iedereen op zijn keyboard heeft, vind ik dat ze dan maar gewoon bij zich moeten houden en niet komen exporteren. Jcwf 27 sep 2011 22:13 (CEST)

ʼapostrof ’apostrof 'apostrof

Er zijn er dus drie? De eerste is (blijkbaar) onderdeel van de spelling van Diné (Navaho) en geeft een glottisslag of een ejectieve consonant aan. En nee we hebben niet altijd de juiste gebruikt...Zucht Jcwf 28 sep 2011 05:05 (CEST)

Het verschil tussen de eerste twee is wel echt heel miniem... --Ooswesthoesbes 28 sep 2011 05:27 (CEST)

' (U+0027) kan veel dingen voorstellen.

• apostrof (leesteken): l'enfant (U+0027) of l’enfant (U+2019)
• apostrof (letter): ma'eno (U+0027), ma’eno (U+2019) of maʼeno (U+02BC)
• okina (letter): 'okina (U+0027) of ʻokina (U+02BB)
• saltillo (bovenkast letter): ME̱E̱'PHA̱A̱ (U+0027) of ME̱E̱ꞋPHA̱A̱ (U+A78B)
• saltillo (onderkast letter): me̱e̱'pha̱a̱ (U+0027) of me̱e̱ꞌpha̱a̱ (U+A78C)
• ejectiefteken: /p'/ (U+0027) of /pʼ/ (U+02BC)
• aanhalingstekens: 'woord' (U+0027), ‘woord’ (U+2018, U+2019) of ‛woord’ (U+201B, U+2019)
• primeteken/minutenteken: 40° 20'50" (U+0027) of 40° 20′50″ (U+2032)

’ U+2019 en ʼ U+02BC hebben hetzelfde glief. Dus het verschil tussen beide is semantisch.

Sommige mensen denken dat het is better ʼ U+02BC niet te gebruiken.

Bronnen: Unicode (Code Charts en Chapter 6), On the apostrophe and quotation mark, with a note on Egyptian transliteration characters en Apostrophes in native languages. --Moyogo 28 sep 2011 09:28 (CEST)

Shtooka (audio opname software)

Bij wat rondneuzen tussen de geluidsbestanden op Commons kwam ik een aantal keer de naam Shtooka tegen. Het blijkt software, bedoeld voor het geautomatiseerd aanmaken van audiobestanden voor de uitspraak van woorden. Het klinkt veelbelovend: "One can record an average of 500 words in 20 minutes." (!!)

• Uitleg van een gebruiker: [8]
• Website Shtooka Recorder: [9]

Misschien dat iemand belangstelling heeft? -- Curious 30 sep 2011 19:40 (CEST)

Het opnemen op zich kost niet zo veel tijd, maar je moet alles in piepkleine bestandjes knippen (in mijn geval) converteren naar ogg zorgen dat alle bestandsnamen het juiste formaat hebben en dan opladen naar commons. Dat laatste is een heel gedoe omdat common vreselijk bureacratisch is. Tot voor kort stonden ze erop dat ieder woord afzonderlijk ingebracht moest worden. Voor ieder woord moest je dus een apart formulier invullen, waarop je telkens weer moest verklaren dat het jouw werk was, op welke datum het aangemaakt was Nu kun je tenminste 10 woorden min of meer tegelijk doen, hoewel ook dat nog behoorlijk bewerkelijk is. Je kunt bijvoorbeeld niet voor alle tien zeggen "pronunciation file" of "Category:Dutch pronunciation", je kunt zelfs niet tien bestandjes tegelijk aanklikken, ook dat moet nog steeds één voor één. Commons werkt de wiktionaries al tijden lang zwaar tegen. Jcwf 5 okt 2011 02:08 (CEST)

:-( Curious 5 okt 2011 21:24 (CEST)

Zonet audacity even geprobeerd en de uitspraak aangemaakt voor meekomen. Kan iemand eens nakijken of alles hier goed is? Wordt het geluidsbestand goed weergegeven? Annabel_(overleg) 16 okt 2011 11:33 (CEST)

Klinkt goed! :) Curious 16 okt 2011 13:33 (CEST)

Danke, ik heb er nog een reeks woorden gedaan en heb er nog een paar staan lokaal om op te laden. Uitspraken toevoegen, het heeft nog iets speciaal. Annabel_(overleg) 16 okt 2011 21:21 (CEST)

Mogen er nog vele meer volgen! :) Curious 16 okt 2011 21:35 (CEST)

Klinkt goed. Leuk om eens wat Vlaams-Nederlands te horen in plaats van dat geroggel van boven ;) --Ooswesthoesbes 16 okt 2011 22:01 (CEST)

GGGeroGGGel? Welk GGGeroGGGel? Dit klinkt toGGG GGGewoon GGGeweldiGGG? ;) Curious 17 okt 2011 20:15 (CEST)

Laat een Amerikaan maar eens dit horen: "als een schitterend geschenk schoot een schelle schicht schichtig uit de hoge." Zijn ze meteen genezen. Jcwf 17 okt 2011 20:29 (CEST)

Ik blijf het toch knap vinden hoe sommige Noorderlingen met keel-r en harde g een woord als "geroggel" kunnen uitspreken :P --Ooswesthoesbes 17 okt 2011 21:33 (CEST)

Ja, dat vind ik ook. Daarom houd ik het maar bij een ouwerwetse tongpunt-r... 17 okt 2011 22:04 (CEST)

Ondertussen al 221 woorden bij elkaar geroggeld ... Annabel_(overleg) 5 feb 2012 21:08 (CET)

Seelenstrip

Bestaat er een nederlands woord voor duits: Seelenstrip? Of zijn de nederlanders daarvoor te preuts ;)?
Dank jullie vooruit.
Groet, Ciciban 5 okt 2011 10:22 (CEST)

Zoiets heb ik nog nooit in het Nederlands gehoord. Maar misschien ligt dat wel aan mij. Curious 5 okt 2011 21:27 (CEST)

Ich denke, ist eine moderne Wortbildung, eher Jargon. Mal sehen, ob das Wort auch in die deutschen Wörterbücher Eingang findet. -- Cadfaell 5 okt 2011 21:57 (CEST)

Bestaat niet meer [seelenstrip.de.tc/ r] (http:// weg moeten halen :() p@io4it 8 okt 2011 04:04 (CEST)

de:Seelenstriptease
Groet, Ciciban 26 okt 2011 13:13 (CEST)

Italië

Er wordt blijkbaar in Italië nog afgewacht op wat er morgen in het parlement gaat gebeuren. De protesten hebben wel opgeleverd dat er een parlementslid wiki verzekerd heeft dat er een amendement komt dat wiki's positie zal vrijwaren. Jcwf 9 okt 2011 20:32 (CEST)

Ongebruikte categorieën

Een van de speciale pagina's op deze wiki is de pagina Speciaal:OngebruikteCategorieën. Deze geeft een overzicht van lege categorieën. Op het ogenblik van schrijven zijn dat er 73. Kan iemand eens meekijken. Zijn deze allemaal overbodig, zijn ze ontstaan of leeggeraakt door een fout in een sjabloon, kunnen er een aantal opgeruimd worden of moeten ze gewoon aangevuld worden? Annabel_(overleg) 16 okt 2011 11:00 (CEST)

Zoals ik het vluchtig bekijk, geven zij goede categorieën, maar ze zijn simpelweg nog niet ingevuld. --Ooswesthoesbes 16 okt 2011 11:07 (CEST)

Merendeels zijn die categorieën wel aan te vullen, denk ik. (Enkele gedaan.) -- Curious 16 okt 2011 14:52 (CEST)

Hetzelfde is dus niet te zeggen van de ongebruikte sjablonen. Een aantal ervan zijn nog ontbrekende ISO 639-5 sjablonen, maar er zijn ook hardnekkige verwijzingen naar sjablonen die al tijden verwijderd zijn en waar ook allang niet meer naar verwezen wordt, zoals {-nl-} of {-de-}. Heeft iemand een idee hoe dat komt? Ik betwijfel dat dat is omdat de cache echt zo oud is... Meer beeheesjes? Jcwf 17 okt 2011 20:34 (CEST)

Categorie:WikiWoordenboek:Onbereikbare externe link is ooit van een botrun van me om links op te sporen naar onbereikbare pagina's. Geen idee of ik dat uiteindelijk ook gedaan heb en als het zo was, dan waren het er niet veel. Deze categorie kan weg.

De achtervoegsel cats lijken me geen nut te hebben. Verticaal klasseren in de prullenmand?

Categorie:WikiWoordenboek:Twijfel is afkomstig van {{twijfel}}. We kunnen evengoed {{weg}} gebruiken lijkt me.

Categorie:WikiWoordenboek:Weg is afkomstig van {{weg}}. De inhoud kan in de erboven liggende categorie komen (Categorie:WikiWoordenboek:Te verwijderen -> reden: overcategorisatie: nu hebben we meerdere lege of bijna lege subcategorieën).

Heeft {{Sjabloon:m/f/n/p}} nog nut? Zorgt voor de categorie Categorie:WikiWoordenboek:Ongedefinieerd geslacht.

{{nonzwak0}} geeft aanleiding tot de Categorie:Zwak werkwoord klasse 0 in het Oudnoors. (@Cadfaell:) ga je {{nonzwak0}} opnieuw gebruiken of is het sjabloon overbodig geworden? Categorie:Overgankelijk werkwoord in het Oudnoors wordt ook niet meer in een sjabloon gebruikt ....

Voor de rest zie ik niet zo direct naar welke sjablonen je/Jcwf verwijst die allang verwijderd zouden zijn.

Annabel_(overleg) 17 okt 2011 22:11 (CEST)

Jcwf bedoelt denk ik deze pagina: Speciaal:GevraagdeSjablonen. Bijv. Sjabloon:nl staat daar al tijdenlang op, heeft geen verwijzingen meer, maar blijft toch maar op die Speciale pagina staan. Geen idee waarom. Sjabloon {twijfel} zou ik graag willen behouden: soms heb ik serieuze twijfel bij wat iemand heeft geschreven, maar gaat het me te ver om er een {weg} etiket op te plakken, zo stellig zou ik dat niet durven beweren. Sjabloon:m/f/n/p wordt (werd?) aangeroepen als iemand het basisstramien gebruikt, maar vergeet om het juiste geslacht in te vullen; ik heb maar een enkele keer wat woorden uit Categorie:WikiWoordenboek:Ongedefinieerd geslacht geplukt, maar het was toch wel handig. De andere categorieën/sjablonen maken me niet zo heel veel uit geloof ik. Curious 18 okt 2011 00:05 (CEST)

OK. Da's duidelijk. En wat als we wel {{twijfel}} en {{weg}} behouden, maar de pagina's van beide sjablonen laten categoriseren in dezelfde categorie Categorie:WikiWoordenboek:Te verwijderen? Annabel_(overleg) 18 okt 2011 07:36 (CEST)

PS: ik heb een paar van de gevraagdesjablonen aangepakt. Er zijn er ook voor mij veel bij waarvan ik me afvraag hoe ze op die lijst komen. Annabel_(overleg) 18 okt 2011 07:50 (CEST)

Een enkele is een nog openstaande contextplakker, een aantal komen van de gebruikersbladzijde van Gebruiker:Averaver, die hier geen fluit bijdraagt maar wel zonodig een stel onaangemaakte sjablonen op zijn gebruikerspagina wil hebben. Mijn vingers jeuken soms om ze maar aan te maken en er "ik ben een ...." in te zetten met iets onvriendelijks. Maar dat is natuurlijk weer niet netjes... maar is dit soort misbruik van gebruikerspagina's dat wel dan?

Jcwf 18 okt 2011 16:21 (CEST)

Ik heb de lege Noorse, Nynorske en Oudnoorse sjablonen nu angevuld. -- Cadfaell 18 okt 2011 19:11 (CEST)

Annabel, maakt me niet veel uit. Jcwf, gooi het eruit, maak die sjablonen, leef je uit, opkroppen is ook nergens goed voor! >:) (oeps, foei, wat zeg ik nu? :) ) Maar serieus, dit is een woordenboek, niet een persoonlijke website. Gebruikers kunnen niet eisen dat ze persé iets op een gebruikerspagina willen hebben. Niet bestaande sjablonen kunnen het best verwijderd worden, ja wat mij betreft ook van gebruikerspagina's. Cadfaell, allen, handig dat iedereen meehelpt om wat op te ruimen, schiet lekker op zo. :) Curious 18 okt 2011 21:18 (CEST)

Nu we toch bezig zijn: hebben deze nog nut?: Sjabloon:windstreken-kab, Sjabloon:windstreken-lat, Sjabloon:kleuren-nld, Sjabloon:lat-land-Europa, Sjabloon:huidigbestand, Sjabloon:lim-continent, Sjabloon:lim-land-Afrika, Sjabloon:lim-land-Amerika, Sjabloon:lim-land-Oceanië. Ze hebben allen nul komma geen verwijzingen... Annabel_(overleg) 18 okt 2011 22:53 (CEST)

Ik los de Limburgers wel op :) --Ooswesthoesbes 19 okt 2011 09:50 (CEST)

Wow, dat ging snel! Vind je die andere sjablonen er ook niet verleidelijk uitzien, OWTB? Curious 20 okt 2011 21:55 (CEST)

Ik houd 't toch echt bij Limburgs en af en toe iets Nederlands ;) --Ooswesthoesbes 21 okt 2011 06:49 (CEST)

Micronesië/Micronesia

Blijkbaar is er een verschil aangezien Micronesië bij verwant staat op Micronesia. Wat is het precies? --Ooswesthoesbes 19 okt 2011 09:52 (CEST)

Nog een opmerking: Is het echt "Saint Kitts en Nevis"? --Ooswesthoesbes 19 okt 2011 10:04 (CEST)

Nog eentje: Wat is de naam van de recentelijk onafhankelijk zuidelijke deel van Soedan? --Ooswesthoesbes 19 okt 2011 10:09 (CEST)

De Taalunie heeft een pagina over de spelling van aardrijkskundige namen: [10].

1. "De Federale Staten van Micronesia vormen één soevereine staat onder de naam 'Micronesia'. 'Micronesia' verwijst dus naar de staat en 'Micronesië' naar het gebied waar de eilanden zich bevinden." [11]
2. Ja. [12]
3. Blijkbaar twee spellingen: "Zuid-Soedan" en "Zuid-Sudan". [13] -- Curious 25 okt 2011 20:09 (CEST)

Dank je :)

1. Volgens mij maken wij daar geen onderscheid in.
2. Ok, dan zal dat wel è :)
3. Goed :) Eigenlijk moeten we nu alle landensjablonen gaan updaten...

--Ooswesthoesbes 26 okt 2011 05:57 (CEST)

[3] Heb een aantal Afrika-sjablonen aangevuld met Zuid-Soedan. Aan de rest waag ik me niet. -- Curious 26 okt 2011 22:37 (CEST)

Goedzo :) --Ooswesthoesbes 27 okt 2011 07:11 (CEST)

De Wikimedia Conferentie 2011 komt eraan!

Hallo allemaal!

Op zaterdag 5 november organiseert de Vereniging Wikimedia Nederland in Utrecht de jaarlijkse Wikimedia Conferentie Nederland!

De Wikimedia Conferentie wordt voor de vijfde maal georganiseerd en ook dit jaar hebben we weer een goed gevuld programma met diverse sprekers omtrent de thema's wiki's en Cultureel Erfgoed. Zo kun je meer te weten komen over de toekomst van gadgets voor Wikipedia, de meerwaarde van het vrijgeven van fotocollecties en kun je leren over het gebruik van sjablonen en categorieën. Aan het einde van de dag zal de prijsuitreiking van de in september georganiseerde fotowedstrijd Wiki Loves Monuments zijn, waarvoor je ook van harte bent uitgenodigd.

De conferentie vindt plaats van 9.30 tot 18.00 bij Media Plaza op Hoog-Catherijne in Utrecht (direct naast het Centraal Station!). Vanaf 15.00 uur is de conferentie vanwege de prijsuitreiking vrij toegankelijk.
Verenigingsleden krijgen bij ons uiteraard een speciale korting op de toegangsprijs. Nog geen lid? Maak dan gebruik van de mogelijkheid om je via de voorinschrijving kostenloos in te schrijven voor 2011 èn 2012!

Ga voor meer informatie naar wikimediaconferentie.nl en schrijf je in!

Tot op 5 november! Ciell 20 okt 2011 10:01 (CEST)

Crosswiki spammer

Hoi iedereen. Ik weet niet waar ik het anders moet zeggen, dus ik doe het daarom maar even hier. Kan iemand svp de gebruiker Allensmith lokaal voor onbepaalde tijd blokkeren? Het is een crosswiki spammer en ik heb vandaag behoorlijk wat accounts globaal gelockt (kijk naar m:Special:Log/Trijnstel en zoek op "spam-only accounts" van 20 oktober). Een aantal zijn non-sul account (deze is er één van, zie hier) en die kan ik daarom niet locken. Bedankt alvast voor jullie hulp. Met vriendelijke groet, Trijnstel 20 okt 2011 14:11 (CEST)

Uitgevoerd Jcwf 20 okt 2011 15:33 (CEST)

Bedankt voor de melding, Trijnstel! Annabel_(overleg) 20 okt 2011 16:27 (CEST)

Terms of Use update

I apologize that you are receiving this message in English. Please help translate it.

Hello,

The Wikimedia Foundation is discussing changes to its Terms of Use. The discussion can be found at Talk:Terms of use. Everyone is invited to join in. Because the new version of Terms of use is not in final form, we are not able to present official translations of it. Volunteers are welcome to translate it, as German volunteers have done at m:Terms of use/de, but we ask that you note at the top that the translation is unofficial and may become outdated as the English version is changed. The translation request can be found at m:Translation requests/WMF/Terms of Use 2 -- Maggie Dennis, Community Liaison 27 okt 2011 03:08 (CEST)

Van of uit ?

Goedendag. Ik ben franstalig en wens te weten wat goed is : "een gebouw van de 16e eeuw" of "een gebouw uit de 16e eeuw" ? Dank bij voorbaat. --Égoïté 3 nov 2011 13:01 (CET)

Cher Égoïté: persoonlijk zou ik "uit" gebruiken, maar ik ben van boven/tussen de rivieren. In het zuiden kan het best anders zijn. Jcwf 3 nov 2011 15:47 (CET)

Het is stammen uit, dus een gebouw is uit de 16e eeuw. --Ooswesthoesbes 3 nov 2011 18:47 (CET)

(@jcwf:) Als je met Antwerpen het zuiden bedoelt, ja dan is het daar ook "een gebouw uit de 16e eeuw". Annabel_(overleg) 3 nov 2011 18:58 (CET) PS: leuke vraag (merci pour la question, Égoïté)

Paginateller

Het sjabloon {{telling}} was ooit in het leven geroepen omdat er problemen waren met de paginateller (die veel te laag was). Het idee was toen dat er zeker een link op een pagina moest voorkomen om meegeteld te worden. Nu heb ik dit sjabloon altijd een rare constructie. Daarom heb ik de afgelopen dagen al het voorkomen van het sjabloon weggehaald van pagina's waar nog andere links op stonden.

Het lijkt erop dat de definitie van de paginateller veranderd is sinds de invoering van {{telling}}. Door wat te spelen met zoekopdrachten op de wiki, ben ik tot de vaststelling gekomen dat ook het voorkomen van een sjabloon leidt tot het meetellen van een pagina op de paginateller, als het sjabloon een link legt. Een voorbeeld van zo'n veelgebruikt sjabloon dat de teller verhoogt is {{=nld=}}, omdat {{=nld=}} een link legt naar de pagina Nederlands. Dus, om een lang verhaal wat in te korten, blijkt dat het sjabloon {{telling}} overbodig geworden is. Het tijdelijk verwijderen van het sjabloon geeft geen daling van het aantal pagina's op de teller. De reden is dat elke echte pagina op deze wiki wel een taalkopje bevat (de =xxx= sjablonen). Ik stel dan ook voor om 1) het sjabloon niet meer te gebruiken, 2) alle ingangen naar het sjabloon (nog zo'n 25000 op dit ogenblik) weg te halen en 3) nadien {{telling}} te verwijderen.

Annabel_(overleg) 3 nov 2011 23:18 (CET)

PS: deze "nieuwe" definitie van wat een artikel is, zal ik dan ook gaan gebruiken voor mijn onzinpaginazoeker die op de verwijderlijst gelinkt staat

Dat zou wel fijn zijn als we van dat sjabloon verlost zouden worden. Wel een kleine opmerking over "Het tijdelijk verwijderen van het sjabloon geeft geen daling van het aantal pagina's op de teller.": ik heb eerder ervaren dat wijzigingen aan een sjabloon meestal niet direct merkbaar zijn op pagina's, vooral bij sjablonen die veelvuldig gebruikt worden. Zo heb ik in het verleden wel eens de foute conclusie getrokken dat wijzigingen in een sjabloon geen effect hadden, terwijl het systeem nog bezig was om de sjabloonwijziging te verwerken... :S Als je helemaal zeker wil zijn, zou je misschien de test met verwijdering van Sjabloon:telling veel langer kunnen laten duren... Curious 4 nov 2011 00:06 (CET)

Dat probleem met vertraging bij wijzigingen van een sjabloon lijkt ook grotendeels opgelost te zijn (heb ik gemerkt de laatste weken). Alleszins, ik heb het ook onafhankelijk van de verwijdering bekeken met een paar zoekopdrachten op de wiki. Zowat alle pagina's waarop {{telling}} gebruikt wordt, blijken namelijk nog links (al dan niet via een sjabloon) te bevatting naar een andere pagina dan telling. In mensentaal, alle, zoniet bijna alle, pagina's blijken al opgenomen te zijn in de paginateller als het sjabloon {{telling}} weggehaald wordt. Annabel_(overleg) 4 nov 2011 13:31 (CET)

Ik ben begonnen met het weghalen van {{telling|[[telling]]}}. Dit zal wel enkele dagen duren. Ter info, de paginateller op het ogenblik van schrijven is 131.703. Annabel_(overleg) 6 nov 2011 19:53 (CET)

Ah, prima. :) Curious 9 nov 2011 23:40 (CET)

Alles is nu afgerond. Het sjabloon is verwijderd. Annabel_(overleg) 10 nov 2011 07:23 (CET)

Taalverloedering der lidwoorden

Moet het nog gezegd worden dat het taalgevoel erop achteruit gaat en dat aandacht voor het gebruik van het op zijn plaats is?: [14] Annabel_(overleg) 4 nov 2011 13:33 (CET)

Dalk kan ons beter "die" en "dit" gebruik? Of moet dit nog gesê word dat die taalgevoel agteruitgaan en dat aandag vir die gebruik van "die" op sy plek is? Jcwf 4 nov 2011 17:02 (CET)

En nee, ik denk niet dat de Standaard gelijk heeft. De vorming van het verkleinwoord is veel te productief om "het" uit te laten sterven. Misschien dat we wel een situatie krijgen dat "het" gereserveerd wordt voor verkleinwoorden. De paard en het paardje, bijvoorbeeld. Jcwf 4 nov 2011 17:05 (CET)

Lijkt me sterk. En daarbij, als we de Limburger volgen had het al een eeuw geleden moeten gebeuren: de filter, de café, de departement, de raam, de journaal. --Ooswesthoesbes 4 nov 2011 17:43 (CET)

Ik ben erg blij dat jullie er ook zo over denken. Overigens merk ik wel meermaals een verschil in het gebruik van de/het in de lage landen, zoals OWTB hier eigenlijk treffend illustreert. Mijn collega's op het werk vielen achterover dat men in Nederland (neem ik toch aan) het filter gebruikt in plaats van de filter. Ikzelf heb ook nooit iets anders gebruikt dan de filter. Annabel_(overleg) 4 nov 2011 20:08 (CET)

Het filter voor mij. De filter klinkt Frans voor mij. oeps Duits heeft trouwens ook beide. Jcwf 4 nov 2011 21:27 (CET)

Limburgers zijn er logischer in: le blijft mannelijk en la vrouwelijk. De constructie le naar onzijdig is het in het Noorden. --Ooswesthoesbes 5 nov 2011 09:09 (CET)

Vanuit het Frans is dat misschien wel logisch, maar het Latijn had filtrum en dat was toch echt onzijdig.Jcwf 5 nov 2011 14:57 (CET)

Inderdaad, maar niet alle mannelijke http://nl.wiktionary.org/w/index.php?title=WikiWoordenboek:De_Kroeg&action=edit&section=17Franse woorden waren vroeger onzijdig in het Latijn en de woorden zijn direct uit het Frans, niet direct uit het Latijn :) --Ooswesthoesbes 5 nov 2011 18:46 (CET)

Dat laatste gaat voorbij aan de grote invloed van de latinisten in de Republiek: die zullen al gauw gekeken hebben hoe dat in het Latijn ook al weer was en het woord her-ontleend aan het Latijn. Jcwf 6 nov 2011 22:11 (CET)

Bij mijn weten is de regel redelijk solide: le -> onzijdig, behalve als het een mannelijk persoon is (de acteur). HHelaas is mijn kennis van het Latijn te brokkelig om hier echt iets zinnigs over te zeggen. --Ooswesthoesbes 7 nov 2011 06:12 (CET)

Echt veel structuur zit daar volgens mij niet in: de automobiel, enz. In de spreektaal gebruiken wij hier (Antwerpen en omstreken) altijd "de filter". Dat zal wel Franse invloed zijn. In Nederland is dat Frans nogal indirect ingevoerd, dus is het gevoel voor de Franse geslachten logischerwijs minder sterk. Latijnse invloed kan misschien wel meespelen, maar ik weet niet hoe sterk de invloed daarvan op de spreektaal zou zijn. Franse dingen (letterlijk: voorwerpen) durven - ongeacht hun geslacht in de brontaal - in het Nederlands wel eens onzijdig te zijn, volgens Van Marle (verwijzing hier) omdat zo duidelijk is dat het om vreemde woorden gaat. Wikibelgiaan 7 nov 2011 12:03 (CET)

Lijkt vreemd, Engelse woorden krijgen immers meestal mannelijk: de computer, de lift, de stand, de socialworker en af en toe een "klankverwant", zoals het keyboard (vgl: het bord). --Ooswesthoesbes 7 nov 2011 20:00 (CET)

Sequentie

Het woord sequentie ontbreekt nog in het WikiWoordenboek. Het zou handig zijn dit woord te hebben om het te kunnen linken op de doorverwijspagina http://nl.wikipedia.org/wiki/Sequentie. Smile4ever 13 nov 2011 09:11 (CET)

sequens, sequentie, sequentieel. --Ooswesthoesbes 13 nov 2011 09:24 (CET)

Woordgroepen die samen anders zijn

Ik zit al een tijdje in het haar over woordgroepen die los anders uitgesproken worden als vast. Een goed voorbeeld is "op een gegeven moment". Los zijn deze woorden: /ɔp/, /eːn/, /ɣə.ˈɣeː.və(n)/ en /mo.ˈmɛnt/, maar vast is het /ˌɔ.mə.ˈɣeː.(mə.)mənt/. Bij dingen als "op+de=oppe" is dit in principe niet echt belangrijk, omdat het een regelmatige klankverandering betreft, maar "op een gegeven moment" is dat niet. Vertalingtechnisch geeft dit met het Limburgs, waar deze woorden vaak uitspraakgericht geschreven staan, problemen. Zo schrijft men ómmegaementj. Mijn vraag luidt feitelijk: "Is een woordgroep als "op een gegeven moment" goed genoeg voor een eigen pagina of niet?" --Ooswesthoesbes 15 nov 2011 13:50 (CET)

etymologie

Ik heb opgemerkt dat er voor veel lemma's nog geen informatie over de etymologie staat, dus zal ik er een paar toe proberen te voegen. Mijn eerste vraag is hoeveel informatie moet er aangeven worden? Is het alleen maar nodig om het Middel- en Oudnederlandse woord aan te geven, of moet er daar mee bij? En zouden verwante woorden in andere talen vermeldt moeten worden, en zo ja, ook hun geschiedenis (Nieuw- Middel- Oudhoogduits enz.?) En wat te doen met het Proto-Germaans en Proto-Indo-Europees? En dan komt de lay-out er nog bij, want al deze informatie op één lijn naast elkaar zal er wel verwarrend uitzien. Is er hiervoor een tabel misschien?--Megaman en m 21 nov 2011 15:08 (CET)

Er is niet echt teen vast formaat voor omdat de beschikbare informatie nogal varieert. Er zijn wel een aantal woorden wat beter uitgewerkt. Je kunt ze denk ik het best vinden in Categorie:Erfwoord in het Nederlands Jcwf 21 nov 2011 14:56 (CET)

Ah oké. Ik zal dat dan maar gebruiken, het is alvast beter dan normale tekst.--Megaman en m 21 nov 2011 15:08 (CET)

Nou, als je iets passenders weet te bedenken horen we dat graag, lijkt me. Het is een nog niet zo erg ontwikkelde zaak. Deels omdat het nogal wisselt wat je ervan zeggen kunt of erover vinden kunt. Deels ook omdat er veel woorden zijn die afgeleid of samengesteld zijn. Het is dan meestal handiger om de opbouw te tonen en de historische etymologie van de delen om de pagina te zetten van die delen. Jcwf 22 nov 2011 00:23 (CET)

Wel veelvoorkomende woorden zijn meestal niet samengesteld, en daarmee ga ik beginnen. Als het woord wel samengesteld is zou het wel beter zijn om alleen de individuele morfemen te weergeven. Het zou wel mooi zijn als de tabel uitklapbaar is, want het neemt wel vrij veel plaats op.--Megaman en m 22 nov 2011 07:14 (CET)

Vragen over tabellen voor vervoeging en verbuiging, gereconstrueerde talen

Nummering ( [1], [2], [3] ) ingevoegd. -- Curious 7 dec 2011 23:52 (CET)

Hoi iedereen! Ik ben al een tijdje actief op de Engelse Wiktionary, en ik ben daardoor bekend met de regels en manier van werken die daar geldt. Dat is hier natuurlijk anders en ik probeer daar zoveel mogelijk op te letten, maar er zijn een paar dingen die me nog niet helemaal duidelijk zijn.

[1] Allereerst heb ik wel gezien dat vervoegingstabellen wel mogen, maar alleen op een aparte deelpagina en niet op de hoofdpagina zelf. Maar wat moet er gebeuren als er van verschillende talen verschillende vervoegingen zijn? Bijvoorbeeld het woord cantar. Daar staan nu vier talen, die elk een eigen vervoegingstabel zouden kunnen hebben. Worden die allemaal op cantar/vervoeging geplaatst en zo ja, hoe worden de talen van elkaar onderscheiden? Moeten de tabellen voor elke taal er ook hetzelfde (ongeveer) uitzien? En daarnaast staan er nog kleine tabelletjes naast de woorden zelf; welke vormen zijn het meest geschikt voor zulke tabelletjes?

[2] Op de Engelse Wiktionary word veel gebruik gemaakt van automatische programma's (bots) die pagina's genereren voor woorden die geen hoofdwoord zijn, maar een vorm van een ander woord. Bij het bovengenoemde cantar zou zo'n bot bijvoorbeeld in het Catalaans de vormen canto, cantes, canta, cantem enzovoorts genereren, met bijbehorende definities. Zijn zulke bots hier ook toegestaan en welke regels gelden daar dan voor?

[3] Tenslotte vraag ik me nog af hoe hier wordt omgegaan met gereconstrueerde talen. Op Wiktionary worden zulke woorden in een appendix geplaatst, zoals het Oergermaans en:Appendix:Proto-Germanic/hundaz. Mag dat ook bij WikiWoordenboek en welke regels voor de bronnen en naamgeving gelden er dan? Mogen de gereconstrueerde woorden die op Wiktionary staan hier zomaar worden overgenomen? —CodeCat 7 dec 2011 13:44 (CET)

Hoi CodeCat. Dat zijn een stel goede vragen! En grotendeels hebben we er nog geen afspraken over denk ik...

Ik heb maar nummertjes toegevoegd en subkopjes aangemaakt om elk van je vragen tot zijn recht te laten komen, hopelijk vind je dat niet erg. Curious 7 dec 2011 23:52 (CET)

[1] Vervoegingstabellen

In principe komen die vier talen allemaal op deelpagina cantar/vervoeging. Tenminste, dat hebben we tot nog toe zo gedaan. Tot dusver kwam het denk ik maar een enkele keer voor dat er twee talen op de vervoegingspagina stonden, meestal staat er maar 1 taal. Maar goed, dat zal wel veranderen... Vooral nu met Spaans en Catalaans. :)

Ter onderscheid zou bijv. het hoofdtaalsjabloon zoals {{=spa=}}, {{=cat=}}, toegevoegd kunnen worden boven de vervoegingstabel. Het is dan wel nodig de hoofdtaalsjablonen aan te passen om te voorkomen dat deze vervoegingspagina's terecht komen tussen de gewone woorden in bijv. Categorie:Woorden in het Catalaans. Maar er zijn vast ook andere oplossingen te bedenken.

De kleur van de tabellen zou ik wel steeds hetzelfde houden (anders wordt het zo'n bonte boel), maar inhoudelijk is elke taal weer anders en kom je waarschijnlijk uit op verschillende modellen voor verschillende talen.

De kleine tabelletjes naast de woorden zelf: als er stamtijden bestaan, dan graag de stamtijden (zoals bijv. in het Nederlands). Als er geen stamtijden zijn, dan zou ik de meest gebruikte tijden nemen; het zal vast per taal verschillend zijn... (maar waarschijnlijk kom je uit op zoiets als: tegenwoordige tijd, verleden tijd, toekomende tijd of iets dergelijks.) -- Curious 7 dec 2011 23:52 (CET)

In plaats van {{=spa=}}, {{=cat=}} zou je bijvoorbeeld =={{cat}}== kunnen gebruiken. Jcwf 8 dec 2011 01:07 (CET)

Wat bedoel je precies met stamtijden? Ik denk zelf dat het handig is als er zoveel vormen staan dat een gebruiker makkelijk kan raden wat de andere vormen zijn, zonder naar een tabel te hoeven kijken. Maar dat is voor het Catalaans niet altijd even makkelijk omdat er zoveel onregelmatige werkwoorden zijn. De tegenwoordige en onvoltooid verleden tijd en het voltooid deelwoord zouden er dan minstens moeten staan denk ik, dat zou de grootste onregelmatigheden wel opvangen. —CodeCat 8 dec 2011 01:16 (CET)

Stamtijden zijn gedefinieerd als de kleinste groep vormen waaruit -indien men de regels kent- alle vormen van een (anderszins regelmatig) werkwoord geconstrueerd kunnen worden. In het Nederlands zijn dat er drie, in het Oudgrieks bijvoorbeeld 6, Latijn had er geloof ik 4, in het Frans dacht ik dat er 5 zijn maar dat is erg lang geleden voor mij. Voor cat of spa zou ik het echt niet weten.

Een van de redenen waarom we hier mee zijn gaan werken is dat het weergeven van alle vormen vaak een onbeholpen grote tabel oplevert, terwijl een selectie van vormen zal altijd een willekeurige selectie zijn -waar je heerlijk ruzie over kunt maken dus-, behalve de minimale (dwz de stamtijden). Op het Engelse net hebben ze dit probleem omzeild met uitklapboxen. Hier is in het verleden ooit besloten dat die bij verstel openstaan in plaats van dicht omdat er bezoekers waren die niet in de gaten hadden dat er ook nog nuttige info in de dichte uitklappen stond.

Een andere reden om stamtijden te vermelden is dat het gewoon handige hulpmiddelen zijn bij het leren van een taal, zeker als de werkwoorden vreselijk veel vormen hebben, zoals bij het Oudgrieks. Jcwf 8 dec 2011 04:37 (CET)

P.S. Voor het Spaans schijnen er drie te zijn.

Voor het Catalaans zouden het in principe ook die drie kunnen zijn. De 'passat' wordt echter niet zoveel gebruikt in het Catalaans, of althans niet door het werkwoord te verbuigen, maar met een hulpwerkwoord. Daarom lijkt het me handiger om de onvoltooid verleden tijd (imperfet) als tweede vorm te nemen. Voor regelmatige werkwoorden is die weliswaar voorspelbaar aan de hand van de infinitief, maar voor een aantal onregelmatige niet altijd. Daarnaast is de aanvoegende wijs van onregelmatige werkwoorden in het Catalaans ook soms moeilijk te voorspellen. Voor een vollediger overzicht kun je kijken op en:Appendix:Catalan verbs. —CodeCat 8 dec 2011 11:28 (CET)

Ik heb nu cantar aangepast en een tabel toegevoegd op cantar/vervoeging. Het is niet echt heel overzichtelijk, en dit probleem wordt natuurlijk erger als de andere Romaanse talen er ook nog bij komen. Meerdere tabellen op een pagina kan wel, maar is het niet beter om voor elke taal een aparte deelpagina te maken? Dan zou de Catalaanse vervoeging op cantar/vervoeging/Catalaans verschijnen, de Spaanse op cantar/vervoeging/Spaans enzovoorts. —CodeCat 8 dec 2011 14:18 (CET)

Ik heb nog een vraagje. Op Wiktionary worden alle sjablonen die voor een taal gebruikt worden apart gegroepeerd, zoals in en:Category:Dutch templates. Op WikiWoordenboek vind ik alleen Categorie:Werkwoordsjablonen, zonder onderverdeling naar taal. Ik kan me voorstellen dat dat op den duur erg onoverzichtelijk gaat worden, zeker omdat de naamgeving niet altijd consistent is voor zover ik kan zien... —CodeCat 8 dec 2011 13:34 (CET)

Welke Catalaanse werkwoordstijden het meest geschikt zijn voor in het tabelletje zou je denk ik het best zelf kunnen beoordelen (ik kan er in ieder geval niks zinnigs over zeggen :) ). Het hoeft ook niet bij 3 tijden te blijven, je zou er ook meer kunnen noemen, mocht je dat nodig vinden.

Ik twijfel over aparte subpagina's (zoals cantar/vervoeging/Catalaans, cantar/vervoeging/Spaans) voor de vervoegingen. Dat is een grote wijziging van hoe we nu werken, en het zal (op de lange termijn) ook een heleboel extra pagina's in de hoofdnaamruimte opleveren. Ik weet niet of we daaraan moeten beginnen. Het valt nu nog wel te overzien op pagina's als cantar/vervoeging, voorlopig slechts Spaans en Catalaans. Een groter probleem worden waarschijnlijk de gewone pagina's in de hoofdnaamruimte, daar komen steeds meer talen per pagina, en per taal komt er steeds meer informatie, leidend tot overvolle pagina's. Daar zal op den duur ook een oplossing voor moeten komen, misschien wel in de vorm van zoiets als de Tabbed Languages van Yair Rand op en.wikt. Het probleem van ".../vervoeging" geldt dus evengoed voor de gewone pagina's. Voorlopig zou ik het daarom denk ik houden bij de oplossing van Jcwf, en =={{cat}}== & =={{spa}}== boven de vervoegingstabellen toevoegen.

De sjablonen categoriseren per taal vind ik een goed idee. Zo zal beter zichtbaar zijn welke sjablonen beschikbaar zijn voor een bepaalde taal en via interwiki's kan er bijv. ook makkelijker bij de buren sjablonen bekeken/vergeleken/overgenomen worden. -- Curious 9 dec 2011 23:41 (CET)

Bedankt dat je mijn vragen hebt beantwoord Curious. Het probleem dat er veel talen op een pagina staan is inderdaad veel groter op de Engelse Wiktionary, maar ik vind de oplossing die ze hebben gekozen niet zo handig. Met Javascript vermijd je namelijk niet dat de pagina's te lang worden, je moet immers eerst de hele pagina in je browser laden voordat het script de verdeling in talen kan toepassen. Datzelfde probleem treedt daar ook op bij vervoegingstabellen. Daarnaast werkt het helemaal niet als Javascript is uitgeschakeld. Ik zou dus zelf willen voorstellen om de talen elk een aparte deelpagina te geven, ongeveer zoals ik al voorstelde bij de vervoegingstabellen. Bijvoorbeeld cantar/Spaans of cantar/es. Wat er dan op cantar zelf zou moeten staan weet ik niet, misschien dat daar een script gebruikt kan worden om een lijstje van beschikbare talen weer te geven? Ik begrijp dat dit een heel grote verandering is, maar het heeft wel veel voordelen, en we hebben op het Nederlandse WikiWoordenboek wel het voordeel dat er minder materiaal is om aan te passen. —CodeCat 10 dec 2011 16:19 (CET)

[2] Bots

Voor het Nederlands hebben we wel bots ingezet, voor andere talen bij mijn weten nog niet. Ik zie geen bezwaar voor de botmatige aanmaak van andere talen. Als woorden zoals canto, cantes, canta etc. worden aangemaakt, zou het wel fijn zijn als het hoofdwoord cantar ook daadwerkelijk bestaat (wat in dit geval zo is :) ) Als het hoofdwoord nog niet bestaat, dan liever ook geen woordvormen als canto. Daarnaast zou handig zijn als de bot een sjabloon plaatst (i.p.v. platte tekst), zodat evt. veranderingen achteraf simpel via dat sjabloon kunnen. -- Curious 7 dec 2011 23:52 (CET)

Zo zou het inderdaad ook wel werken. Ik heb al een bot voor Wiktionary, en die gebruikt de informatie in de sjablonen die de vervoegingstabellen aanmaken. Hoe dan ook moet die tabel dus eerst bestaan, en dat betekent dus dat het hoofdwoord ook altijd bestaat. —CodeCat 8 dec 2011 01:05 (CET)

Inderdaad, op li.wikt is ook veel gebruik gemaakt van bots om de oude, ongeordende site te vervangen door de huidige en dat ging ook goed, dus ik zie geen reden om het hier niet ook te doen om nieuwe bestanden aan te maken. --Ooswesthoesbes 8 dec 2011 09:18 (CET)

[3] Gereconstrueerde talen

We hebben geen Appendix naamruimte, maar volgens mij is het te overwegen om die toch maar aan te vragen. Het lijkt me goed om onderlinge werkafspraken (WikiWoordenboek naamruimte) te scheiden van aanvullende informatie voor lezers (Appendix naamruimte).

Om recht te doen aan de auteurs van die pagina's zou het misschien beter zijn om die pagina's te importeren i.p.v. de tekst te kopiëren. -- Curious 7 dec 2011 23:52 (CET)

Op Wiktionary gaan er ideeën rond om de naamruimte voor gereconstrueerde talen juist af te schaffen, en ze in de hoofdnaamruimte te plaatsen. Dat is nog niet definitief en het ziet er ook niet naar uit dat het gaat veranderen, maar omdat hier nog geen afspraak is kunnen we meteen kijken wat het beste werkt. —CodeCat 8 dec 2011 01:03 (CET)

Er zijn tot dusver een handvol woorden in ine of gem, en gewoon in de hoofdruimte, maar wel met een sterretje. Erg ontwikkeld is ons formaat op dat punt dus niet. Wat mij betreft mag het best in de hoofdruimte blijven als er maar duidelijk is dat de een het best anders kan reconstrueren dan de ander. Ik weet gewoon niet genoeg van die materie af om dat zinnig aan te geven. Er ligt dus een schone taak voor je CodeCat! Welkom aan boord! Jcwf 8 dec 2011 01:12 (CET)

Angolaan/Angolees

Hoi, ik probeer demoniemen te genereren. Nu vraag ik me af of een inwoner van Angola een Angolaan [15] of een Angolees [16] heet. Of beide, net als Birmaan/Birmees? - Difool 13 dec 2011 23:20 (CET)

Angolees lijkt mij zelf waarschijnlijker, maar dat komt misschien omdat het lijkt op Congolees. —CodeCat 14 dec 2011 00:16 (CET)

Hmmf, de Taalunie weer eens dus. Google geeft +/- 1040 voor Angolanen en 30.000 voor Angolezen. De sprekers van onze taal zijn het dus grotendeels met je eens CodeCat. Misschien beide vermelden met een -note- dat Angolezen gebruikelijker is? Jcwf 14 dec 2011 03:23 (CET)

nl.Wikipedia over het miljoen

Een heuglijk feit waarmee we onze collega's van nl.wiki natuurlijke van harte feliciteren!

Uit de begintijd van nl.wiki kan ik me nog veel 'bijdragen' herinneren in de trant van: "Belachelijk om dit in het Nederlands te doen! Dat wordt noooit wat! Blijkbaar lopen dat soort lieden nog steeds rond en gaan ze nu trachten via de Engelse wiki af te dwingen dat alles een vertaling uit het Engels moet zijn

Uiteraard heeft de gebruiker die dit fraais voorstelt zelf nog nooit ene klap uitgevoerd... Jcwf 17 dec 2011 22:07 (CET)

Open Call for 2012 Wikimedia Fellowship Applicants

I apologize that you are receiving this message in English. Please help translate it.

• Do you want to help attract new contributors to Wikimedia projects?
• Do you want to improve retention of our existing editors?
• Do you want to strengthen our community by diversifying its base and increasing the overall number of excellent participants around the world?

The Wikimedia Foundation is seeking Community Fellows and project ideas for the Community Fellowship Program. A Fellowship is a temporary position at the Wikimedia Foundation in order to work on a specific project or set of projects. Submissions for 2012 are encouraged to focus on the theme of improving editor retention and increasing participation in Wikimedia projects. If interested, please submit a project idea or apply to be a fellow by January 15, 2012. Please visit https://meta.wikimedia.org/wiki/Wikimedia_Fellowships for more information.

Thanks!

--Siko Bouterse, Head of Community Fellowships, Wikimedia Foundation 22 dec 2011 03:58 (CET)

Distributed via Global message delivery. (Wrong page? Fix here.)

murw

Ik vraag me op het moment af hoe dit woord wordt uitgesproken. Ik weet dat veel mensen van de -w een -f maken en dus /mʏrf/ zeggen, maar hoe zit het met de verbogen vorm 'murwe', waar de w niet meer aan het eind staat? Wordt er dan wel /mʏrʋə/ gezegd of toch /mʏrvə/ naar analogie van de onverbogen vorm? En hoe zit het met het afgeleide werkwoord vermurwen? —CodeCat 23 dec 2011 16:18 (CET)

Hangt van de regio af. In Limburg zegt men traditioneel /mʏrw/ /vɛrˈmʏrwə(n)/, maar dit wordt minder, net als /ɛrwt/ :) In het noorden zegt mijn volgens mij /mʏrf/ /mʏrvə/ (of /mʏrfə/ in sommige dialecten) en /və(r)ˈmʏrvə/. --Ooswesthoesbes 23 dec 2011 16:21 (CET)

Ik denk dat het vooral afhangt van de uitspraak van de w, of die bilabiaal is of labiodentaal. Ik spreek zelf de w eigenlijk wisselend als allebei uit (de bilabiale w is meer Brabants, de labiodentale meer Standaardnederlands). Heeft het Limburgs een bilabiale w? —CodeCat 23 dec 2011 16:25 (CET)

Het is eigelijk zelfs ingewikkelder. Er zijn niet twee vormen w in het Nederlands maar drie. In het Noorden heeft men labiodentaal: ʋ. Brabant, Vlaanderen, West- en Noord-Limburg en Maastricht hebben de bilabiaal approximant: β̞. Suriname, Midden-Limburg ten oosten van de Maas, Maaskant en Parkstad hebben de labio-velare approximant: w (zoals in het Engels: "witch"). Ik weet niet precies of het ermee samenhangt. Zelf denk ik dat het komt doordat Limburgs altijd al meer naar de spelling uitspreken ("gëwoon" i.p.v. Noord-Nederlands "ghõw"). Hoe het precies in Brabant zit kan ik niet veel over vertellen. --Ooswesthoesbes 23 dec 2011 16:32 (CET)

Feestdagen

De beste wensen!

Fijne feestdagen & (alvast) een gelukkig nieuwjaar allemaal! -- Curious 26 dec 2011 13:20 (CET)

Categorieën zonder interwiki

Hallo allen, Ik heb afgelopen middag een botrun gedaan en aan alle categorieën die geen interwiki hebben (in het Duits, Engels, Frans of Portugees) het sjabloon:Geen interwiki toegevoegd die de categorieën aan Categorie:WikiWoordenboek:Categorie zonder interwiki-link toevoegt. Het zou mooi zijn als we meer categorieën weten te koppelen aan de categorieën hiervoor op de anderstalige Wiktionaries. Groetjes - Romaine 9 jan 2012 02:12 (CET)

Sjablonen met infobox-code

Niet al te lang geleden bleek dat de nieuwste versie van Firefox last geeft door het tonen van zwarte tabelcelranden, terwijl er grijze bedoeld werden. Daartoe werd in de MediaWiki:Common.css code gezet zodat dit probleem verholpen kon worden als we overal een class gebruiken in tabellen, in plaats van de code zelf voor de opmaak (die niet altijd goed werkt). Vandaag heb ik alle sjablonen nagelopen op het gebruik van bgcolor="#FFFFE0". Vrijwel alle sjablonen waarin nog deze bgcolor rechtstreeks werd ingevoegd heb ik omgebouwd. Overal zou het er nu dus zo kraakhelder moeten uitzien zoals op bv Sjabloon:-nlnoun-. In plaats van bgcolor gebruiken we voortaan overal een class:

• {| class="infoboxlinks" -> voor een tabel die tegen de linker kantlijn wordt uitgelijnd.
• {| class="infobox" -> voor een tabel die tegen de rechter kantlijn wordt uitgelijnd.
• | class="infoboxrijhoofding" | -> voor het geven van de lichtgele achtergrondkleur aan een cel.

Gebruik voor kopcellen in een tabel slechts ! zonder een class. Zie Sjabloon:-nlnoun- als voorbeeld: daar zijn enkelvoud en meervoud de kopcellen (vette tekst) en naamwoord en verkleinwoord de cellen met een lichtgele achtergrond (niet-vette tekst).

Zou mooi zijn als we dit zo in stand kunnen houden. PS: Annabel: mooi werk voor het instellen van deze code! :-) Romaine 10 jan 2012 18:47 (CET)

En alle categorieën heb ik hierop vandaag nagelopen en hierop aangepast. Romaine 11 jan 2012 16:19 (CET)

Top! Toen ik de bewuste opmaakcodes introduceerde, merkte ik dat de opmaak nog niet altijd uniform was. Sommige rij- en kolomhoofdingen waren cursief. Heb je zo'n trends ook waargenomen? Kunnen we deze nog uniformiseren? (dus de wiki-accentjes voor cursieve tekst weghalen) Annabel_(overleg) 12 jan 2012 17:25 (CET)

Daar heb ik niet echt op gelet. Ik herinner me wel enkele kolom- en rijhoofden die cursief waren, maar echt consistentie was daar niet in zover ik bemerkt heb. Misschien is het handig er voor te zorgen dat er voor iedere onderwerpengroep van sjablonen het minstens gelijkgetrokken wordt, maar dit is veel lastiger op te zoeken omdat een kleurcode eenvoudiger te vinden is. Ik denk dat we daar in ieder geval niet te veel tijd moeten steken, tenzij het automatisch kan. Groetjes - Romaine 13 jan 2012 10:49 (CET)

Veel tijd mag het ook niet kosten als er iets gedaan wordt. Het enige waar ik aan denk, is een vervanging met reguliere expressies die 'tjes weghaalt in tabellen. Annabel_(overleg) 13 jan 2012 17:13 (CET)

• Done: Alle pagina's in de WikiWoordenboek-naamruimte heb ik hier ook op nagelopen. Romaine 4 feb 2012 01:36 (CET)

Woordenboekingangen met sjabloon zonder ingevulde taal

Ik denk dat het zinvol is om aan de kopje-sjablonen adjc, adverb, name en noun altijd een taalcode mee te geven, omdat op die manier artikelen worden toegevoegd aan een categorie voor bijvoorbeeld een werkwoord. Ten behoeve daarvan heb ik de Categorie:WikiWoordenboek:Pagina's met sjabloon zonder ingevulde taal aangemaakt die automatisch via deze drie sjablonen wordt ingevoegd. Groetjes - Romaine 13 jan 2012 11:34 (CET)

Momenteel 82.942 items die nog een taal behoeven. Bot loopt om dat in te vullen. Romaine 13 jan 2012 11:59 (CET)

Bei Deklinationsformen und Konjugationsformen (verbuigingsvormen) haben wir bisher bei der Kopfschablone kein ISO-Kürzel zugsetzt, damit KEINE Zuordnung zu den Categorien für Verben und Substantive erfolgt. Diese Zuordnung erfolgt normalerweise durch die Verbuigingssjablone und nur wenn diese fehlt durch die Kopfschablone. Die betreffenden Wortartkategorien werden riesig und sehr unübersichtlich, wenn alle verbuigingsvormen erfasst werden. Nach meiner Meinung ist dieser Weg nicht sinnvoll. Die Verbuigingsformen sollten nach meiner Meinung weiterhin nicht in den Wortkategorien erfasst werden. -- Cadfaell 13 jan 2012 12:25 (CET)

Ik probeer te snappen wat je bedoelt. Heb je een voorbeeld van een artikel van wat je liever niet in de categorie van woordsoort naar taal terecht ziet komen? Bedoel je dan bv een meervoudsvorm zoals afschaffingen? Romaine 13 jan 2012 12:38 (CET)

Alle deze zelfstandige naamwoorden zijn niet in de categorie van de zelfstandige naamwoorden en alle deze werkwoorden zijn gewild niet in de categorie van de werkwoorden geregistreerd, bijv. aanwezigen of aanbakkend. -- Cadfaell 13 jan 2012 12:59 (CET)

Mmm, daar had ik niet bij stilgestaan (al had ik die tot op heden overgeslagen). Dan heeft dat dus ook betrekking op Categorie:Bijvoeglijk-naamwoordsvorm in het Nederlands? Romaine 13 jan 2012 13:11 (CET)

Zou het misschien werken om aparte sjablonen voor niet-lemma's te hebben? —CodeCat 13 jan 2012 13:14 (CET)

Wat bedoel je precies met "niet-lemma's"? Kun je een voorbeeld geven eventueel? Romaine 13 jan 2012 13:19 (CET)

Ik bedoel woorden die een verbogen of vervoegde vorm van een ander woord zijn. In het Nederlands dus werkwoordsvormen (die geen infinitief zijn), de verbogen vorm, partitief en trappen van vergelijking van een bijvoeglijk naamwoord, en van een zelfstandig naamwoord de meervoudsvorm en eventueel ook het verkleinwoord (hoewel verkleinwoorden ook een soort lemma zijn omdat ze een eigen geslacht hebben, en soms is er niet eens een basiswoord). —CodeCat 14 jan 2012 13:47 (CET)

Ter verduidelijking: als ik een Russisch lemma als молодец aanmaak zet ik er in de regel ook een blok met naamvallen op mbv {{-runoun1-}} en dan komt het woord dus in categorie:Zelfstandig naamwoord in het Russisch te staan. Is het je bedoeling dat je dan alsnog {{-noun-|rus}} schrijft? Kan, hoor. De cat komt er toch maar een keer op te staan, maar het is wat overbodig. We zouden natuurlijk ook de cats uit de bloksjablonen kunnen halen. Zeg maar. Jcwf 14 jan 2012 22:09 (CET)

Ja, dat staat hieronder bij Voorstel 1: woordsoort-sjablonen. De reden hiervoor is dat op die manier deze sjablonen gekoppeld worden aan een taal en wat er voor zorgt dat overal waar een dergelijk sjabloon is ingevoegd de pagina in een taalspecifieke woordsoort-categorie terecht komt. Bij een deel van de woordenboekingangen wordt dit al gedaan door middel van bv -runoun1-, maar dat is lang niet overal het geval. Een dubbele categorie op een woordenboekingang is niet erg, de software corrigeert dat vanzelf, maar een ontbrekende categorie niet, daar moeten we zelf voor zorgen, wat kan door overal een taalcode in te voegen (eventueel met nocat). Groetjes - Romaine 14 jan 2012 23:50 (CET)

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 {{Tl|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)

 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=}}: [17] identiek.
• Sami: {{smi}} / {{=smi=}}: [18] 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=}}: [19] identiek.
• West-Germaans: {{gmw}}: [20] identiek.
• Indo-Europees: {{ine}}: [21] identiek.
• Romansh: {{rsh}}: [22] 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. [23] 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, [24]. 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: [25] .

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 {{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 {{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 {{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)