Wikipedia:De kroeg

Voor het aanduiden van een afbeelding binnen een wikipedia-artikel zijn de technische mogelijkheden in ieder geval: 'File', 'Image', 'Bestand' of 'Afbeelding'. Naar mijn mening is het prima om daarbij te kiezen voor een Nederlandstalige aanduiding, dus 'Bestand' of 'Afbeelding'. Daarbij zijn m.i. beide Nederlandstalige mogelijkheden gelijkwaardig, zolang maar consequent een van beiden binnen een artikel toegepast wordt. (Mijn eigen voorkeur is 'Afbeelding' omdat dat duidelijker is, en een onderscheid geeft ten opzichte van andere bestanden, zoals filmpjes.) Dat betekent dan dat het 'BTNI' zou zijn om hierin iets te wijzigen in die gevallen waarin binnen een artikel consequent één van beide genoemde aanduidingen wordt toegepast. En toch zien we dergelijke wijzigingen gebeuren, uitgevoerd door gebruikers en door 'bots'. Hoe denken andere gebruikers hier over? Zie ook Overleg gebruiker:Romaine#BTNI. - Bob.v.R (overleg) 20 mrt 2024 00:46 (CET)Reageren

Heb altijd begrepen dat we hier in principe 'bestand' gebruiken. Weet niet zeker of daar een discussie of richtlijn aan ten grondslag ligt. Nu is dit wat mij betreft geen belangrijk issue om structureel na te lopen en te wijzigen, maar het komt wel voor dat ik dit samen met andere wijzigingen meepak bij een update van een artikel. GeeJee (overleg) 20 mrt 2024 00:56 (CET)Reageren

Ik heb onlangs op de helpdesk dezelfde vraag gesteld. Wat GeeJee hier zegt klopt. De voorkeur wordt gegeven aan “Bestand”. De argumenten hiervoor zijn niet ijzersterk, maar ze bestaan. –Frank Geerlings (overleg) 20 mrt 2024 01:04 (CET)Reageren

Sommigen vinden het fijner alles precies volgens strikte zo klein mogelijke boxjes in te delen. Ik kies voor generiek. "Bestand" is generiek en eenduidig. Het is hopeloos om allerlei varianten voor hetzelfde aan te houden: het leidt tot willekeur op basis van persoonlijke voorkeuren, al dan niet OCD gedreven - en daarmee tot BTNI confkixten.zijn. Labrang (overleg) 20 mrt 2024 01:13 (CET)Reageren

Ik heb het even opgezocht en het blijkt dat dit gewoon weer even iets oprakelt wat door deze zelfde personen al besproken is. Help:Helpdesk/Archief/dec 2023#Waarom is Bestand: beter dan Afbeelding:?. Ik negeer het verder. –Frank Geerlings (overleg) 20 mrt 2024 01:26 (CET)Reageren

Afbeelding maakt duidelijk dat het om een afbeelding gaat. ChristiaanPR (overleg) 20 mrt 2024 21:26 (CET)Reageren

Er zijn diverse voorbeelden van (oud)medewerkers die hier (soms zelf toegegeven) OCD-gedreven bewerkingen deden, en ik heb er een broertje dood aan. Maar zoveel mogelijk 'Bestand:' gebruiken valt daar wat mij betreft niet onder. Bij het plegen van onderhoud in de broncode van pagina's is het vrij vervelend om te moeten zoeken naar 'File:', 'Image:', 'Afbeelding:' of 'Bestand:' om alle afbeeldingen te kunnen vinden (vooral bij grote pagina's met veel afbeeldingen). Er is minstens één bot die bij het uitvoeren van zinvolle klussen en passant ook die namen aanpast naar 'Bestand:' en ik denk dat dat de facto bij ons de standaard is geworden. Ik sta er wel achter als die verandering ook door andere medewerkers wordt meegenomen. Wat de betekenis van de vier woorden precies is, doet er weinig toe omdat ze exact hetzelfde uitvoeren, en voor de lezer niet zichtbaar zijn. Ik vind de verandering te futiel om je er zo over op te winden. WIKIKLAAS overleg 20 mrt 2024 22:21 (CET)Reageren

Als 'bestand' zo belangrijk is, dan moet iemand Commons even melden dat de aangeboden linkjes naar afbeeldingen niet meer met 'File' moeten beginnen. Zo blijf je immers bezig. Ik vervang zelf altijd handmatig File door Bestand, maar dat is vooral omdat ik nogal moe werd van al die aanpassingen in door mij gestarte artikelen.... Elke keer weer een melding als iemand een in mijn ogen volkomen nutteloze aanpassing van een woordje deed..... Thieu1972 (overleg) 20 mrt 2024 22:58 (CET)Reageren

Je moet wel accepteren dat andere mensen in hetzelfde artikel wijzigingen aanbrengen als dat jij hebt gedaan. Schrijffouten en fouten in de grammatica mogen worden gecorrigeerd. ChristiaanPR (overleg) 20 mrt 2024 23:06 (CET)Reageren

Maar dat is nu net het punt: het lijkt helemaal geen correctie te zijn. Er wordt iets aangepast omdat, uh, nou, geen idee? Het is in dit geval file->bestand, maar ook het toevoegen van enters (die de VE juist heeft weggehaald). Het komt over als bezigheidstherapie om zaken die Wikimedia zelf softwarematig aanbiedt, handmatig te gaan zitten aanpassen in alle artikelen. Thieu1972 (overleg) 21 mrt 2024 06:51 (CET)Reageren

Ik ben net zo goed als jij weer bezig, zegt mij niets. ChristiaanPR (overleg) 21 mrt 2024 07:06 (CET)Reageren

Ik kopieer altijd alleen het gedeelte achter File:. Of je nu de hele titel of hele titel minus 5 karakters met de muis selecteert kan het verschil in werk ook niet uitmaken. Labrang (overleg) 20 mrt 2024 23:07 (CET)Reageren

ik in een <gallery> ook ChristiaanPR (overleg) 20 mrt 2024 23:15 (CET)Reageren

Voor iemand als ik, die moeite heeft met het richten van de muis, is er wel verschil in werk. Ik selecteer de titel met een drievoudige klik, dat kan ik wel goed, en na het plakken ga ik met de cursortoetsen naar voren om File te selecteren en in Bestand te veranderen. Niet problematisch, maar wel een irritante aanpassing aan de zeloten  →bertux 21 mrt 2024 11:35 (CET)Reageren

De Engelse naamruimte heeft 'File', de Nederlandse naamruimte heet 'Bestand'. De Engelse benamingen in de Mediawiki software werken overal, en is er een lokale voorkeur ingesteld dan overschrijft deze de Engelse variant. Omdat we in een ver verleden "Afbeelding" gebruikten waar we het nu "Bestand" noemen is dit alternatief behouden (zodat we niet alle artikelen aan hoefden te passen om bestanden ingeladen te houden), en is het voor uniformiteit een bewerking die meegenomen wordt in bv AWB, mits er ook andere bewerkingen gedaan worden in het artikel (zoals ook te zien in de link die Bob geeft). Een lezer ziet het verschil niet. Zelf gebruik ik vaak "User:" in plaats van "Gebruiker:" omdat het sneller typt; hetzelfde voor als ik handmatig de naamruimte voor bestanden op moet geven, dan in "File:" simpelweg de kortste. Dat er dan iemand anders na mij komt die dat verandert, maakt mij niet uit.

Als je meldingen ('pings') krijgt van dat soort wijzigingen kan ik me de ergernis voorstellen Thieu, maar bedoel je misschien een vermelding in je volglijst? Dat is dan toch niet zo erg? Ik zie wel het voordeel van enige uniformiteit, maar het is voor mij teveel moeite omdat het effect niet veranderd. Als er dan iemand met de bezemwagen achter mij aan hobbelt, is dat juist beter voor mijn gemoedsrust. 🙂 Ciell need me? ping me! 21 mrt 2024 12:04 (CET)Reageren

Ik negeer de volglijst (een draak van een ding) en krijg mailtjes van elke wijziging. En ik kijk die wijzigingen ook altijd even na, om te zien wat er aangepast is. En als dat dan de in mijn ogen volledig onnodige wijziging betreft File->Bestand, dan irriteert dat na de zoveelste keer wel een beetje, ja. Ook omdat Commons mij gewoon de link mét File erin aanbiedt. Net zoals de VE de wikilinkjes soms wat knullig aanmaakt, waarna mensen die dan handmatig massaal gaan nalopen en aanpassen. Kan zoiets dan niet beter gewoon gecorrigeerd worden in de software? Het komt mij over als vrij zinloos werk dat eenvoudig voorkomen kan worden. En nog steeds snap ik niet waaróm het per se Bestand moet zijn... Thieu1972 (overleg) 21 mrt 2024 12:18 (CET)Reageren

Ik vind ook dat dat een onnodige wijziging is, op zichzelf dan. Als ik een grotere wijziging doe, neem ik die aanpassing wel eens mee, maar ik zou nooit alleen “File” in “Bestand” gaan veranderen, want mijns inziens grenst dat teveel aan BTNI. Mondo (overleg) 21 mrt 2024 12:29 (CET)Reageren

Wat mij betreft mogen al die onhandige Nederlandse namen verdwijnen: File, User, Special en thumb zijn allemaal korter dan die stomme vertalingen, die bovendien in de weg zitten als je een file, user of page in een ander project wilt hergebruiken of aanspreken.

@Thieu1972: de volglijst met de optie Volglijst uitbreiden om alle wijzigingen te tonen, en niet alleen de recentste vind ik wél handig in gebruik, vooral in combinatie met de pop-ups: je zet de muis even op wijz en ziet meteen wat je over kunt slaan. Bij twijfel uitklappen om de individuele wijzigingen te bekijken, weer met de pop-ups. Mailmeldingen heb ik alleen aanstaan voor projecten waar ik zelden kom, en dan nog gegroepeerd per dag of week. Bij jouw werkwijze zou ik tientallen tot honderden mailtjes per dag krijgen, een nachtmerrie  →bertux 21 mrt 2024 12:30 (CET)Reageren

Het valt mee 😉 En het valt ook slechts in de categorie 'klein leed'. Maar ik snap het gewoon niet zo goed waarom die naampjes per se aangepast moeten worden. Thieu1972 (overleg) 21 mrt 2024 12:35 (CET)Reageren

@Wikiklaas, je geeft aan: "Bij .... is het vrij vervelend om te moeten zoeken naar 'File:', 'Image:', 'Afbeelding:' of 'Bestand:' om alle afbeeldingen te kunnen vinden." Wat je vindt met 'Bestand' is alle bestanden, dus inclusief de filmpjes. Als de afbeeldingen in een artikel consequent worden aangeduid met 'Afbeelding' dan is het juist beter mogelijk om specifiek de afbeeldingen te vinden. Bob.v.R (overleg) 21 mrt 2024 12:38 (CET)Reageren

Nee, vrijwel overal op Wikipedia wordt consequent Bestand: gebruikt. Dat er dan in een handjevol artikelen van een enkele gebruiker opeens een ander voorvoegsel wordt gebruikt is niet behulpzaam om afbeeldingen en andere bestanden snel met de zoekfunctie terug te vinden in de brontekst. Met andere woorden, het toepassen van het voorvoegsel Afbeelding: is suboptimaal: voor één gebruiker en voor die kleine groep artikelen lijkt het optimaal, maar het is nadelig voor alle andere gebruikers die even snel op een bestand willen zoeken met de zoekfunctie en daarbij eerst moeten weten welke auteur in de grote encyclopedie (onnodig) hierop afwijkt en dan per artikel eerst in de geschiedenis moeten gaan kijken om te zien of die gebruiker daar actief is geweest. Romaine (overleg) 27 mrt 2024 11:58 (CET)Reageren

Vraag: waarom wil je zoeken naar een bestand? Thieu1972 (overleg) 27 mrt 2024 13:50 (CET)Reageren

Ik zoek naar bestanden om een verwijderd bestand uit een artikel weg te halen, om parameters van de bestanden te repareren, de uitlijning te regelen en om in een pagina de onderschriften met elkaar te vergelijken en op elkaar af te stemmen. Romaine (overleg) 27 mrt 2024 14:09 (CET)Reageren

Het lijkt dan toch het beste om de bron aan te pakken: Commons. Die levert immers kant-en-klare URL's af die 'File' en 'thumb' etc bevatten. Van gebruikers kun je niet verwachten dat ze weten/onthouden welke termen ze dienen aan te passen - vergeet immers niet dat 'File' an sich geen foute term is. Thieu1972 (overleg) 27 mrt 2024 18:46 (CET)Reageren

Omdat we op NL:WP zitten. Maar goed, heel erg consistent zijn we er ook niet in, want File → Bestand is een gebruikelijke verandering, maar DEFAULTSORT → STANDAARDSORTERING zie ik dan weer niemand doen (en ik denk daar zelf ook nooit aan), ondanks dat laatstgenoemde ook bestaat. Mondo (overleg) 21 mrt 2024 12:39 (CET)Reageren

Die laatste is eigenlijk pas zichtbaar sinds een recente (2023) fix, waarbij VE de DEFAULTSORT als sjabloon zag en niet als de sorteersleutel. Zelf gebruik ik DEFAULTSORT (die zit zo ingebakken), maar VE gebruikt STANDAARDSORTERING. Mbch331 (overleg) 21 mrt 2024 12:50 (CET)Reageren

A, goed om te weten! 🙂 Mondo (overleg) 21 mrt 2024 13:03 (CET)Reageren

Toen ik voor het eerst iets met een afbeelding wilde doen, keek ik naar de Wiki-code van een ander artikel dat een afbeelding had. Daar stond [[file:naam.jpg|thumb|tekst]]. Ook als je een bestand aan commons toevoegt met de upload wizzard krijg je als voorbeeld hoe bestand te gebruiken [[file:naam.jpg|thumb|tekst]] te zien, met één klikje te copiëren. Op commons is alles verder Nederlands, maar bij de bestandsnaam staat dus "file:" en niet "bestand:", ondanks de Nederlandse taal-instelling op commons. Moet dat niet veranderd worden op commons? FredTC (overleg) 21 mrt 2024 13:19 (CET)Reageren

Precies mijn vraag dus. Thieu1972 (overleg) 21 mrt 2024 13:23 (CET)Reageren

Oeps, even niet goed opgelet, sorry. FredTC (overleg) 22 mrt 2024 02:16 (CET)Reageren

Was geen kritiekpuntje hoor. Ik had gewoon dezelfde vraag 🙂 Thieu1972 (overleg) 22 mrt 2024 10:02 (CET)Reageren

@Mbch331 - Is het dan beter om STANDAARDSORTERING te gebruiken? Ik heb namelijk mijn bot voor de archieflinks gereanimeerd, en ik zou dit dus mee kunnen nemen als de bot een pagina bewerkt om een andere reden. Wikiwerner (overleg) 21 mrt 2024 18:41 (CET)Reageren

In mijn ogen niet. VE kan met beiden overweg en vervangt niet het een voor het ander. Mbch331 (overleg) 21 mrt 2024 18:47 (CET)Reageren

Is deze discussie niet een uitstekend voorbeeld van de Trivialiteitswet van Parkinson (ook wel "the colour of the bike shed" ) ? Saschaporsche (overleg) 21 mrt 2024 17:37 (CET)Reageren

@Wikiklaas, Romaine en ieder ander die worstelt met dit onderhoudsprobleem: met de add-on Multi Find kun je een webpagina tegelijkertijd op meerdere termen doorzoeken. Wanneer je bijvoorbeeld "Bestand", "File", "Afbeelding" en "Image" intikt, zullen die vier zoektermen gelijktijdig oplichten in de pagina, dus dat lijkt me de perfecte oplossing voor dit probleem. — Matroos Vos (overleg) 27 mrt 2024 19:57 (CET)Reageren

Spannend, die Multi Find … In het begin vond hij helemaal niets, maar na een uurtje gaat het bij veel pagina's wel, in de versie voor Chrome. Alleen nog niet in onze VE of het bewerkingsvenster voor broncode. Dat haalt met pijnlijke nauwkeurigheid deze toepassing onderuit. Morgen krijgt hij een herkansing  →bertux 27 mrt 2024 20:59 (CET)Reageren

Die enkele keer dat ik in de kroeg kijk, zie ik een mooie tip voorbij komen. Ik wist niet dat ik ernaar zocht, maar ik vind het toch heel erg handig. Dank, Matroos. hiro the club is open‍ 27 mrt 2024 21:56 (CET)Reageren

Graag gedaan. Ik moet trouwens met het schaamrood op de kaken erkennen dat Bertux gelijk heeft, en dat deze add-on inderdaad geen woorden in een bewerkingsvenster kan vinden. Ik gebruik Multi Find zelf alleen op 'gewone' webpagina's, en daarin kan hij moeiteloos meerdere zoektermen tegelijk vinden. Toen ik mijn tip hier postte, heb ik er geen seconde bij stilgestaan dat bewerkingsvensters weleens een gevalletje apart zouden kunnen zijn, al was het maar omdat de reguliere "Ctrl+F"-functie wel gewoon het bewerkingsvenster meeneemt. Bij wijze van wiedergutmachungsschnitzel heb ik net nog even een aantal gelijkaardige add-ons opgesnord en uitgeprobeerd, maar geen van alle kon overweg met ons bewerkingsvenster. Helaas, gatenkaas. — Matroos Vos (overleg) 28 mrt 2024 00:04 (CET)Reageren

Wat is eigenlijk het nut van die taalcodes (zoals deze (en) ) die soms bij bronnen en links worden vermeld? Zelf zie ik het nut er niet van in, aangezien het in het overgrote deel van de gevallen om iets in het Engels gaat en ook als het in het Duits, Frans, of Spaans is, dan zien de meeste mensen aan de titel toch wel om welke taal het gaat. Groeten, Paul2 (overleg) 20 mrt 2024 14:45 (CET)Reageren

Maar de minder taalvaardigen zien dat misschien niet zo makkelijk. En als een bron een wat minder bekende taal heeft dan is het ook een stuk moeilijker te zien. LeeGer 20 mrt 2024 15:46 (CET)Reageren

Maar dan kunnen ze het nog steeds niet lezen als die taalcode erbij staat. Automatische vertaling op je telefoon werkt ook en die vertelt welke taal het is. Hobbema (overleg) 20 mrt 2024 16:11 (CET)Reageren

Als er meerdere bronnen bij een artikel staan en een is Engels terwijl anderen bijvoorbeeld Frans of Hongaars zijn, dan kun je ervoor kiezen de Engelse bron te kiezen omdat je die wel kunt lezen maar die anderen niet. Zelfde voor links. LeeGer 20 mrt 2024 16:14 (CET)Reageren

Maar dan nog heb je niet het labeltje (en) nodig om te zien dat "Language policy is discussed at the village pump" in het Engels is en "In der Kneipe wird über Sprachpolitik gesprochen" in het Duits. Volgens mij is het nut hetzelfde als alle vlaggetjes bij nationaliteiten: het wordt toegevoegd omdat het kan, en het staat ook niet vreselijk in de weg. CaAl (overleg) 20 mrt 2024 16:19 (CET)Reageren

Mwa, ik vind het ook niet echt mooi, in lijstjes met links of bronnen staat die code vaak maar bij een paar, en dat maakt het beeld rommelig, terwijl de meerwaarde absoluut minimaal is. Bij vlaggetjes is het nog iets anders, omdat bij sportwedstrijden e.d. vaak veel meer landen meedoen dan het gering aantal talen dat hier vermeld en gelinkt wordt. Paul2 (overleg) 20 mrt 2024 16:24 (CET)Reageren

Ik zie dan weer nog minder het nut in van de vlaggetjes.. Dajasj (overleg) 20 mrt 2024 16:43 (CET)Reageren

Ik gebruik ook wel eens bronnen uit het Fins, Zweeds, Servisch en andere Slavische talen. Maar aan die titels zou ik niet weten welke taal dat is hoor. Het geeft de lezer of mensen die de bronnen opzoeken (zal niet veel zijn) een kans om direct te weten in welke taal het staat. Zoals vlaggetjes dat doen bv bij sporters, direct zichtbaar maken van iemands zijn nationaliteit of land waarvoor die uitkomt. Zeer handig als je bepaalde clubs, sporters enzo niet kent maar wel wil weten vanwaar zij kwamen. Themanwithnowifi (overleg) 20 mrt 2024 18:53 (CET)Reageren

Dat is ook de reden dat ik ze in het verleden al handig heb gevonden. MLTRock (overleg) 20 mrt 2024 19:44 (CET)Reageren

Maar dat gaat niet altijd op. Als de titel “Jan Hoet” is, maar na aanklikken is het een artikel over hem in het Engels, hoe weet je dat dan op basis van de titel? Ik maak wel vaker zulke dingen mee, dat iets in een andere taal is dan je op basis van de titel verwacht. Natuurlijk kun je dat in de titel verduidelijken, maar als niemand dat doet (en soms is dat ook moeilijk, want dan moet je gaan nadenken wat je moet gaan toevoegen aan de titel), is het wel zo fijn als je weet welke taal het is. Mondo (overleg) 21 mrt 2024 12:18 (CET)Reageren

De taalcode in het sjabloon {{Citeer web}} (en vergelijkbaar) kan helpen de spraak-assistentie te schakelen naar de juiste taal. Zo kan een titel worden uitgesproken voor bijvoorbeeld blinden of mensen die op de fiets naar Wikipedia luisteren. Dat betekent niet dat we die code ook zichtbaar moeten maken (en of het zichtbaar moet zijn, daar heb ik geen mening over). Maar de taalcode heeft dus meer toepassingen dan de meest voor de hand liggende (dus meer dan de al genoemde twee "om als Captain Obvious de lezer te helpen" en "omdat het kan").

Het is ook mogelijk de taalcode alleen zichtbaar te maken voor mensen die dat willen, of de taalcode juist onzichtbaar te maken voor mensen die dat willen. Ik ben daar geen fan van, maar het is eenvoudig te regelen. –Frank Geerlings (overleg) 20 mrt 2024 17:50 (CET)Reageren

Voor de liefhebber goed om te weten dat {{lang}} gebruikt kan worden om dit zelfde effect voor spraakassistentie te bereiken buiten {{Citeer web}}. Dit gebruiken we volgens mij nog te weinig (althans ik). Dajasj (overleg) 20 mrt 2024 20:29 (CET)Reageren

Als je regelmatig artikelen redigeert is het handig om van tevoren te zien of het zin heeft om een bron te openen. Zo kan Google Translate redelijk overweg met Koreaans, maar totaal niet met Japans. DeepL kan dat wel, maar die is gratis maar heel beperkt te gebruiken  →bertux 20 mrt 2024 19:37 (CET)Reageren

Het is inderdaad handig om direct te zien in welke taal een bron is geschreven (dit blijkt niet altijd meteen uit de link en/of omschrijving), zeker bij redigeerwerk of de controle op feitjes of relevantie. Thieu1972 (overleg) 20 mrt 2024 23:01 (CET)Reageren

Ik heb geen bezwaar tegen het vermelden van de taal. Waar ik wél ernstig bezwaar tegen maak is het vermelden van die taal helemaal vooraan. Alsof dat het belangrijkste is van de bron of referentie. En volgens mij moet dat toch echt de auteur ervan zijn, gevolgd door het jaar van uitkomen. Is er ergns een afspraak over de plek waar we de taal vermelden? WIKIKLAAS overleg 20 mrt 2024 23:06 (CET)Reageren

Kennelijk is dat helemaal vooraan, want ik kwam op dit onderwerp omdat de RomaineBot nu bezig is met die taalcodes te verplaatsen met de mededeling: "(Taalcodes vooraan bron, niet elders)" Paul2 (overleg) 21 mrt 2024 00:23 (CET)Reageren

En dat was exact waarom ik hier bezwaar maakte omdat ik nergens iets over een dergelijke afspraak kon vinden. Dus wat mij betreft stopt RomaineBot daar onmiddellijk weer mee. WIKIKLAAS overleg 21 mrt 2024 02:42 (CET)Reageren

Misschien handig om Romaine even te pingen om deel te nemen aan deze discussie. Saschaporsche (overleg) 21 mrt 2024 09:42 (CET)Reageren

De taalcodes (99,9% Engels/Duits/Frans/Nederlands) zijn hoogstens nodig bij een héél vreemde taal. Er is geen afspraak dat de taalcode vooraan moet, maar het is al jaren dusdanig algemeen gebruik dat je het als een kunt opvatten. Dit nu weer gaan veranderen omdat het kan, lijkt mij niet zinvol. En achteraan heeft nog minder nut, want bij 99,9% van de bronnen weet de lezer al zelf welke taal gebruikt is. HT (overleg) 21 mrt 2024 06:31 (CET)Reageren

Bij citeer sjablonen wordt het automatisch vooraan gezet. Ik mag aannemen dat dat ergens o gestoeld is, maar ik heb geleerd dat hier niks aangenomen moet worden. Labrang (overleg) 21 mrt 2024 08:20 (CET)Reageren

In het verleden heb ik wel eens gebruikers de taalcode van achter de externe link naar vooraan zien verplaatsen, maar dat ze achteraan staan ben ik zelf maar zelden tegengekomen. Toen ik het onlangs eens een keertje tegenkwam heb ik nagezocht hoe vaak een taalcode aan het einde van een regel ingevoegd stond. Dat was zeer sporadisch. Conform de sjabloondocumentatie en de categorie heb ik het op die plekken van achter naar voor geplaatst.

Dit onderwerp is denk ik voor het laatst meer dan tien jaar geleden besproken. Jaren geleden, in de periode 2008-2011 moet dat geweest zijn, ben ik wel eens een discussie tegengekomen waarin gevraagd werd waar de taalcodes ingevoegd dienen te worden. Daar kwam unaniem een antwoord op: vooraan. Dat zal niet de enige keer zijn geweest. Op basis van eerder gevoerd overleg is toen in 2011 op alle taalicoontjes aangegeven dat ze vóór de betreffende bron geplaatst dienen te worden. Reeds in 2009 was het klaarblijkelijk duidelijk dat de taalicoontjes niet achteraan, maar vooraan horen, gezien de bewerking en deze discussie, waarna vervolgens bovendien niemand bezwaar gemaakt heeft. Verder, gezien de vele duizenden keren dat dat zo is toegepast en de weinig keren dat men het erachter heeft gezet, evenals dat de citeer-sjablonen dit vooraan zetten, denk ik dat we veilig kunnen stellen dat het vooraan plaatsen de norm is.

Of het zin heeft om icoontjes te plaatsen daar wisselen de gedachtes over. Maar als ze geplaatst worden heeft het weinig zin om ze achteraan te plaatsen, ze dan dan als mosterd na de maaltijd: als een gebruiker een referentie of bron in een artikel tegenkomt, gaat men niet eerst alle blabla wat er achter komt napluizen. De vraag is dus niet of een taalicoontje belangrijk is, maar de vraag is (als men een taalicoontje plaatst) waar die dan functioneel is. De taalaanduiding wordt vooraan geplaatst zodat voordat iemand op een link klikt weet welke taal die kan verwachten. Achteraan plaatsen is daartoe zinloos. (Ik ben zelfs voorbeelden tegengekomen waarin iemand de taalaanduidingen later vooraf toevoegde en diegene niet had gezien dat ze achteraan al stonden!) Anno 2009-2011 was er duidelijk consensus over dat de taalaanduidingen vooraan geplaatst dienen te worden. Romaine (overleg) 21 mrt 2024 15:11 (CET)Reageren

Maar dan is er nog steeds geen reden om dat met een bot overal precies hetzelfde te gaan maken. Sommige medewerkers kiezen er bewust voor om die taalcode niet vooraan te zetten omdat het de leesbaarheid van een lijst met bronnen flink verslechtert als de auteursnamen niet vooraan staan en niet netjes uitgelijnd zijn (de taalcodes zijn niet allemaal even breed, en niet bij elke titel staat er een). Het lijkt me een vorm van OCD als iemand dit botmatig gaat uitvoeren zonder dat er een functionele reden voor is. WIKIKLAAS overleg 21 mrt 2024 18:01 (CET)Reageren

Om die reden laat ik taalcodes wel weg bij een aparte literatuurlijst in de appendix, boven de gewone inline referenties en voetnoten. Labrang (overleg) 21 mrt 2024 19:45 (CET)Reageren

@Wikiklaas: In eerdere discussies consensus en vastgesteld dat ze vooraan horen te staan. En dat al 15 jaar! Dat is absoluut wel reden om daar waar gebruikers de verkeerde plek kozen dit op die sporadische plekken te corrigeren. Dat je het daar niet mee eens bent en daarom mij een dwangstoornis toedicht is een persoonlijke aanval en in strijd met de gedragscode op Wikipedia. En zoals al aangegeven, aan het einde van een bron is een taalcode zinloos, achteraan is géén functionele plek. Als je ze niet vooraan wilt hebben en auteursnamen obsessief dwangmatig recht onder elkaar wilt hebben, snap ik sowieso niet waarom je ze wilt toevoegen. Dat een "lijst met bronnen flink verslechtert" zie ik niet en al helemaal niet gezien de taalcodes vooraan op honderdduizenden artikelen zijn toegepast. Romaine (overleg) 22 mrt 2024 09:09 (CET)Reageren

Willen jullie (allemaal) alsjeblieft even een time out nemen van deze discussie over de positie van een paar letters en de uitlijning van een lijst, en even te tijd nemen of, hoe en waar zo een discussie moet plaatsvinden. Het gooien met termen als OCD leidt nergens toe. We zijn allen betrokken bij Wikipedia, ieder op een eigen maner. Groet, Elly _{Sta jij al hier? (Overleg)} 22 mrt 2024 09:52 (CET)Reageren

Nou ja, impliciet is het afgesproken in de citeersjablonen, zoals {{Citeer web}}. De visuele tekstverwerker gebruikt deze sjablonen voor het invoegen van referenties. Wikiwerner (overleg) 21 mrt 2024 20:24 (CET)Reageren

Om op het nut terug te komen: als ik ergens de of en zie staan (of ja, ik, of zelfs kk) denk ik niet snel dat daar een taal mee bedoeld wordt. Wammes Waggel (overleg) 27 mrt 2024 11:39 (CET)Reageren

Het staat tussen haakjes en als je je cursor erboven houdt, dan zie je ook dat het een taalcode betreft. Mondo (overleg) 27 mrt 2024 16:56 (CET)Reageren

Op dit moment ben ik bezig met het updaten en zo veel mogelijk verbeteren van artikelen rondom de wereld van Het Erfgoed, een boekenserie waarvan het bekendste boek (en personage) Eragon is en meer dan 40 miljoen verkochten exemplaren heeft. De pagina van de serie zelf loopt een of twee boeken achter en ook de pagina's van de individuele boeken zijn niet heel sterk (en vaak zonder bronvermelding).

Op mijn kladblok Gebruiker:Mythical/Kladblok/HetErfgoed ben ik begonnen met de pagina van de serie, de Engelse pagina voor nu leidraad/inspiratiebron. Op de Engelse pagina, maar ook bijvoorbeeld op de Spaanse en Italiaanse wiki, is er gekozen om op de pagina zelf de personages beperkt te benoemen en door te verwijzen naar List of the Inheritance Cycle characters.

Nu was ik benieuwd wat hier op de Nederlandse wikipedia gebruikelijk is, voordat ik veel tijd en energie steek in een pagina die niet de bedoeling is. Kan ik zo'n pagina aanmaken of liever niet? Mythical (overleg) 24 mrt 2024 21:17 (CET)Reageren

Het belangrijkst is hier bronnen. Je artikel moet gebaseerd zijn op onafhankelijke secundaire gezaghebbende bronnen die erover hebben geschreven. Schrijf je over boeken die je zelf gelezen hebt dan loop je al snel het risico dat de boeken je belangrijkste bron zijn en je gaat beschrijven wat je hebt gelezen. Maar dat is een primaire bron en dus niet de bedoeling. LeeGer 24 mrt 2024 22:36 (CET)Reageren

In je conceptartikel zie ik een veel te lange verhaallijn, vol met namen en allerlei plotwendingen. Mij nodigt zo'n samenvatting niet uit tot lezen. En dat is wat LeeGer dan ook bedoelt: je zult dit vooral uit eigen ervaring hebben opgeschreven, en dan krijg je al snel dat elk detail belangrijk lijkt ('en toen-en toen-en toen'). Baseer je ook voor de verhaallijn op secundaire bronnen, zoals recensies: die weten een boek vaak kernachtig samen te vatten. Voor de lezer ook veel prettiger, want dan krijg je wel een indruk van het boek zonder dat je wordt vermoeid met allerlei details.

Voor de personages moet je je afvragen of er voldoende bronnen zijn die hen daadwerkelijk beschrijven. Om een recent voorbeeldje (van mezelf) te mogen geven: ik heb de beschrijving van Commandant Cody volledig uit secundaire bronnen weten te halen, en heb dus niks zelf hoeven bedenken. Als je dat als uitgangspunt hanteert voor Het Erfgoed, dan kom je er al snel achter of je een aparte lijst moet gaan maken met lange beschrijvingen, of dat je je beter kunt beperken tot wat je nu hebt gedaan: een korte opsomming, eventueel aangevuld met enkele hoofdzaken.

En dan ook nog even iets positiefs: ik zie dat je achtergronden e.d. hebt beschreven, en dat valt toe te juichen, want dergelijke informatie wordt op de NL-wiki helaas maar al te vaak vergeten... Dus dat is echt een verademing! Thieu1972 (overleg) 25 mrt 2024 08:35 (CET)Reageren

Dank allebei voor de toelichting! Dat was ook al mijn vermoeden.

De samenvatting is inderdaad veel te lang, een vertaling van de Engelse samenvatting. Ik ga die inkorten, omdat er inderdaad te veel randzaken benoemd worden! Mythical (overleg) 25 mrt 2024 10:40 (CET)Reageren

Op 25 maart 2024 begint om 23:00 uur CET de Stemming kop "trivia" vervangen. Ieder heeft iets meer dan 2 weken de tijd om een stem uit te brengen. De stemming eindigt op 10 april 23:00 CEST. CEST, want het is dan inmiddels zomertijd. Met vriendelijke groet van de stemcoördinator, Elly _{Sta jij al hier? (Overleg)} 24 mrt 2024 22:45 (CET)Reageren

MediaWiki message delivery 25 mrt 2024 19:53 (CET)Reageren

Beste allemaal,

Zoals eerder vermeld, organiseert de WMF van 2 april tot 28 mei haar jaarlijkse inzamelingsactie met banners voor niet-ingelogde gebruikers in België.

Je kunt meer informatie over de campagne vinden, voorbeeldbanners bekijken en eventuele vragen of suggesties achterlaten op de samenwerkingspagina van de community.

Over het algemeen kun je voor en tijdens de campagne contact met ons opnemen:

• Op de praatpagina van het fondsenwervingsteam
• Als u een bug of technisch probleem wilt melden, maak dan een phabricator ticket aan.
• Als je ziet dat een donateur op een praatpagina, VRT of sociale media problemen heeft met doneren, verwijs hem dan door naar donate at wikimedia.org

Bedankt en groeten, JBrungs (WMF) (overleg) 26 mrt 2024 12:59 (CET)Reageren

Op de website van Nationaal Comité 4 en 5 mei staat er dit oorlogsmonument: https://www.4en5mei.nl/oorlogsmonumenten/zoeken/709/stein-gedenkmonument Het zou gelegen zijn in de Limburgse gemeente Stein, maar er is verder niks van bekend. Van dit monument zou ik graag de locatie bepalen waar het nu staat of ooit gestaan heeft. Deze gemeente is niet zo heel erg groot, bestaat voornamelijk uit de plaatsen Stein en Elsloo en wat kleinere dorpen/gehuchten. Op de achtergrond van de foto zijn twee gebouwen te zien, waarbij de rechter spekbanden heeft, dus misschien is de plek van dit monument op basis van dit gebouw vast te stellen. In de gemeente zijn veel historische panden bewaard gebleven. De foto is al wat ouder gezien de oude zendmasten/sprietantennes op de daken. Wat me opvalt is de hoogte van het rechter gebouw, het heeft namelijk 3 bovenverdiepingen. Met Google Streetview ben ik een aantal straten in het centrum van Stein en Elsloo afgegaan, maar wat me daarbij opvalt is dat een gebouwhoogte van drie bovenverdiepingen niet gangbaar is en de ruimte tussen het monument en de achterliggende bouwen groter is dan gangbaar in Stein/Elsoo. Is dit wel in de gemeente Stein? Wat me opvalt is dat de straat iets afloopt, het zou dus zeker wel Limburg kunnen zijn. Maar als je een horecazaak 't centrum noemt, verwacht ik niet dat het buiten het centrum van een plaats moet zijn. Maar waar? Wie kan helpen? Romaine (overleg) 26 mrt 2024 17:48 (CET)Reageren

Even met Google Lens gezocht, het beeld staat in Valkenburg. Behanzane ☎✉ 26 mrt 2024 17:58 (CET)Reageren

Super! Ik was vorige week in Valkenburg en ben daar erlangs gelopen, maar toch herkende ik de foto niet met de plek. Hartelijk dank! Romaine (overleg) 26 mrt 2024 18:04 (CET)Reageren

Het monument wordt hier genoemd. Hobbema (overleg) 26 mrt 2024 18:05 (CET)Reageren

Maar dan heeft het dus niks met de oorlog van doen... Romaine (overleg) 26 mrt 2024 18:09 (CET)Reageren

Volgens de afbeeldingspagina is deze foto jouw eigen werk van een paar jaar geleden.. Behanzane ☎✉ 26 mrt 2024 18:19 (CET)Reageren

Ja, dat maakte het net hier even heel hilarisch... Romaine (overleg) 26 mrt 2024 18:30 (CET)Reageren

Ik vind het wel leuk om te zien hoe het straatbeeld in de tussentijd is veranderd. (en kennelijk heeft @Mondo: hier een hotel-restaurant.)

Ik had trouwens ook gezocht, op basis van de kleur van de daken en een beetje op basis van de stand van de zon. Maar wel dus in Stein.... Sneeuwvlakte (overleg) 26 mrt 2024 18:38 (CET)Reageren

Hier een beschrijving van de activiteiten bij de onthulling van het eerste monument in 1889. Hobbema (overleg) 27 mrt 2024 12:58 (CET)Reageren

Fraaie zuil! Zouden daar rechtenvrije (of onder vrije licentie) foto's van zijn om te gebruiken in Wikipedia? Romaine (overleg) 27 mrt 2024 14:12 (CET)Reageren

Je zou kunnen informeren bij het Regionaal Historisch Centrum Limburg of bijvoorbeeld deze afbeelding inmiddels rechtenvrij is. Gouwenaar (overleg) 27 mrt 2024 14:47 (CET)Reageren

Op een van de toeristische richtingaanwijzers staat "Polfermolen" - aparte naam! Dan wordt het wel makkelijk zoeken. PAvdK (overleg) 27 mrt 2024 15:15 (CET)Reageren

@Sneeuwvlakte Om een of andere reden werkte je ping niet, maar hahaha, zo te zien ben ik eigenaar zonder het te weten. 😛 Mondo (overleg) 27 mrt 2024 17:04 (CET)Reageren

Op de website van Nationaal Comité 4 en 5 mei staat er dit oorlogsmonument: https://www.4en5mei.nl/oorlogsmonumenten/zoeken/536/egmond-oorlogsmonument Volgens die pagina zou het in het Noord-Hollandse Egmond liggen. Weet iemand te achterhalen waar dit is? Romaine (overleg) 27 mrt 2024 08:15 (CET)Reageren

In Egmond Binnen op de hoek Kloosterweg/Abdijlaan bij de Buurkerk. brbbl (overleg) 27 mrt 2024 09:08 (CET)Reageren

Hartelijk dank! Romaine (overleg) 27 mrt 2024 09:34 (CET)Reageren

artikel Hoekgetrouwe cilinderprojectie

Ik krijg wanneer ik de bewerkingsgeschiedenis van Hoekgetrouwe cilinderprojectie open maar een beperkt aantal bewerkingen te zien. ChristiaanPR (overleg) 28 mrt 2024 11:27 (CET)Reageren

Ik zie er 10, inclusief de aanmaak. De laatste vier zijn van jouw hand. Wat is het probleem? Erik Wannee (overleg) 28 mrt 2024 11:32 (CET)Reageren

Het zijn er tien, maar de aanmaak is er niet bij. ChristiaanPR (overleg) 28 mrt 2024 20:13 (CET)Reageren

Zie het logboek en dit verplaatsingsverzoek. Jeroen N (overleg) 28 mrt 2024 11:37 (CET)Reageren

Inderdaad heel vreemd. Het artikel is niet aangemaakt, eerste bewerking door BoH op 8 mrt 2017 om 11:25. PAvdK (overleg) 28 mrt 2024 17:09 (CET)Reageren

Geschiedenis zit volgens mij verstopt in transversale mercatorprojectie, zie dit verschil. Multichill (overleg) 28 mrt 2024 20:09 (CET)Reageren

Het lijkt mij het eenvoudigste het artikel eerst te verwijderen en daarna met dezelfde naam en inhoud opnieuw te maken. ChristiaanPR (overleg) 29 mrt 2024 08:30 (CET)Reageren

@ChristiaanPR Het lemma is geheel bronloos. Lijkt mij zinloos het zonder bronnen te laten. HT (overleg) 29 mrt 2024 09:06 (CET)Reageren

@HT Ik ben dat niet met jou eens. Vrijheid van meningsuiting is hier belangrijk, dus wij mogen opschrijven wat ons goed dunkt. Daar hoort ook bij dat wij corrigeren wat anderen hebben geschreven. Het doel is iets zo te schrijven dat het voor iemand die de tekst leest die aannemelijk is. Er zijn genoeg andere gebruikers waarvan ik de tekst liever niet corrigeer omdat ik het goed geschreven vind, van Patrick bijvoorbeeld. Dat is in mijn ogen een belangrijker maatstaf dan dat er wel of niet bronnen in het artikel zijn opgenomen. Kun je jouw bewering nader verklaren? ChristiaanPR (overleg) 29 mrt 2024 15:00 (CET)Reageren

@ChristiaanPR: Vrijheid van meningsuiting geldt in de openbare ruimte, en daarmee op je eigen website, maar uitdrukkelijk niet op pagina's die door derden beheerd worden, zoals Facebook en Wikipedia. Daar mag de beheerder aangeven welke bewerkingen acceptabel zijn. In ons geval heeft WMF een deel van die rechten aan de gebruikers gedelegeerd, zodat wij in onderling overleg kunnen en moeten uitmaken wat we wenselijk vinden.

Wikipedia-pagina's zijn géén openbare ruimte, maar ook weer niet echt privé, meer te vergelijken met een kroeg, vervoersbedrijf of vereniging. In een kroeg of in de trein kun je buitengezet worden omdat je Mark Rutte bij herhaling een toffe peer noemt, terwijl je dat in de openbare ruimte vrijuit kunt zeggen  →bertux 29 mrt 2024 15:11 (CET)Reageren

Maar Mark Rutte is toch een toffe peer die voor onze vrijheid van meningsuiting opkomt. ChristiaanPR (overleg) 29 mrt 2024 17:26 (CET)Reageren

In de geschiedenis van Transversale mercatorprojectie, staat: bewerkt door Patrick (overleg | bijdragen) op 18 mrt 2014 om 06:38. (Patrick heeft de pagina Transversale Mercatorprojectie naar Hoekgetrouwe cilinderprojectie hernoemd: algemener, systematische beschrijvende naam). Hierna is de doorverwijzing weer als artikel verder gegaan. Eigenlijk leek de bedoeling een deel af te splitsen, vermoed ik. PAvdK (overleg) 29 mrt 2024 10:34 (CET)Reageren

Vier jaar later weet ik niet meer direct welke versies waar stonden, maar ik heb hier als moderator inderdaad versies vanuit beide bewerkingsgeschiedenissen samengevoegd. Daardoor is de 'aanmaak' niet als aanmaak geregistreerd. Encycloon (overleg) 29 mrt 2024 16:45 (CET)Reageren

Waarom niet mijn manier, verwijderen en met dezelfde naam en inhoud opnieuw maken? Daarmee wordt de bewerkingsgeschiedenis gewist, maar daar is hier een reden voor. ChristiaanPR (overleg) 29 mrt 2024 17:29 (CET)Reageren

De licentie vereist dat de bewerkingsgeschiedenis bewaard blijft. Ik heb als moderator in het verleden wel van dit soort puzzels opgelost, waar de bewerkingsgeschiedenissen van twee artikelen verward waren geraakt door hernoemingen en verwijderingen met weer terugplaatsen. Het kan dus wel, en daarom is 'jouw manier' hier niet aan de orde. Om dit op te lossen zal het nodig zijn dat een moderator er tijd in steekt. WIKIKLAAS overleg 29 mrt 2024 18:51 (CET)Reageren

Wikiklaas, Dat antwoord is goed genoeg. Het ligt niet aan jou, maar bijvoorbeeld wat de licentie vereist lijkt mij te absoluut gesteld. Het lijkt mij niet nodig altijd maar te kunnen terugvinden welke gebruikers welke veranderingen hebben aangebracht, al hebben ze jaren geen veranderingen meer aangebracht. Houd mij te goede, ik ben met jouw antwoord tevreden. ChristiaanPR (overleg) 29 mrt 2024 21:11 (CET)Reageren

De licentie is geen vrijblijvend advies. Medewerkers hebben niet de optie om de licentievoorwaarden al dan niet te accepteren en te besluiten er niet naar te handelen. Ik was ook wat verbaasd toen je hierboven de vrijheid van meningsuiting noemde als argument om een bronloos artikel te accepteren. Artikelen mogen nooit de mening van een medewerker vertolken. Op overlegpagina's mag je een eigen mening geven en opschrijven wat je goeddunkt; in een artikel niet, ook al schrijf je daar iets wat voor een lezer heel aannemelijk is. In artikelen hoort goed gedocumenteerde kennis te worden samengevat. Het is kennis om te weten wat er door deskundigen op een of andere manier over een onderwerp is gepubliceerd of gezegd, en je zult daar dus naar moeten kunnen verwijzen. Wij doen hier niet zelf aan waarheidsvinding; wij herhalen slechts wat de kenners daarover geformuleerd hebben. En als kenners het niet met elkaar eens zijn, dan zoeken we niet zelf een aannemelijke tussenweg maar vermelden de verschillende opvattingen. Met vrijheid van meningsuiting heeft het schrijven van een artikel niets te maken, en in die zin is die hier dan ook helemaal niet belangrijk. WIKIKLAAS overleg 29 mrt 2024 22:21 (CET)Reageren

Wie bepaalt het verschil tussen objectieve informatie en een mening? Informatie is iets anders dan een gegeven. Ik was het met jouw eerste antwoord wel eens, maar met wat je nu zegt niet. ChristiaanPR (overleg) 30 mrt 2024 21:33 (CET)Reageren

Wat mij betreft is een mooie definitie van "objectieve informatie" dat deze volgens een formele discipline (bijvoorbeeld een scheikundig protocol) vastgesteld is en dat iemand anders die volgens dezelfde discipline werkt deze kan re/dupliceren. Een mening is iets dat iemand zelf bedacht heeft. - Brya (overleg) 31 mrt 2024 08:29 (CEST)Reageren

Inderdaad, de bewerkingsgeschiedenis is belangrijk. De bewerkingsgeschiedenis laat niet alleen zien wie over welke delen het copyright heeft, maar ook wie waarvoor wettelijk en moreel aansprakelijk is. En inderdaad, vrijheid van meningsuiting is hier niet niet, of slechts ten dele, van toepassing: dit project is geen verzameling ingekomen brieven. - Brya (overleg) 30 mrt 2024 06:36 (CET)Reageren

Ik heb jouw gebruikerspagina gelezen en toen bedacht dat ik het niet nodig vind om antwoord te geven. ChristiaanPR (overleg) 30 mrt 2024 20:53 (CET)Reageren

Zolang je maar niet vergeet dat je bij elke bewerking telkens expliciet akkoord gaat met de Gebruikersvoorwaarden, en dat die omvatten wat ik hier schreef. Je verklaart telkens dat je accepteert dat je daaraan gebonden bent. - Brya (overleg) 31 mrt 2024 08:18 (CEST)Reageren

@ChristiaanPR: Je vraagt mij hierboven waarom in een lemma bronnen dienen te staan. Ik verwijs naar de mening van de Universiteit Utrecht over Wikipedia. Dat is: "In goede artikelen staan recente referenties, bronnen, noten en literatuurverwijzingen die je als wetenschappelijke bron kunt gebruiken. Wanneer je Wikipedia toch als bron wilt gebruiken moet je vooral letten op de aanwezigheid van dergelijke verwijzingen." (hier). Het RIVM meldt als kritiek over Wikipedia-lemma's m.b.t. infectieziekten: "Verder ontbraken er regelmatig referenties bij Wikipedia." (hier). HT (overleg) 31 mrt 2024 08:55 (CEST)Reageren

@Brya Ik accepteer de Gebruiksvoorwaarden wel maar jouw interpretatie ervan niet. Bijvoorbeeld jouw definitie niet van objectieve informatie. Wanneer jij zegt dat andere mensen een bron moeten opgeven bij wat zij schrijven, moet je eerst beginnen jouw eigen beweringen te maatstaven. Wat er op de wikipedia staat kan door iedereen worden gecontroleerd en voldoet dus aan jouw definitie. Formele discipline zegt daarentegen mij niets.

@Gebruiker:Happytravels Als je dat zo nodig vindt dan moet je ze toevoegen. Ik vind het belangrijker dat een artikel aannemelijk is en gestructureerde informatie biedt. Het RIVM neemt in dit geval de positie van de Rekenkamer in, die ook nooit iets goed vinden. ChristiaanPR (overleg) 31 mrt 2024 18:53 (CEST)Reageren

Het ontgaat mij geheel waarom je meent dat mijn definitie van objectieve informatie iets te maken heeft met wat ik over de Gebruikersvoorwaarden zei. Laat staan dat ik kan bedenken waarom je meent dat ik gezegd zou hebben "dat andere mensen een bron moeten opgeven bij wat zij schrijven". - Brya (overleg) 1 apr 2024 07:54 (CEST)Reageren

@ChristiaanPR: Je schrijft over het bijdragen aan Wikipedia: "Het doel is iets zo te schrijven dat het voor iemand die de tekst leest aannemelijk is." en over het door jou niet willen toevoegen van bronnen: "Ik vind het belangrijker dat een artikel aannemelijk is". Het voor de lezer aannemelijker maken doe je juist door bronnen toe te voegen. Een van de kritiekpunten uit de wetenschappelijke wereld op Wikipedia is dat door het veelvuldig gebruik van pseudoniemen niemand weet heeft wie iets geschreven heeft en wat zijn/haar expertise over het onderwerp is. Door bronnen toe te voegen maak je duidelijk waar de informatie vandaan komt en hoe betrouwbaar die is. Dit is de enige manier om in het algemeen inhoud aannemelijker te maken. HT (overleg) 1 apr 2024 08:09 (CEST)Reageren

Goede bronnen helpen bij aan het overbrengen van informatie, maar zijn daar geen nodige voorwaarde voor. ChristiaanPR (overleg) 1 apr 2024 09:42 (CEST)Reageren

Het is misschien een kwestie van onhandig woordgebruik, maar "Het doel is iets zo te schrijven dat het voor iemand die de tekst leest aannemelijk is." klinkt voor mij omgedraaid. Het is een van de belangrijke eigenschappen van een encyclopedie dat ze informatie biedt waarvan de lezer zal denken "He, dat kan toch niet!", in lijn met het gezegde truth is stranger than fiction. Iets zo presenteren dat het voor de ander 'aannemelijk' is, is juist belangrijk voor oplichters, die mensen erin willen laten tuinen zonder dat ze het in de gaten hebben. - Brya (overleg) 1 apr 2024 09:17 (CEST)Reageren

Brya, Wat kletst jij veel. Ik mag dat als jij over oplichters begint best zeggen. De wikipedia wordt voortdurend gecontroleerd. ChristiaanPR (overleg) 1 apr 2024 09:42 (CEST)Reageren