Overleg gebruiker:CartoonistHenning

[bewerken] mechelenmapt.org

Ik heb doorgestuurd http://mechelenmapt.org naar http://mechelen.mapt.be --Carlb 16 mrt 2010 15:58 (UTC)

Thanks | CartoonistHenning 16 mrt 2010 17:43 (UTC)

[bewerken] Sig

test | Cartoonist | Contact | 21 mrt 2010 14:41 (UTC)

[bewerken] Wandelingen/fietstochten

Vanuit de stad Mechelen, was er de vraag om een pagina te maken met verschillende wandelingen/fietstochten uit de omgeving. Kunnen we dat opzetten ? --Peter 26 mrt 2010 19:40 (UTC)

Zeker! Alles wat Mechelen is is toegelaten hier. Zo kunnen we ook wat met de kaart experimenteren | Cartoonist | Contact | 27 mrt 2010 13:35 (UTC)

[bewerken] Opkuiswerk

Zeg, Henning, als ik zo sommige artikels overloop is er nog een pak opkuiswerk :-D

En er ontbreken nog een pak foto's. --Gimycko 31 mrt 2010 21:09 (UTC)

Ik ga het zsm in orde brengen | Cartoonist | Contact | 2 apr 2010 16:33 (UTC)

BTW:Heb jij al een ID om schrijvers te lokken ? Just2know  :-) --Gimycko 2 apr 2010 18:17 (UTC)

Zoveel mogelijk verwijzingen aanmaken in artikelen op Mechelen Blogt lijkt me de eerste optie. Mechelen.be zou een link naar ons mogen hebben vind ik. Op Mechelen Blogt een aparte rubriek met een rss-feed... Cartoonist | Contact | 2 apr 2010 18:46 (UTC)

Een suggestie : Maak er geen overkill van want anders gommen ze je weg op MB. BTW : Nog ideeën voor artikels in de pipeline ? --Gimycko 2 apr 2010 19:39 (UTC)

Peter stelde voor om op aanvraag van Mechelen stadsbestuur iets te doen rond fietsroutes (zie hierboven) in en rond Mechelen | Cartoonist | Contact | 2 apr 2010 20:57 (UTC)

[bewerken] Congé

Aha, is Henning terug uit congé  ;-) --81.165.206.245 17 jul 2010 15:04 (UTC)

Nog niet hoor. In Noorwegen heb ik ook internet :-) Cartoonist | Contact | 21 jul 2010 18:21 (UTC)

[bewerken] Zeg

D'r gebeuren allemaal dingen en jij blijft weg? Wazullewenukrijgen? R7 6 jul 2012 11:52 (UTC)

Is er ee eet gebeurd? A zal a ni fuil gemist emme, paos ek.— SomeHuman 2012-07-09 14:38 (UTC=CEST-2)

Buiten een spaminvasie niet veel. Buiten het feit dat ik moeilijk bereikbaar ben. Liefst per e-mail (zie boven) | Cartoonist | Contact | 9 jul 2012 14:45 (UTC)

[bewerken] Random

Zeg, Henning, als ge wilt... plaats de random-page eens terug in de navigatie. Was altijd leuk. --Gimycko 7 jul 2012 07:40 (UTC)

Uitgevoerd Roye7777777 7 jul 2012 19:27 (UTC)

[bewerken] AN tekst in Mechels dialect/suggesties

Het komt me voor dat U zich vergist heeft. De beleefdheidsvorm 'uw' kan niet samengaan met 'je', maar vergt u, aan/van u, uw (ongeacht of de ultiem beleefde 3e persoon vervoegd en een hoofdletter geschreven wordt). Als normale vormen erkent het AN combinatie 1. je, jou, jouw ofwel 2. ge, u, uw. Het door mekaar gebruiken van vormen uit 1 en 2 alsook één ervan met de beleefdheidsvorm, is een taalfout (een "noordbelgicisme"?) en erger dan een d/t-fout want men hoort het. In geschreven AN is 'ge' oubollig, zelfs in onze contreien. Zo 'jou', jouw' en 'jullie' U te Hollands klinken, kiezen we het Westvlaamse joen (enkv.) en joender (mv.), dat is ook geen AN. 'Vousvoyeren' is onmogelijk: 'vous' is de normale vorm, 'tu' de vertrouwelijke, expliciet informele, vandaar dat men tutoyeert; 'je' (ofwel 'ge') is de normale vorm, 'u' de beleefdheidsvorm die in een vrij normale omgeving tegenwoordig afstandelijk overkomt, 'U' de heden ten dage ostentatieve beleefdheidsvorm.

De matige beleefdheidsvorm 'u' wordt buiten een formele context nog nauwelijks gebruikt; ik zag al jobaanbiedingen op directieniveau bij een in ons land gevestigde grote bank "Je profiel" beschrijven, volop doorgaand met "Je bent..."!

Ik ben er me pijnlijk van bewust dat "je uw" (vlak na mekaar, als in "dan kan je uw zin doen") honderdduizenden keren op het Internet voorkomt, weliswaar ietsje minder op een .nl dan een .be domein. Doch welgeteld 0 keer op onzetaal.nl, taaladvies.net, leernederlands.com en taaluniversum.org. De enkele tientallen gelegenheden op dbnl.org blijken "zo je uw Vrouw niet schénd, nóch my niet meld. Filibert" en dergelijke. Voor "nieuwerzwetse" blogtaal ben ik te zeer van dɘn aovɘ stempɘl, uit principe.

In de pagina kan wel de eerste 'jouw', nu 'uw', door het doffer bezittelijk voornaamwoord 'je' vervangen worden, de tweede echter moet nadrukkelijk de 2e persoon aanduiden en een bezittelijk voornaamwoord zijn. Er is m.i. slechts 'jouw' mogelijk, behoudens een heel andere formulering. Mits Uw goedvinden, zou ik U met genoegen op minder formele wijze willen adresseren. ;-D
— SomeHuman 2012-08-13 01:00 (UTC=CEST-2)

Op Mechelen Mapt zou ik graag willen dat je de u-vorm gebruikt als je de lezer aanspreekt (niet mij). Kwestie van beleefdheid en om juist persoonlijker te werk te gaan. De afstandelijkheid toont aan dat we kwalitatief willen overkomen, wat we ook willen zijn. Zoals je zegt is die "je" neutraal. Daarom vind ik dat de lezer zich aangesproken moet voelen door het encyclopedisch werk dat hier verricht wordt. Merk op dat er een groot verschil is met spreektaal. In de spreektaal echter, wanneer het een face-to-facegesprek betreft, ongeacht of het nu Zijne Majesteit de Koning der Belgen is of de burgemeester, spreek ik mijn gesprekspartner aan met "ge". Dat zal ik voor eeuwig en drie dagen blijven doen. Puur omdat ik wens dat mijn gesprekspartner zich niet neerbuigerig gedraagt tegenover mijzelf en andersom. Als ik voor een publiek spreek, gebruik ik dan weer de u-vorm, omdat ik weet dat het articulatorisch de aandacht trekt en dieper doordringt dan een doffe ge of je. Gij en jij zijn dan weer voornaamwoorden die ik liever gebruik als ik mijn gesprekspartner zelf in de verf wil zetten. De ij-klank acht ik immers niet geschikt voor een publiek, omdat het opdringerig overkomt. De eerste persoon meervoud is ten slotte goed voor een verbondenheid, wanneer je bijvoorbeeld namens een groep spreekt of je richt tot een groep waarmee je verbondenheid hebt.

Wat ik zeker wil meegeven is dat je de scheiding moet maken tussen spreektaal en schrijftaal. Mensen maken namelijk de fout de spreektaal aan te passen aan de schrijftaal, meestal gekoppeld aan hoge verwachtingen, hetzij mbt schoolprestaties hetzij mbt communicatievaardigheden die zo scherp moeten staan dat de puurheid onnatuurlijke vormen aanneemt. Veel heeft ook te maken met positie op de maatschappelijke ladder en het kortzichtige, pejoratieve beeld dat ons door politiek en media wordt opgelegd: wie dialectisch of dialect spreekt is ruraal en intellectueel onbegaafd. Ik ken landen waar dialect spreken salonfähig is en zelfs aangemoedigd wordt. Maar niet schrijven. Dialect schrijven werkt niet. Een ge geeft in de spreektaal een specifieke gevoelswaarde mee, in schrijftaal echter kan de ge moeilijk geïnterpreteerd worden, zodat het wel eens boertig zou kunnen overkomen. Met een u en een je in schrijftaal weet je op voorhand dat de gevoelswaarde niet ambigu is, daar deze twee voornaamwoorden uitersten vormen in de schaal van "nederigheid". Dit is de reden waarom ik geen "ge" in schrijftaal gebruik.

Het zal me bovendien worst wezen dat alles en iedereen zouden moeten meedraaien met de wind. Hier op deze site wil ik dat we niet afglijden naar een neutrale, grijze toestand à la vlees noch vis zoals op Wikipedia. Natuurlijk kun je uitzonderingen maken op de u-regel, maar als het echt een stappenplan is, zorg dat je de lezer er dan echt bij betrekt. Mijn lange boterham is ondertussen en baguette geworden (ik ben namelijk ook een heel grote fan van taal) | Cartoonist | Contact | 16 aug 2012 01:56 (UTC)

Des lezers heil! Ik denk dat ik je goeddeels kan volgen. Het is allicht zelden nodig de lezer aan te spreken, en dan nog veeleer hetzij als Lecturi salutem, hetzij een kennisgeving aan of oproep tot de menigte lezers. Wishful thinking, may I? Laat nu de pagina 'suggesties' echter een zeldzame gelegenheid wezen waarbij aan een afgezonderd individu uitgerekend een te volgen methode meegegeven wordt. Een afstandelijker aanspreking met 'u' zou net in zulke situatie instructies, met de onvermijdelijke vermelding van 'vaklui' of 'administratoren' zelfs nadrukkelijk een van bovenaf opgelegde plicht, insinueren. De vertrouwelijker 'je'-vorm laat toe, samen met de erdoor mogelijke minder formele zinsbouw, woordkeuze (zoals na een opmerking van Gimycko, "techneut") en stijl (zoals "vakman (m/v)"), de scherpe kantjes af te ronden tot een praktische gids, een vertrouwelijke goede raad in een oprechte poging het leven van de lezer te vergemakkelijken.

Het alternatief, inzake het onpersoonlijke 'men', wordt niet door elke aangesprokene geapprecieerd. Ik denk dat we best een onderscheid handhaven tussen hulppagina's en richtlijnen enerzijds in vertrouwelijke vorm, en berichten anderzijds in professioneel wellevende vorm. — SomeHuman 2012-08-16 06:59-07:26 (UTC=CEST-2)

[bewerken] Hoera

Hoera ! Henning is terug ! Nu de spamfilter terug installeren, if you please, en dan zijn we er helemaal !  ;-) --Gimycko 6 sep 2012 13:37 (UTC)

Een goed spamfiltersysteem is altijd meegenomen, bijvoorbeeld bij registratie gebruiker een visueel te herkennen en in te tikken reeksje karakters, en dat ook voor elke toevoeging of wijziging van een url door een niet-geregistreerde gebruiker. Daarnaast zijn blacklists voor IP ranges interessant. Maar als men ook van geregistreerde gebruikers (of eventueel dezen die al meer dan drie dagen geregistreerd zijn) vergt dingetje in te vullen, is de remedie al gauw erger dan de kwaal.

Bij blokkeren van gebruikersnamen aanvinken het IP ook te blokkeren, blijkt een 'blok' te zetten dat in feite al verlopen is. De laatste dagen blokkeerde ik dus geregeld IP's direct, en ook al de nieuw geregistreerde gebruikersnamen die nog niet hadden bijgedragen (lees: niet gespamd in main space of in hun gebruikerspagina). Dat vergt nu wel heel wat extra werk (ISP's moeten geverifieerd worden bvb. om geen onschuldige klanten van een dynamic IP provider te pesten - zelfs bij buitenlandse ISP's want bijvoorbeeld de Cartoonist en ikzelf kunnen wel eens vanuit een wat afgelegen gehuchtje aanloggen), maar het zou na enkele weken vruchten kunnen afdragen, dat wil ik wel even aankijken.
— SomeHuman 2012-09-06 14:11 (UTC=CEST-2)

Wat een probleem is, is dat veel van onze pagina's handmatig semi-protected zijn, omdat Carl niet reageerde toen ik vroeg om een blokkade voor anoniemen en newusers. De mensen die nu normaal inloggen moeten minstens 10 bewerkingen hebben gedaan en 4 dagen oud zijn, alvorens zij alle pagina's kunnen bewerken. Ik krijg op regelmatige basis een e-mail van mensen die daarover klagen, waarop ik hun telkens diezelfde uitleg moet antwoorden | Cartoonist | Contact | 6 sep 2012 19:07 (UTC)

Vele andere pagina's zijn niet (semi-)protected. Die worden niet aangevallen door de 'reguliere'_(sic) spambots. Die snoodaards maken wel geregeld ook gebruikers aan zonder enige (onmiddellijke) bewerking; ik check dus het 'nieuwe-gebruikers'-log en blokkeer veiligheidshalve die (voor het menselijk brein als spammer herkenbare) gebruikersnamen (omdat wisselende IPs anders achteraf van die gebruikersnaam misbruik zouden kunnen gaan maken, ze zijn allicht met die bedoeling aangemaakt). Toch valt op dat ook wijl tot vorige week nog vele gebruikersnamen niet geblokkeerd waren, slechts gebruikerspagina's en compleet nieuw aangemaakte artikelen spam kregen toebedeeld. Bestaande pagina's beveiligen heeft dus allicht geen nut: Dat stoort bij het gedragspatroon van de huidige series spammers, uitsluitend bonafide bijdragers. Ik stel voor om 'semi-protection' van alle pagina's te verwijderen, met slechts semi (of full) protection van de meest essentiële hoofdpagina's die we niet zomaar door iedere (zelfs goedmenende) fysieke persoon willen zien wijzigen. Ik denk bijvoorbeeld aan de homepage, aan wat in menu's gelinkt wordt (meestal toch in een aparte 'space' die best quasi systematisch minstens semi-protected wordt), of nog de pagina die de zeer specifieke uitspraakspelling (regels) van het Mechels dialect uitlegt.
— SomeHuman 2012-09-07 04:10-04:29 (UTC=CEST-2)

[bewerken] Verwijderde bijdragen

In een 'Gebruikersbijdragen'-pagina verschijnt bovenin een kleingedrukt balkje met links, waaronder 'verwijderde bijdragen'. Deze opent steevast een blanco pagina, zelfs als net voordien of al dagen eerder een door die gebruiker aangemaakte (spam)pagina verwijderd werd (zoals het verwijderingslog bewijst). In de praktijk zijn bij mijn dergelijke controles wel alle pagina's van die gebruiker al verwijderd, ik weet nog niet wat er te zien zou zijn indien er van een bepaalde gebruiker bijdragen verwijderd zijn maar andere nog niet. Heb alleen ik dat euvel, of gaat ergens iets ook voor anderen fout?

Ik vermoedde eerst een typische programmeerfout: Men had in gedachten dat vele bijdragen bestaan waarvan enkele verwijderd werden, en bedacht een routine om die eruit te pikken. Als er echter helemaal geen bijdragen [meer] bestaan, wordt die routine domweg overgeslagen. Bij nader inzien blijkt echter dat ondanks mijn eigen 2012-08-20T08:37:07 verwijderde bijdrage (zie verwijderingslogboek) en mijn natuurlijk vele nog bestaande bijdragen, ook ik slechts een blanco lijst 'verwijderde bijdragen' heb. De flop is dus totaal.
— SomeHuman 2012-09-07 04:21-05:04 (UTC=CEST-2)

Ik heb dat ook. Wel een vreemde fout. Het is iets gelijkaardigs als de logcounts-pagina. Ik heb er alleszins geen oplossing voor | Cartoonist | Contact | 7 sep 2012 18:32 (UTC)

[bewerken] JS confirm

Goeiemorgen Henning, Ik zocht en prutste nog wat verder en kwam tot dit. En ik merkte ook van mijn 'beste' probeersels net zo min iets als van wat jij er had gezet. Ik zou niet denken dat de browser cache er voor iets kan tussenzitten, maar als je de geschiedenis (mijn laatste versie voor de huidige) bekijkt, dan zou er toch iets moeten te zien geweest zijn, lijkt me. Noppes. Keer gerust terug naar jouw versie, of gooi die er ook uit, zoals je wenst.
— SomeHuman 2012-09-08 05:18 (UTC=CEST-2)

UPDATE: Het werkt. De fout zat blijkbaar in de al lang bestaande reeksen 'pre' (en allicht ook fout geplaatste 'nowiki'). Het verklaart allicht ook waarom een test die ik al een tijd geleden uitvoerde, zonder resultaat bleef. Maar ook (sommige) andere functies in dat .js bleven dan wellicht al die tijd onbenut. Die werden dan nu ook aktief. Als je dus iets abnormaal en ongewenst ziet, kan je die extra functies dus moeten desactiveren.

Tijdelijk plaatste ik een tag in mijn overlegpagina, die ervoor zorgt dat bij bekijken ervan de spamcontrole uitgevoerd wordt. Je leest in mijn overlegpagina meteen dat een extra spamcontrole functioneel werd.
— SomeHuman 2012-09-09 07:55-12:26 (UTC=CEST-2)

Aangezien de reguser blijkbaar geen popup opleverde, voegde ik nog een extra lijntje in de .js toe, maar ook dat bleef zonder resultaat. Doe me een plezier, en vernietig de identiteit van (dus niet 'blokkeer') gebruiker TestByRealPerson; daartoe moet men 'bureaucraat' zijn. Als dat lukt, en je zou die gebruikersnaam later opnieuw tegenkomen (nadat ik nog eens een ideetje had), mag je die steeds al een uur of twee na creatie opnieuw vernietigen.
— SomeHuman 2012-09-09 16:41 (UTC=CEST-2)

Je doet me tot de ontdekking komen dat ik die bevoegdheid (delete user) niet heb, evenals de bevoegdheid om gebruikers samen te voegen (merge user). Ik heb die bevoegdheden normaal gezien wel bij andere wiki's, maar dat komt (dacht ik) omdat Carl deze overal als extensie installeerde. MM is op veel gebieden wel een vreemde eend, als je het mij vraagt. Gebruiker hernoemen (rename user) vernietigt bij mijn weten geen gebruiker-id's. Zie Speciaal:Softwareversie.

Ik ben eigenlijk wel benieuwd waarom precies ik dit account moet verwijderen. Je logt de volgende keer toch gewoon terug in om iets te testen? Cartoonist | Contact | 10 sep 2012 00:00 (UTC)

Dat account diende om een 'nieuwe gebruiker' te zijn. Daarbij kreeg ik geen popup te zien, ook niet met het lijntje dat ik tijdelijk in de .js had ingelast zelfs na een paswoord aangemaakt te hebben. Bij een nieuwe pagina verschijnen de popups wel maar toch worden volop gebruikers- en artikelpagina's aangemaakt. (JavaScript confirm heeft steeds de OK als default, dat maakt het allicht ook robots al te makkelijk). Er zal dus nog wel meer getest kunnen worden en ik wens geen tiental rommel-'gebruikers' te laten bestaan. Als ooit een dergelijke testgebruiker geblokkeerd wordt (net tussen een hoop spammers), is allicht ook diens IP (bij default) geblokkeerd. En dat IP is ook dat van...
— SomeHuman 2012-09-10 00:51-09:48 (UTC=CEST-2)

Ja oké, ik begrijp. Tja, ik kan eigenlijk niet veel doen dan erover naar Carl mailen, maar die geeft voor het moment geen teken van leven. Misschien is hij ook een robot, of cyborg. Als hij nu eens bereikbaar was per telefoon, Smoelenboek o.i.d. met eventueel vaste uren waarop ik hem kan bereiken. Of als ik nu eens zijn gemiddelde dagplanning wist, bleven we al een beetje minder in het ongewisse. Hoeveel stukken bestek hij in de schuif liggen heeft of hoeveel bedpartners hij al heeft gehad moet ik nu ook niet weten | Cartoonist | Contact | 10 sep 2012 11:31 (UTC)

[bewerken] Spammers merken niets van JavaScript

Ik plaatste in common.js nog een mooi functietje om spammers tegen te houden. Men mag proberen wat men wil: direct vanuit de browserbalk met parameters 'action=edit' of 'action=submit', via 'Maak artikel', via zoeken naar onbestaand bestand... mijn code en wat die beoogt kan onmogelijk omzeild worden: Enter, Escape, klik in input, enz. Alles wordt perfect opgevangen, behalve... als JavaScript uitgeschakeld staat in de browser (of door de firewall) van de gebruiker. Jammer genoeg hebben de spamrobots lak aan JavaScript. Mijn JS code houdt dus alleen echte gebruikers tegen die geen Nederlands begrijpen en toch wat zouden willen spammen in een nieuwe pagina. Ook de jouwe zoals in Gebruikerregistratie, wordt door spamrobots niet eens opgemerkt.  :-(

Een oplossing is misschien denkbaar door bijvoorbeeld het edit-venster en de 'Opslaan'-knop in de Html te plaatsen d.m.v. JavaScript, in plaats van die daarmee weg te houden of zo. Mediawikidesigns zijn echter uitgekiend om ook zonder JS of CSS functioneel te zijn, en vooral de spamrobots weten daarvan te profiteren.
— SomeHuman 2012-09-12 21:06 (UTC=CEST-2)

[bewerken] Uitweg

Het lijkt me aanvaardbaar om uitsluitend voor 'registratie van nieuwe gebruiker' en voor 'aanmaak van een nieuwe pagina' te eisen dat JavaScript ingeschakeld wordt. Als dat bij iemand niet het geval is, wordt dan een bericht met link getoond in plaats van de registratie of de bewerking. In de targetpagina komt een woordje uitleg waarom, zodat men alsnog JavaScript even kan inschakelen, en ten behoeve van diegenen die JavaScript niet kunnen inschakelen (technisch onvoldoende onderlegd of geen baas over hun systeem met bijvoorbeeld JavaScript geblokkeerd in browser of Firewall) een link naar de contactpagina zodat ze het per e-mailtje kunnen aanvragen.

In dat geval kan de Php die nu een registratieblokje of bewerkingblokje in de pagina pusht, een '<noscript>' produceren die voormeld kort bericht met link toont, en het registratieblokje of bewerkingblokje ('<form>') een 'style="display:none"' meegeven. Voor wie ook CSS uitschakeld heeft staan (hoogstwaarschijnlijk uitsluitend spamrobots), krijgt daarbinnen '<input id="wpSave" name="wpSave" type="submit" ...>' een extraatje mee: 'disabled="disabled"'. In Common.js laten we dan onze huidige functies terzake die style en disabled naar default zetten zodra men in de controle slaagde. Alle huidige problemen zouden daarmee finaal van de baan zijn.

Bij registratie zouden we wel meteen een gebruikerpagina en overleg-gebruikerpagina moeten aanmaken (als ik en jij al deden).
Misschien kan ook bij uitgeschakeld JavaScript een zuiver Html 'form' vanuit die uitlegpagina een gepast e-mailtje zenden. Ik vermoed dat Php het IP van de aanvragende gebruiker 'hidden' in dat 'form' kan plakken en meezenden; het door Php geproduceerde registratieblokje zou aan admins een extra veldje 'in naam van IP' behoeven. Ook kan Php allicht voor bepaalde groepen ingelogde gebruikers het aanmaken van pagina's wel zonder JavaScript mogelijk maken door 'style="display:none"' en 'disabled="disabled"' weg te laten. Een 'bureaucrat' kan een nieuwe gebruiker na enige positieve ervaring in een dergelijke groep plaatsen.

Ik vrees echter dat mijn huidige rechten niet toestaan de Php terug te vinden, laat staan zelf even aan te passen.
— SomeHuman 2012-09-17 11:16-12:20 (UTC=CEST-2)

[bewerken] Quick and not too dirty

Gezien Gimycko net als ikzelf de spamplaag k*tsbeu is, is een manoeuvre dringend gewenst.
Mits hoger cursief vermelde zeer eenvoudige kleine wijziging in de Php (zonder 'noscript' maar met extra '<div class="HideByJS">' dat zegt dat JavaScript en CSS nodig zijn en men anders een e-mail kan sturen; nu al verbergt die 'class' een betreffend 'tag' slechts als zowel JS als CSS werken), ken ik een voorlopige manier om al quasi onmiddellijk (zonder uitlegpagina, nieuwe form of extra registratie-inputveldje) verder te kunnen: Jij stuurt me een desgevallende e-mailaanvraag gewoon door en ik antwoord de aanvrager dat hij/zij gedurende een bepaalde halve dag (waarvoor ik de controle in Common.js even overbrug) het gevraagde kan uitvoeren. Nadien check ik of ook spammers doorkwamen.(2012-09-27 Voorgaande was onzin vermits JS uitstaat en Php de 'submit'-knop disabled zet, doch:) Wij maken de in e-mail gevraagde gebruikersnaam aan met een tijdelijk paswoord dat we terugmailen met vraag dat meteen te wijzigen in 'mijn voorkeuren'. Wellicht is er zelfs nooit zulke aanvraag want hopelijk hebben alle bestaande en de meeste zeer zeldzame nieuwe gebruikers JavaScript ingeschakeld. De spamplaag is dan meteen voorbij.
— SomeHuman 2012-09-17 14:08-22:12 (UTC=CEST-2)

Wat ik bedoel is:

[bewerken] Voor registratie van een gebruikersnaam

schrijft de Php (includes/templates/Usercreate.php ???) recht-toe-recht-aan hetvolgende in de pagina (de noodzakelijke inlassingen toon ik hier in het groen):

In dezelfde of een afzonderlijke Php hoort eigenljk eveneens:

maar als dat niet meteen gevonden wordt, is het geen erg: die extra knop wordt in de meest gewone omstandigheden niet getoond.

[bewerken] Voor nieuwe pagina's

moeten we weliswaar volgende Html verkrijgen:

Maar ik denk dat je de sequentie in de Php welke die Html-blokjes schrijft, wel niet zo vlot kan terugvinden als de eenvoudige 'include' voor registratie van een gebruikersnaam, en de aanpassingen zullen niet zomaar met copy/paste kunnen. Zo ziet de 'form'-tag er (in EditPage.php ???) vermoedelijk ongeveer zo uit:

maar we moeten opletten dat die groene inlas, en ook die voor de 'input'-tag, alleen in nieuwe pagina's terechtkomen. Ik kan niet zo meteen voorspellen waar of hoe dat precies gebeurt, men zal moeten zoeken naar iets als:

en

[bewerken] Hoe ver we staan

Voor de nieuwe pagina's hoef ik slechts iets uiterst eenvoudig in Common.js in te lassen (het 'enablen' van de input), dat doe ik vandaag (speelt geen rol of die dan al disabled staat of niet). Jij(?) of Carl(wanneer?) kunnen de betreffende Php-sequentie dan al aanpassen, of mij tijdelijk bevoegd maken (maar ik moet dan nog even kijken hoe dat allemaal gaat: ik laadde nog nooit .php op). Voor registratie gebruiker wachten we met die Php-aanpassing tot ik in Common.js ook de betreffende functie herschreef zoals ik deed voor nieuwe pagina's (in feite is het voor registratie een stuk eenvoudiger, maar wacht toch je reactie wel even af). Aangezien de Php-wijziging voor registratie gebruiker uiterst simpel kinderspel is, en op 1 na alle spammers van de laatste maand als geregistreerde gebruiker hun onheil aanrichtten, zet ik toch wel enige spoed achter ook die betreffende aanpassing in Common.js.
— SomeHuman 2012-09-18 01:38-02:51 (UTC=CEST-2)

Graag zeer dringend voor registratie gebruikersnaam in Php de uiterst eenvoudige aanpassing (want in vlot leesbaar Html) zoals nu hierboven staat (ik paste daarin zopas het allerlaatste definitief aan). Ondertussen werden alle functies in Common.js al aangepast om daarmee uitstekend samen te werken (ook met de moeilijker uit te voeren Php-aanpassing voor nieuwe pagina's) en ze werken ook zo al goed maar pas na die dringende gemakkelijke aanpassing in Php zullen (op totdusver twee IP-gebruikers na) de batterijen nu onvermoeibaar onafhoudende spamrobots gesperd raken.
— SomeHuman 2012-09-19 14:25 - 2012-09-20 01:52 (UTC=CEST-2)

Sorry voor mijn afwezigheid. Ik heb alles gelezen, maar ben er nog niet helemaal uit hoor. Ik kan 1 ding met zekerheid zeggen: ik heb noch rechten om de php-files te r-w-x'en, noch heb ik toegang via ftp. Ik kan dus geen aanpassingen maken in php. De enige uitweg is Carl gewoon mailen over de aanpassingen. Ik wil je best tot bureaucraat maken, maar je zult er niet veel wijzer uit worden vrees ik | Cartoonist | Contact | 22 sep 2012 21:47 (UTC)

Gedetailleerde aanvraag tot aanpassen van registratie gebruikersnaam in Php staat op Carls overlegpagina. Wil hem er per e-mail op wijzen.
— SomeHuman 2012-09-26 22:37-22:46 (UTC=CEST-2)

De mail is reeds verzonden. Ik wilde je nog in een CC zetten, maar vergat het gewoonweg | Cartoonist | Contact | 26 sep 2012 23:04 (UTC)

[bewerken] More is less

"In 2013 werden..." loop ik nu achter? — SomeHuman 2012-10-04 07:06 (UTC=CEST-2)

"Worden" natuurlijk... Je zou het ergens kunnen zien als een vrij absurde tijdskeuze om de pagina niet meer te hoeven updaten. Ik heb eerder een gewoonte om pagina's in de verleden tijd te schrijven. Soms ben ik toch zo'n warhoofd | Cartoonist | Contact | 4 okt 2012 07:27 (UTC)

"In 2012 besliste men dat (de volgende jaren / vanaf januari/leerjaar/ ...)" pas ik ook wel eens toe. Men kan het dan achteraf misschien korter verwoorden maar het is niet noodzakelijk het in een agenda bij te houden.
— SomeHuman 2012-10-04 07:34-07:44 (UTC=CEST-2)

Misschien hoeft Thomas More op MM geen artikel te krijgen, maar waar hij vermeld wordt kan er wellicht gewezen worden op zijn band met Mechelen via Jeroom Busleyden.
— SomeHuman 2012-10-04 07:58 (UTC=CEST-2)

Thomas More zelf niet nee. De bedoeling was gewoon naar WP te linken, that's all | Cartoonist | Contact | 7 okt 2012 19:43 (UTC)

[bewerken] Contact

Hi.
Je wijziging van daarnet:

• "VOOR U VERDER LEEST:" Op Mechelen Mapt, want daar was ik aan het lezen? Wat scheelde er aan "BELANGRIJK:"?
  
• "Wij zijn dus niet het bedrijf of de persoon die op onze website omschreven staat." Welk bedrijf, welke persoon? "Wij" of Mechelen Mapt is niet Mechelen Mapt?
  
• We... "en hebben geen bindingen met welk bedrijf of instelling dan ook" viel weg. Heeft de website verplichtingen tegenover een instelling waarmee een medewerker bindingen heeft? "We" viel m.i. te begrijpen als 'in hoedanigheid van website-beheerder/administrator/gebruiker' (dus de pseudoniemen) want als puntje bij paaltje komt, hebben alle geregelde Internetgebruikers en dus ook "wij" wel een binding al was het maar met bijvoorbeeld een Internetprovider. "We" is m.i. het geheel van (geregelde) MM-schrijvers; ga je mij blokkeren als ik een tamelijk objectieve maar wonderwel negatieve zin over een instelling zou plaatsen, waarmee jij een binding hebt (de leverancier van elektriciteit voor je PC, of zo)? Desnoods past "De website" i.p.v. "We", zo niet verwacht ik een klare uitleg aangaande haar bindingen.
  
• "Gebruik onderstaande gegevens dus alleen om ons over de werking van de website Mechelen Mapt te contacteren!" De "werking" valt te interpreteren als offline, slechte link enz. Is er een aspect aangaande de website, waarvoor men MM niet langs die weg mag contacteren?
  

De "website". Is er dan nog een andere Mechelen Mapt?

Werd je al langs een van die wegen gecontacteerd over iets anders? Die toevoeging in vetjes en dus in het bijzonder benadrukt, komt bij mij over als "Laat me g@vrheerenginder gerust met al jullie gezever! Het komt me de strot uit!"

Bizar en heel onduidelijk.
— SomeHuman 2012-11-19 03:44-05:58 (UTC=CEST-2)

P.S. Je verving het aantal ex door een aantal px. Dit laatste is dikwijls prima voor grafische elementen met decoratieve functie of thumbnails met link naar grotere afbeeldingen, maar voor grafische elementen waarvan de duidelijke zichtbaarheid binnen de pagina essentieel is en ook voor pure tekst, verdienen ex (in de breedte) en em (in de hoogte) meestal de voorkeur: een lezer mag zijn browser instellen voor een andere karaktergrootte [of voor hem/haar duidelijker 'font-family' die wellicht een andere x-breedte en andere lijnhoogte heeft], en dan wordt door ex en em ook de box daaraan netjes aangepast.
In de praktijk doen de meest gangbare browsers dat ook wel net zo goed voor px bij tijdelijk vergroten/verkleinen door Ctrl+/Ctrl-, maar ik weet niet of zulks door W3C aan browsers voorgeschreven is. Wie zoals slechtzienden echter zijn browser (permanent) instelt om voor de karaktergrootte aan de eigen voorkeur voorrang op die van de website te geven, is met px lelijk geschoren.
— SomeHuman 2012-11-19 04:12-05:58 (UTC=CEST-2)

Met "wij" bedoel ik Mechelen Mapt in zijn geheel, dus ik snap op dat punt je probleem niet echt. Volgens mij zoek je het nogal ver ;-D Ik stel vast dat mensen die ons een e-mail sturen vaak denken dat ze het onderwerp van de pagina (die ze net gelezen hebben) hiermee kunnen bereiken, wat niet zo is. Iemand die een pagina over Telenet leest en dan op "Contact" klikt, komt niet uit op de contactgegevens van Telenet. Logisch toch? Voor vele mensen dus niet. Vandaar die nieuwe zin. En "BELANGRIJK" blijkt niet doordringend genoeg, dus moet je iets concreter bedenken. Ik wilde overigens "werking en inhoud" zetten. Ben dat vergeten; dank voor het op te merken.

Op vlak van code ben ik erg liberaal. De vorige breedte was naar mijn mening wat te smal. Indien je je beter voelt bij een ex-waarde: ik houd je niet tegen! Cartoonist | Contact | 19 nov 2012 20:33 (UTC)

More clearly: mijn probleem met "Wij" was en is dat We [...] "en hebben geen bindingen met welk bedrijf of instelling dan ook" weggevallen is. De enige reden leek me dat je die "We" zag als betrekking hebbend op de onderscheiden personen die slechts een stukje van hun leven aan Mechelen Mapt spenderen, maar waarvan er daarbuiten wel eventueel zelfs professionele bindingen hebben met een bedrijf of instelling. Door precies die weglating, lijkt het erop dat Mechelen Mapt best wel de belangen van een zulke instelling voor ogen dient te houden. Met de oorsprong (Memori) verklaard op Mechelen Mapt, laat de naam van een zulke instelling zich vlot raden, en wordt uitgeoefende druk op een medewerker een denkpiste die nu niet langer expliciet geloochend wordt.
— SomeHuman 2012-11-21 06:58-07:34 (UTC=CEST-2)

Je zoekt het echt veel te ver. Dat zinnetje heb ik niet om die reden laten vervangen. Ik wilde gewoon alles herschrijven met oog op meer duidelijkheid naar de lezer toe. Ik begrijp nu wat je bedoelt, maar ik word zeker niet onder druk gezet. Indien dit gebeurt, zal ik de zware middelen bovenhalen die in het nadeel zullen spelen van de desbetreffende instelling | Cartoonist | Contact | 21 nov 2012 11:57 (UTC)

PS: Memori noch de hogeschool hebben nog iets met de wiki te maken.

[bewerken] Tekeningen & Schilderijen

Hi Henning.

Je hernoemde drie "Tekeningen & Schilderijen: <artiestennaam>" naar <artiestennaam>.

Ik denk dat je er een onnodig en moeilijk netjes op te lossen probleem mee veroorzaakt: Het gaat om artiesten die (meestal) niets met Mechelen te maken hebben gehad, behalve dat ze eens een Mechels zicht of Opsinjoorke grafisch voorgesteld hebben. Precies die voorstelling is het onderwerp van het artikel en slechts dat verdient een plaats op MM. De link bij de naam van de artiest verwijst meestal naar een uitgebreid artikel op Wikipedia. Dat is nogal moeilijk te evenaren, hoort niet op MM thuis, en aan de andere kant is het nogal bespottelijk een stompje van een artikel te hebben dat dan naar dezelfde artikelnaam op Wikipedia verwijst.

Er bestaan meer dan die drie "Tekeningen & Schilderijen: <artiestennaam>". De meeste van die grafische werken hebben echter zelf geen algemeen aanvaarde of gekende benaming. Vandaar de oude oplossing. Ze was dus nog zo gek niet. Ik hield me maanden eerder ook even met die reeks bezig, en dacht toen al over die 'categorie'-titels na. Als er toch eens een niet-Mechelaar zou zijn waarover Wikipedia geen (goed) artikel heeft, kan je bij de 'Externe links' naar een andere site verwijzen of desnoods even zelf een hoofdstukje 'Over de kunstenaar' of 'Relatie van <familienaam van de artiest> tot Mechelen' inlassen.

Voor Ost hoort op MM wel een artikel thuis, net als voor alle Mechelaars onder de gekende grafici. Ost had een atelier hier, en zijn uitgebreid oeuvre over Mechelen is wel wat anders dan een enkel werkje van de buitenlander Petrie. Voor die man hoort gewoon geen artikel op Mechelen Mapt.
— SomeHuman 2013-02-10 01:52-02:05 (UTC=CEST-2)

Ik heb dit bekeken vanuit een gebruiksvriendelijk oogpunt. De lange titel met hoofdletters en een ampersand is niet zo handig bij het verwijzen als externe link op een andere website. Wat je vindt van over wie we artikels horen te schrijven ben ik het er niet echt mee eens. Ik beschouw ieder bemerkenswaardig persoon die ooit iets met Mechelen had als relevant, ook Petrie. Ik maak daarin geen onderscheid, omdat de encyclopedie moet openstaan voor zo veel mogelijk feiten en personen. Mocht Obama nu naar Mechelen komen, houd ik niemand tegen om er een artikel over de man te schrijven (uiteraard moet de link met de stad de rode draad zijn; details weet Wikipedia wel) | Cartoonist | Contact | 10 feb 2013 02:15 (UTC)

Begin maar artikels te schrijven over Lodewijk XV, over Napoleon, over Leopold I, over Albert I, over Johannes Paulus II, over... Het is niet omdat drie ervan de Toren beklommen, een andere even per trein kwam goeiedag zeggen maar geen station kon vinden, en de laatste een mariabeeld wou zien, dat een artikel hun naam mag dragen. Wel bijvoorbeeld "Torenbeklimmingen", "Eerste trein" of "Pausbezoek" indien er voldoende stof voor zulke artikels zou beschikbaar zijn. Waarschijnlijker wordt het simpele feit in een lijntje of hoofdstukje vermeld in de artikels over de Toren, het station of het spoorwegennetwerk, respectievelijk de Hanswijkbasiliek. Het is niet eens duidelijk (in het huidige artikel) of Petrie ooit Mechelen bezocht (if so, so what - who didn't?), de 'band' met Mechelen is me veel te mager. Zijn schilderij heeft met Mechelen te maken, dus verdient dat een artikel. Een artikel dient een naam te hebben die op het onderwerp slaat. Lijkt me erg evident.
Hernoem de artikels (met doorverwijzing) naar "Tekeningen en Schilderijen: <artiestennaam>" zodat de ampersand geen problemen kan geven; ze staan trouwens reeds in een categorie met 'en' i.p.v. een ampersand.

Je geeft blijkbaar teveel aandacht aan je eigen interessesfeer. Elke voetbalist en basketter van Malinois of Racing (2x) heeft meer met Mechelen te maken gehad, en velen hadden meer bekendheid, dan Petrie. Dat geeft dan veel te veel nutteloze artikels, wijl er nog zoveel echt over Mechelen, gewoon ontbreken.— SomeHuman 2013-02-10 19:07-19:11 (UTC=CEST-2)

Een pagina "Celebs in Mechelen" zou niet misstaan, maar ik begin wel te begrijpen wat je zegt over artikelnamen. Alleen vind ik dan dat we de drie pagina's op 1 enkele pagina kunnen gooien: Tekeningen en schilderijen. Mocht er nu rond een tekening of schilderij heel veel te vertellen zijn, kan het in een apart artikel. Is dat een logischere oplossing? Cartoonist | Contact | 11 feb 2013 03:17 (UTC)

Het zijn er nu al veel meer dan die drie, check maar even in 'zoeken' op "Tekeningen" en zie wat er (zelfs na de 3 die je veranderde) allemaal verschijnt. En dat is dan wellicht maar het topje van de toekomstige ijsberg: er zullen nog veel meer grafische werken van niet-Mechelaars over onze stad bestaan en vroeg of laat komen we het te weten. Vooral omdat ook de foto van elk schilderij of tekening in de pagina komt, zou die potentieel ellenlange pagina bij een wat tragere verbinding (of als de MM-server weer eens kuren krijgt) ernstige problemen kunnen veroorzaken. De oplossing met het predikaat was niet de mijne, maar ze lijkt me nog wel de beste (of de weg van het minste kwaad). En het dozijn dat we al hadden, kan dan blijven als het was. Dat bespaart werk: slechts die 3 terug hernoemen of best allemaal naar "Schilderijen en Tekeningen:" [volgorde en zonder ampersand zoals de categorie], gaat sneller dan alles (3 + 9) omwerken naar gelijk wat. Misschien is "Grafisch werk:" een nog betere naam (ik denk aan etsen en de categorie:Grafici) maar misschien ken jij 1 woord daarvoor?
— SomeHuman 2013-02-11 09:35-09:44 (UTC=CEST-2)

1 pagina "Grafische kunst" gewoon? Het is uiteraard meer dan schilderijen en tekeningen, gezien het bestaan van etsen, zeefdrukken en nog wat. Mocht de pagina in kwestie te lang worden, dan maken we van Grafische kunst een doorverwijspagina met een overzicht van deelpagina's (op alfabet - schuine streep A tot ... en ... tot Z - of genummerd of per stroming/kunstenaar...). Maar daartegen denk ik dat we toch al enige tijd verder zijn | Cartoonist | Contact | 12 feb 2013 00:33 (UTC)

"Grafische kunst" is te vaag: dat omvat ook stijlen, kunstenaars,... — het gaat louter om kunstwerken, "Grafisch werk". Een titel moet duidelijk zijn (= doen verwachten wat men levert of vooral niet iets anders leveren dan wat men verwacht); vóór de naam van een kunstenaar zou "Grafische kunst" meteen misleiden. Met de onbetrouwbare mobiele 2G-verbinding die ik vorig jaar gedurende maanden 'genoot', zou een pagina met dertien foto's me al serieus doen vloeken hebben.
— SomeHuman 2013-02-12 01:50 (UTC=CEST-2)

Grafisch werk is OK voor mij. Het is hier een wiki, wat ons toelaat om op een gemakkelijke manier een mouw aan iets te laten passen, mocht de omvang van de pagina echt een probleem worden. Zolang artikels niet enkel een paar lijntjes omvatten... Cartoonist | Contact | 12 feb 2013 01:59 (UTC)

[bewerken] Onze-Lieve-Vrouw-over-de-Dijlekerk

Dag Henning.

Ziehier mijn bewerkingscommentaar bij het voormelde artikel:

BIZAR: begintag googlemap t.e.m. eindtag /googlemap weghalen, met nochtans perfecte syntax, met behoud van de div errond, doet 'references'-anker verschijnen en werken, met de map blijft die onzichtbaar en het indexje doet niets.

Ik pluisde reeds alle elementen in het ganse artikel na en verbeterde de syntax waar dat ook maar even kon, om op zeker te spelen. Ik verving mijn sjabloon 'Citeer web' tussen <ref> en </ref> reeds door het simpele woordje TEST, zonder verbetering. Ik haalde het sjabloon 'Bron?' eruit, zonder verbetering. Ik verwijderde de ganse <−− ... −−>, zonder verbetering. Maar <googlemap> ... </googlemap> eruit lichten, loste het probleem meteen op. Ik keek die googlemap syntax nog goed na, hertikte zelfs die lijntjes, maar zodra die aldus terugstaan, blijkt het <references />-anker niets meer te tonen, het indexje dat bij <ref>...</ref> hoort, ziet men wel, maar erop klikken doet niets. In andere artikels zie ik wel alle referenties en die werken prima. Blijf ik dan toch nog iets over het hoofd kijken? Enig idee?
— SomeHuman 2013-02-18 08:37 (UTC=CEST-2)

Commentaar bij mijn volgende bewerking:

BLIJFT BIZAR, maar opgelost: een spatie aan het begin van de lijn, net voor de (O), doet het probleem verdwijnen... maar bij mijn weten is die spatie normaal niet voorzien.

MM heeft nochtans meerdere pagina's (Gouden Vis, Dossinkazerne en wellicht allemaal die zulk markeerpunt in googlemap plaatsen), zonder spatie voor de (X), en alvast die voormelde artikels tonen hun <ref>...</ref> correct onder 'Bronnen'. Ook de pagina voor de O.-L.-Vrouwekerk werkt nu wel, maar het vreemde en bovenal onvoorspelbare blijft.
— SomeHuman 2013-02-18 09:35-09:48 (UTC=CEST-2)

Ik denk dat ik dit ooit al meegemaakt heb, al herinner ik me de preciese omstandigheden niet meer. Tekst tussen nodes worden normaal gezien niet geschikt zoals je dat zelf wilt en kan de extensie dit aanzien hebben als een doorlopende tekst die aaneen plakt | Cartoonist | Contact | 24 feb 2013 02:14 (UTC)

De extensie reageert verschillend in pagina's die een identieke (googlemap) syntax blijken te hebben, er treedt een wisselwerking op met een ander element:

1. OLV-o-d-D had geen open lijntje meteen na de het sjabloon 'Translation' en de 'Afbeelding', maar dat lijntje inlassen help niet.
2. De (div) met (googlemap) uit 'Gouden Vis' doet in OLV-o-d-D ook de referenties verdwijnen, tenzij men een spatie voor de (G) plaatst.
3. De (div) met (googlemap) opnieuw zonder spatie in OLV-o-d-D, laat de referenties netjes verschijnen als die (div) verplaatst wordt bovenin de pagina i.p.v. na een subtitel. Verplaatst tot onder een subtitel lager dan de oorspronkelijke, verdwijnen de referenties ook, maar verplaatst tot onder de bovenste subtitel, komen de referenties wel netjes tevoorschijn.

• Tussen de bovenste, 'Geschiedenis', en die waaronder de (div) een fout veroorzaakt, 'Openingsuren en concerten', worden zowel mijn sjabloon 'Citeer web' (waarvan de output in de referenties hoort gezien te worden) als mijn sjabloon 'Bron?' gebruikt. Als ik beide weghaal (en het woord 'referentie' tussen de (ref) begin- en eindtags intik, blijft de fout toch optreden; als ik het 'Citeer web' verplaats tot onder de (div) met (googlemap), verschijnen de referenties. We zijn dus zeker dat noch 'Bron?', noch 'Citeer web' een element kan zijn waarmee een ongelukkige wisselwerking optreedt. Ook de (span) die de font-size van de gekapitaliseerde tekst verkleint, blijkt in orde...

Andere benadering:

1. In 'Gouden Vis' staat de (div) met (googlemap) helemaal bovenaan, meteen onder 'DISPLAYTITLE', 'Translation' en 'Afbeelding'. Ik laste net boven de (div) een lijntje in: TEST.<ref>Referentie</ref> met als resultaat noppes, 't is te zeggen dat 'Referentie' niet verschijnt boven de overige referenties in die pagina.
2. Dus haalde ik 'DISPLAYTITLE', 'Translation' en 'Afbeelding' weg. Er staat dan slechts een minimalistische referte gevolgd door een (div) met (googlemap) helemaal bovenaan. De referte wordt niet getoond.
3. Dus haalde ik de (div) omheen (googlemap) weg. Er staat dan slechts een minimalistische referte gevolgd door puur (googlemap) helemaal bovenaan. De referte wordt niet getoond. Als ik dan de spatie voor de (G) binnen (googlemap) inlas, verschijnt de Referentie.

Misschien bevat de (googlemap)-extensie een foutje, maar het kan ook aan de (ref) liggen of aan de wijze waarop de wiki pagina's inleest.

Dit is een van de redenen om steeds strikt correct gedocumenteerde Html enz. te benutten, vooral ook in sjablonen, extensies enz.: anders loopt men veel meer risico dat een invloed zich doet gelden buiten dat wat men op het oog heeft, bij onvermoede elementen en op onvoorspelbare plaatsen.

CONCLUSIE: Vermits we de software niet gaan of kunnen aanpassen, en aangezien men nooit bij voorbaat weet of een (googlemap) later verplaatst gaat worden en er dan best een mogelijk later geplaatste (ref) zou kunnen aan voorafgaan, moeten we systematisch een spatie inlassen. Bestaande pagina's dienen daartoe ook herzien te worden.
— SomeHuman 2013-02-24 07:38 (UTC=CEST-2)

DIK PROBLEEM: Het was me nog niet opgevallen, zelfs niet in de pagina OLV-o-d-D, maar de 'oplossing' met spatie, plaatst doodleuk geen markeerpunt in het kaartje. Tot nader order ziet het er dus naar uit dat we geen markeerpunten mogen plaatsen. Het is namelijk volslagen ontoelaatbaar iets in een pagina te zetten dat zulk belangrijk probleem kan veroorzaken, als moeizaam opgezochte en ingelaste referenties (bestaande of later aangebrachte) domweg niet tonen.

Misschien is een iets andere syntax in (googlemap) mogelijk maar die is me nog niet bekend. Ik probeerde reeds een extra open lijntje boven de (X), en ik probeerde de (X)-lijn inline achter de (googlemap)-begintag: de resultaten blijven: ofwel met spatie geen markeerpunt, ofwel zonder spatie geen referenties. Zelfde resultaten zonder (X) zodat een zwarte punt i.p.v. een letter als markeerpunt verschijnt.
— SomeHuman 2013-02-24 08:01-08:09 (UTC=CEST-2)

Noodoplossing: Indien een markeerpunt gewenst is, moet de (div) met (googlemap) bovenaan, onder 'DISPLAYTITLE', 'Translation' maar boven 'Afbeelding' (omdat die een bijschrift met ref kan krijgen) en inleiding. Dit vergt dan tevens een lijnenpaar erboven:

<!-- NIET VERPLAATSEN: GOOGLEMAP MET MARKEERPUNT (en de DIVs er omheen) MOETEN STEEDS HELEMAAL BOVENIN EEN PAGINA!
     MAG NA {{Translation|…}} EN DESNOODS 1 of meer [[Afbeelding:…]] MITS DAARIN NOOIT <ref (…)>…</ref> ZAL KOMEN! -->
De nodige aanpassing in 'Extra's bij bewerken [tonen]', werd al aangebracht.
Zie Forum:Google Maps‎#Bug: Markeerpunt in Google Maps verhindert tonen van hoger in de pagina geplaatste referenties.
—SomeHuman 2013-02-24 08:35 - 2013-02-25 06:24 (UTC=CEST-2)

Je testte al een en ander uit op het forum. Het kan makkelijker en in gelijk welke pagina, zonder 'Opslaan': het euvel is reeds goed te zien bij 'Bewerking ter controle bekijken'. Ik hou liefst de formulering van de instructies en van de twee lijnen bewerkingscommentaar conservatief, principieel eerder afradend om een (Afbeelding) boven de (div) met (googlemap) te plaatsen, zodat men het probleem terdege voor de geest houdt. In de praktijk zal dit echter zelden reden geven om het kaartje absoluut bovenaan te zetten: De dubbellijnige commentaar trekt genoeg aandacht opdat een eventueel later ingelaste (ref) in een bijschrift, de plaatser ertoe zou aanzetten om [pas] dan de bewuste (Afbeelding) tot onder de (div) met (googlemap) te verplaatsen.
— SomeHuman 2013-02-26 09:40 (UTC=CEST-2)

Ik breidde de test (nu als onderdeel van het hoofdstuk) gevoelig uit tot een gedetailleerde demonstratie van het euvel (dat zich ook voordoet indien een ikoontje als markeerpunt geplaatst wordt en indien een sjabloon de googlemap opbouwt), met opsomming van vaststellingen en met mijn analyse: Ik heb zo een idee waar het virtueel kalf gebonden ligt maar de knoop kunnen wij allicht niet ontwarren.
— SomeHuman 2013-02-26 18:05 - 2017-02-26 06:25 (UTC=CEST-2)

[bewerken] Lijst bewerkingen

Hi Henning. Ik zocht zopas naar een (door mezelf onlangs bijgewerkte) MediaWikipagina en merkte dat jij eerder deze maand een pagina "Mycontris" aanmaakte. Ik vermoed dat dit een typo is, en "Mycontribs" had moeten zijn; deze laatste bestaat nog niet. Op een andere wiki zag ik 'contributions' al afgekort tot 'contribs'.
— SomeHuman 2013-02-27 12:04 (UTC=CEST-2)

Dit is inderdaad een typo in het systeem, omdat ik het bewuste MediaWiki-systeembestand onder die naam zo vond. De mensen van TranslateWiki zijn hiervoor verantwoordelijk, denk ik. Ik zou het gewoon laten staan | Cartoonist | Contact | 27 feb 2013 23:45 (UTC)

Bug #44433 (2013-01-29) blijkt in de beste handen!

Bug #43500 (2013-02-14) loste het al op als ZALNIFIKSE.  :-))
— SomeHuman 2013-02-28 03:08 (UTC=CEST-2)

[bewerken] Inlas

Dag Henning. Een heel artikel ergens inlassen is makkelijk, maar weet je of het ook mogelijk is om slechts een hoofdstuk over te nemen? Iets als {{:Brusselpoort#Extra}} last jammer genoeg toch het hele artikel in, hoewel 'Extra' een titeltje is in 'Brusselpoort'.
— SomeHuman 2013-03-01 02:02 (UTC=CEST-2)

Het hekje verwijst alleen maar door naar de heading h2 - h5 door de href="#tussentitel", niet naar de sectie. Laat staan dat je de sectie kunt transcluderen. Dit zou gemakkelijk opgelost kunnen worden door de parserfunctie #lsth, die hier blijkbaar niet bestaat. Het principe is {{#lsth:Paginatitel|Ondertitel}}. Zie mw:Extension:Labeled_Section_Transclusion. De vraag is of je dit nodig acht op MM, dan kan ik een poging wagen om het aan te vragen bij Carl | Cartoonist | Contact | 2 mrt 2013 17:50 (UTC)

Ik heb het toch al enkele keren willen hebben. Het is vooral interessant als men iets wil tonen dat tot een groep van dingetjes behoort, die dan best in 1 pagina terecht komen (en daar gezamenlijk eventueel onderhouden worden), zonder het publiek of de gebruiker naar de eventueel voor hen/hem/haar verwarrende rest van die dingetjes te brengen.

Het is best denkbaar (hoewel niet evident) dat een hoofdstuk uit een artikel in een ander hernomen wordt: niet als link omdat het te belangijk is ook voor dit hernemend artikel en een link wordt nu eenmaal meestal niet gevolgd (daarvoor zijn er te veel en de lezer beseft het belang van die ene bepaalde niet).

Ik denk ook aan een gebruikerssubpagina waarin een aantal voorbeelden en probeersels bewaard blijven, waarvan ik iets in jouw en/of G's overlegpagina wil tonen (of bij gelegenheid aan een andere gebruiker)

Interessant is een soort hulppagina met adviezen en voorbeelden die niet iedereen nodig heeft (het duurt jaren voor men alle hulppagina's van WP enz. doorploegd heeft, ik hou het op MM liever voor de meesten summier of tot enkele onderwerpen beperkt), maar die men zonder al de overige poespas uit die pagina aan een door de omstandigheden bepaalde gebruiker wil tonen.

Op het moment dat de behoefte zich stelt en echt belangrijk blijkt, moet de technische mogelijkheid natuurlijk bestaan - zeker als men met een hoogst onwillige serverbeheerder opgescheept zit.

Daarnaast is er nog een wat aparte behoefte: In een gebruikerssubpagina wil ik enkele problematieken [methoden waarop iets werd opgelost] uit verscheidene artikels samenbrengen. Als die artikels ooit gewijzigd worden, zie ik ook het voorbeeld gewijzigd, en weet ik dat het daar geen rol meer speelt.
— SomeHuman 2013-03-03 00:53-01:20 (UTC=CEST-2)

Er is nog een extensie die blijkbaar op MM ontbreekt: SpamRegex. Die zou wellicht niet hoeven als Carl eindelijk de herhaaldelijk in extenso aangegeven Php-aanpassing zou doen. Ongewapend kan men zich niet tegen een goed uitgerust leger verdedigen.
— SomeHuman 2013-03-03 10:29 (UTC=CEST-2)

[bewerken] IPv6

Henning, wijl je eventueel toch Carl contacteert: Tenzij jij zou weten hoe men op MM een range block voor een IP-adres versie 6 kan plaatsen, denk ik dat er een aanpassing op de server nodig is. We kunnen blijkbaar wel een compleet IPv6-adres blokkeren (2604:180:0:0:0:0:98D3:EC01) maar dat heeft misschien weinig zin (want eenzelfde gebruiker kan eventueel reeds zelf over een soort persoonlijke range daarrond beschikken). Als we iemand niet eens meer gaan kunnen blokkeren, zeker na meer algemeen toepassen van IPv6 i.p.v. IPv4 vooral als de spammers er dan als de kippen bij gaan zitten, gaat de boel hier vroeg sluiten, vrees ik. Op mijn eerdere pogingen tot range block (wat in dit geval voor 2604:180::/32 zou zijn) verschijnt echter een foutmelding alsof dat een onbestaand adres is.
— SomeHuman 2013-03-03 09:49-11:40 (UTC=CEST-2)

Ik heb weinig benul van een correcte ranges, misschien kan dit helpen? Cartoonist | Contact | 3 mrt 2013 20:32 (UTC)

Dat had ik al gezien, en ik begreep eruit dat wij met onze huidige 1.17alpha slechts één persoonlijk subnet (/64) kunnen blokkeren tenzij $wgBlockCIDRLimit een grotere range zou specifiëren. Vanaf versie "1.20wmf5" zou de default op de meer bruikbare /19 staan (zogezegd 35.184.372.088.832 verschillende eindgebruikers maar het kunnen er ook 'maar' 536.870.912 zijn; in feite eventueel slechts een theoretisch maximum van 16.384 verschillende 'organisaties' in dat jargon). 'Grote en erg grote organisaties' en ISPs (zoals de onbetrouwbare waarvan we IPv4 ranges tot /16 kunnen blokkeren) hebben typisch ranges van size /32 tot /12. De default-maximumgrootte van /19 bij IPv6 zal dus voor praktisch gebruik allicht zowat even nuttig (hoewel niet steeds geheel voldoende) zijn als de huidige /16 bij IPv4, waarbij we ook al eens /9 tegenkomen voor erg grote providers. Zulke echte reuzen willen we in principe niet compleet blokkeren, zelfs niet voor niet-geregistreerde gebruikers want die moeten toch ergens een kans krijgen om zich te registreren - maar voor ISPs uit sommige landen die de facto erg weinig ondernemen tegen hun voornaamste ISPs die onbeschaamd zelfs op Sorbs enz. geblockliste spam-IPs laten begaan, zou een grotere range dan IPv4 /16 en wellicht IPv6 /19 wel nuttig kunnen blijken. Voor MM zou het trouwens niet zo erg zijn dat men zich slechts vanaf een Belgische of Nederlandse ISP kan registreren (naast die buitenlandse die toevallig het voorbije jaar geen enkel IP hadden dat op MM spamde - Jammer voor DTAG (Duitsland) met IPv4 /10, maar helaas: die hangt me vrijwel dagelijks de keel uit).

Ik stel dus voor dat Carl ervoor zorgt dat we, welja, zelfs IPv4 /10 en dan ook overeenkomstig IPv6 /13 kunnen blokkeren door afwijking van de huidige defaults in $wgBlockCIDRLimit. MINSTENS de normale IPv6 default van recentere MediaWikisoftware, /19, is absoluut vereist.

Dat alles was gisteren echter niet de hoofdreden van mijn berichtje: Het begin en einde van de range van een ISP waarvandaan spammer 2604:180:0:0:0:0:98D3:EC01 had gewerkt, wordt door externe 'IP check'-sites gemeld als zijnde 2604:180::/32. Maar in het huidige blokkeringvenstertje, geeft zelfs 2604:180::/127 (een prutsklein stukje van een subnet van eenzelfde eindgebruiker) toch de foutmelding "De gebruiker "2604:180::/127" bestaat niet. Controleer de schrijfwijze." Ik ontdekte inmiddels dat onze software de gebruikelijke shorthandnotering van een range niet snapt, maar wel de uitgespelde als 2604:180:0:0:0:0:0:0/32. Aangezien we nog met de oude MediaWikiversie zitten, is die zeer realistische range echter te groot: "Reeksblokkades groter dan /64 zijn niet toegestaan". Zoals gesteld, heeft die niet meer (en mogelijk minder) uitwerking dan een klassieke blokkering van een enkel IPv4; het is geen 'echte' range. Indien we "het IP" van een enkele spammer willen blokkeren, en dit blijkt een IPv6, dan moeten we meteen /64 blokkeren. Dus niet 2604:180:0:0:0:0:98D3:EC01 maar wel een range /64. Het is me echter niet zo meteen evident waar die persoonlijke range dan precies begint... als ik dat voor elke spammer ook nog eens zou moeten uitzoeken, zou ik ermee stoppen. Ik blokkeer echter nu ook al geen individueel IPv4 meer (behoudens geregeld uitzonderingen, maar die gaan zeldzamer worden als de waarden in $wgBlockCIDRLimit als hierboven gewenst, verhoogd worden). Ik blokkeer namelijk desgevallend de geregistreerde gebruikersnaam en steeds quasi automatisch (wijl ik me toch realiseer waarmee ik bezig ben) uitsluitend niet-geregistreerden uit de ganse range (meestal slechts 1 van vele die een ISP heeft) vanwaaruit een IP spamde, welke range anders het waarschijnlijkst (vanaf een dynamisch IP of meerdere vaste binnen eenzelfde organisatie) voor meer problemen zou zorgen. Dat moeten we ook voor IPv6 kunnen.

Vermits ik IPv6-shorthands door een 'IP check'-site gerapporteerd krijg, is het wel erg onhandig dat ik die manueel ga moeten corrigeren om ze te kunnen blokkeren. Maar dat aspect gaat Carl niet kunnen verhelpen. Het wordt hopelijk verbeterd in MediaWikiversie 1.20.3 of zo. Misschien krijgt 1.21.0 wel aparte items (met grote default range) in $wgBlockCIDRLimit voor de gevallen waarbij 'alleen niet-geregistreerde gebruikers' geviseerd worden.
— SomeHuman 2013-03-04 07:06-07:59 (UTC=CEST-2)

[bewerken] Oratoren

Dag Cartoonist,

Hou je cursor even over elk van de twee 'bron?'-vragen in Oratorenstraat. Je link naar WP leidt niet tot Oratorianen te Parijs en mijn in tooltip getoonde bron noemt (in de Mechelse context) Scherpenheuvel voor hun herkomst. Hoewel de straat misschien niet de meest voor de hand liggende was om naar de orde genoemd te zijn, lijkt het me te sterk "geen verband met de locatie" expliciet te vermelden, gezien de nabijheid van het bezit extra muros van de Oratoren (waarnaar de Zwartkloosterstraat genoemd is).

Bij ontstentenis van een volwaardig artikel over de Oratoren te Mechelen, maakte ik 'Oratoren' aan als doorverwijzing naar Oratorenbrug, letterlijk tussen de locaties voor beide voor Mechelen belangrijkste rollen van de orde, welke dat artikel dus noodzakelijk aanstipt.
— SomeHuman 2013-05-04 23:39 (UTC=CEST-2)

À propos Paris: ik zal morgen eens onderzoeken waarom ik dat zou verward hebben. Er is ergens op MB wel sprake dat de Oratorianen gestuurd werden vanuit Parijs, maar daarna moesten uitwijken. Misschien is het schrappen van enig geografisch adjectief hier op zijn plaats, omdat de uiteindelijke afkomst van gering belang is. Naar alle waarschijnlijkheid bestond de lokale orde uiteindelijk ook uit lokale mensen. Maar op dat vlak gis ik enkel.

Wat ik dus bedoelde is dat op de exacte locatie van de straat nooit echt iets meer is geweest dan hooguit een voetweg/grenspad op het domein Vorschenborgh. Bij de uitbouw van de straat in het interbellum - als ik moet afgaan op de historische maquettes van het Spoorwegmuseum en een overzichtskaart van 1920 - zit men al heel lang na de bloeiperiode van de Oratoren. Het klopt dat op enkele honderden meter ervandaan dat huis van die orde er ooit stond, maar ik vind dat eigenlijk al een verre (en sta me toe ook te zeggen een kunstmatige of toegedichte) verwantschap. Wat natuurlijk niet wil zeggen dat het onvermeldenswaardig is | Cartoonist | Contact | 15 mei 2013 00:26 (UTC)

Dit is niet belangrijk voor het artikel 'Oratorenstraat' omdat de orde al in de Mechelse binnenstad was toen ze de hoeve erfde, en vermits Oratoren naar Oratorenbrug doorverwijst in de verwachting dat dát artikel over de letterlijke en figuurlijke brug tussen haar meest noemenswaardige locaties in de binnenstad, beter geschikt is om info over de oratorianen te Mechelen te verzamelen (tenzij er een uitgebreid apart artikel voor zou geschreven worden). Maar dáár horen we wel de herkomst aan te geven. Er is een bron (en er zijn er meer) voor Scherpenheuvel. Gokje: Scherpenheuvel kan afgehangen hebben van Parijs of (eventueel indirect) vanuit Parijs gesticht zijn: Vele orden verspreidden zich vanuit hun oorsprong naar verscheidene locaties toe, waarvandaan telkens een verdere verspreiding voorkwam, enzovoort.

Eenvoudig naar willekeurige 'oratorianen' verwijzen volstaat zeker niet voor de Oratorenstraat: De kans dat een straat slechts een paar honderd meter van de hoeve op de Halfgalg, louter 'toevallig' de naam draagt van de orde die de hoeve bezat terwijl het gehucht errond ontstond, is statistisch quasi nihil. Ik schreef er dus nu in wat we wel en wat we niet weten.
— SomeHuman 2013-05-15 13:31 (UTC=CEST-2)

In het artikel Oratorenstraat is die oorsprong niet zo van belang nee. Het is alleen dat het kan overkomen alsof de Oratorenstraat een centrale rol heeft gespeeld in het ontstaan van het gehucht, wat volgens mij dus niet is. Maar je bedoelt dat uiteraard ook niet op die manier, want je moet op een of andere manier naamsoorsprong van de straat verklaren. Zolang de lezer zover is dat de straat er gewoon naar vernoemd werd, is het voldoende. Zoals het er nu uitziet, is het voor mij in orde hoor. Mocht het artikel alsnog onjuist zijn, moeten mensen zich vrij voelen het aan te passen | Cartoonist | Contact | 16 mei 2013 17:24 (UTC)

Hebben jullie hier wat aan ? https://inventaris.onroerenderfgoed.be/dibe/relict/1422 --Gimycko 16 mei 2013 18:10 (UTC)

Staat al in het artikel Halfgalg | Cartoonist | Contact | 16 mei 2013 18:16 (UTC)