Wikipedia:Visuele tekstverwerker/Feedback/Archief/sep 2014

2: Zeer veel sjablonen missen nog TemplateData

Toevoegen van deze TemplateData zou een enorme verrijking zijn voor het gebruik van de editor. Misschien goed om dat gestructureerd aan te pakken. Hoe krijg je ook weer een lijst van meest gebruikte sjablonen? –Frank Geerlings (overleg) 9 jul 2014 13:41 (CEST)

Die staat hier. Ik weet dat de ontwikkelaars bezig zijn met een hulpmiddel om makkelijker TemplateData toe te voegen door middel van een grafische interface. Sjoerd de Bruin (overleg) 9 jul 2014 14:28 (CEST)

Ik las (ik geloof hierboven in dat nieuwsbericht) dat het er al is, en dat je kan vragen het voor jouw wiki aan te laten zetten. Idee? –Frank Geerlings (overleg) 9 jul 2014 14:39 (CEST)

Voor wie de TemplateDataEditor wil gebruiker, zie en:User:NicoV/TemplateDataEditor voor documentatie en wat je aan je .js moet toevoegen om het 'aan' te zetten. Ad Huikeshoven (overleg) 10 jul 2014 21:38 (CEST)

status Vervelend dat de TemplateData nog niet ingevuld zijn. Aanzetten van VE is waarschijnlijk de grootste stimulans om TemplateData ingevuld te krijgen, of, het ontbreken ervan is niet echt een belemmering om VE aan te zetten.

De TemplateDataEditor of Sjabloondocumentatie beheerder is aangezet op deze wiki, Frank Geerlings en Sjoerddebruin, je vindt hem bij bewerken van een sjabloon. Ad Huikeshoven (overleg) 1 aug 2014 00:44 (CEST)

Het ziet er fraai uit als je het popupscherm gevonden hebt. Misschien wat intimiderend, met name voor beginnende bijdragers, maar er is duidelijk aan te zien dat er veel werk in heeft gezeten, het scherm laadt en beweegt heel soepel.

De inhoud van de descriptionparameter verschijnt nu als een beetje los zand op een plek als Sjabloon:Tekstkleur#TemplateData en dubbelop met eerdere tekst op onder meer Sjabloon:Afzender. Vanwege de verhouding tussen het aantal bezoeken aan een sjabloonpagina en het aantal daadwerkelijke bewerkingen is dat volgens mij een probleem, misschien niet heel groot, maar wel significant. De parameter is alleen bedoeld voor de popup, begrijp ik uit dit overleg (al begrijp ik niet wat het nut dan is, ik ben geneigd de klacht "dat de software alleen maar moeilijker wordt gemaakt om zogenaamd het makkelijker te maken" te onderschrijven), maar het is schijnbaar niet mogelijk hier iets aan te doen in de verantwoordelijke code. Is er een link naar een verklaring van de ontwikkelaars hierover? Ze kunnen er bijvoorbeeld wel "<p class="mw-templatedata-doc-desc">...</p>" omheen zetten. In dit geval kunnen we er zelf wat aan doen door de regel ".template-documentation.mw-templatedata-doc-desc{display:none}" aan de standaardstijl toe te voegen. Dat lijkt me een eenvoudige oplossing, hoewel dus een stoplap. Voor de volledigheid, de beschrijving en de parametertabel staan in een div met class "mw-templatedata-doc-wrap", de tabel zelf kan via "mw-templatedata-doc-params" worden aangepast. Ik stel voor dat we deze aspecten aandacht geven voordat de templatedata massaal worden toegevoegd aan sjablonen. Verrijking van het gebruik van de editor is natuurlijk heel fijn maar is geen doel op zich, duidelijkheid voor de bezoeker is dat wel. Ivory (overleg) 28 aug 2014 23:25 (CEST)

Hi, maybe I can help with this? A summary in English would be much appreciated. Thank you! Elitre (WMF) (overleg) 29 aug 2014 13:33 (CEST)

Hello Elitre, thanks for your time and attention. It's not a big issue, in my view, but one that can save the readers a lot of confusion when thought through properly. The problem I see is this: the contents of the description-parameter that is used by the templatedata-popup appears as plain text when a templatepage is viewed normally, i.e. without editing, where a description text is already provided (usually, if all is well) at the top of the 'sjabloonbeschrijving' (template description). In the example of Sjabloon:Afzender you can read the lines "Soms vergeten gebruikers hun opmerkingen te ondertekenen. Om ervoor te zorgen dat hun opmerkingen niet langer zonder afzender op een overlegpagina staan kan dit sjabloon worden toegevoegd. Dit werkt ook voor anoniemen." twice. This is confusing and a little irritating, because you don't know that it is a literal repetition of the earlier text until after reading it, and because it shouldn't be necessary. It comes across as sloppy, careless and uninterested, the last things we need to attract those eagerly awaited new contributors and stop the "decline in new contributor growth" which the VisualEditor was meant to turn around. I suggested a hack, half tongue-in-cheekly half seriously, of putting a targeted 'display:none' in the CSS, but I realize this is not a very elegant or long term solution. A more constructive way would be to automatically transport the already existing description text to the templatedata description parameter and show the contents of that parameter at the usual location for descriptions on the page. Combining this with the old-fashioned way of editing template documentation is a challenge of course, I don't doubt that, but if the plan is to fase out the old way and make the new way the standard, that may become less important in time. Ivory (overleg) 29 aug 2014 18:13 (CEST)

I don't see why that's an issue, since that's not a rule, but simply something that the kind people who add TD to template just need to pay attention to. So the TemplateData needs a very short description, but it doesn't need it to be the same at the top of the page. I don't even think it's common to find such a description duplicated. In my experience, the top sentence on a Template page rather explains why/when that template needs to be used; the description in the TD section shortly explains what it is. There might be value in simply explaining to the reader what TD is (so that even if duplication happens, he/she understands why). The way en.wp does that, for example, is by having this line '"This is the TemplateData documentation for this template used by VisualEditor and other tools." before the TD table. Hope this helps. Elitre (WMF) (overleg) 1 sep 2014 13:55 (CEST) PS: also notice that the very template you used as an example shouldn't be used in VE, because VE is not available on talk namespaces.

The kind and friendly people who worry and complain are generally also quite attentive and articulate and, according to my standards, remarkably patient. The duplication is already the rule rather than the exception I'm afraid, see for more examples here, here, here, here, here, here, here, here, here, or here. I understand it comes naturally and I don't want to ridicule anyone's work but it looks very strange and I wouldn't be surprised if the waste of words has turned off a potential newcomer by now, either in despair or in scorn. The example of Sjabloon:Tekstkleur mentioned above shows the result of adding the suggested very short description: it is still (I am tempted to say: even more) repetitive, superfluous, annoying, confusing, now also lacking context, especially for the uninformed readers whom we are trying so hard to turn into enthusiastic contributors. Repeating the same thing there in summary, shorter or other form has a non-zero negative effect on the clarity of the content of the page, although it may have added value for the editor "and other tools".

Omitting the description parameter in the templatedata altogether is no solution either: in Sjabloon:Citeer boek the text "Geen beschrijving" ("No description") is also unnecessarily confusing. Adding an empty "description": "" parameter definition would improve the presentation already. Can we at least apply the "display:none" style to paragraphs classed "mw-templatedata-doc-muted"? Muting is not displaying, right? Why bother the reader with more colour coded placeholders, symbols, distraction? Is the user foremost in our minds, or the editor?

At page Sjabloon:Bron?, among others, the line "Deze gegevens worden gebruikt voor een betere weergave van het sjabloon in de visuele tekstverwerker" ("These data are used for a better presentation of the template in the visual text editor") replaces one source of confusion with another, just like it does on other wiki's. The template description is meant for describing the template, including all its technical details, not for apologies or explanations about other technicalities. We should strive to make things intuitive, make them speak for themselves, because every extra explanation is another possible stumbling block for those vulnerable and easily discouraged "new contributors". Weren't we all beginners once, not knowing where to begin and how to distinguish the important stuff from everything else? We should lower and remove thresholds wherever we can, but they get higher with every word.

PS According to #Unable to add my signature via VisualEditor "users are encouraged to sign their name, and all of these will (in time) be served" etcetera. But it is beside the point, I wasn't talking about a template being used in VE or VE being used on a talk page but about compromising the legibility of a template page. The examples I gave are all templatedata in the template namespace. Let's not confuse ourselves further. The "new contributors" who I am trying to help will only see a difference when we change, by developing smarter (local or global) policies and/or upgrading the VE implementation. I find it a minor issue because there are bigger issues to worry about and because templates are technical, nerdy and high threshold by nature, new contributors usually become old contributors in the main namespace, but by the time they become interested in editing a template they have read the template description and made an attempt at understanding what it is trying to say, which for many templates is in itself difficult and confusing enough. I'm sure the visual editor can be a great tool, but on some template pages more than on others, and the idea behind the description parameter (if it is only to say what it is rather than describe how it works) is apparently unclear and unenforceable, if it is to reach its first goal, put newcomers at ease. I hope, for the developers and users, one day it will even win over the hearts of some grumpy old wikipedians. With experience comes criticism, with criticism comes improvement. hth, Ivory (overleg) 2 sep 2014 20:03 (CEST)

Dutch summary: binnenkort wil ik hier voorstellen om bezoekers van sjabloonpagina's de alinea's onder het templatedatakopje met als inhoud alleen "Geen beschrijving" te besparen, hetgeen dankzij een techniek met een zogeheten class een fluitje van een cent is. Kan hier bezwaar tegen zijn? Ik denk niet dat dit veel pagina's betreft, het enige voorbeeld dat ik ken staat hierboven. Ik wil de editor alle ruimte gunnen, deze paragrafen zijn daarbij overbodig en verwarrend, vooral wanneer er wel een beschrijving boven staat. Ivory (overleg) 4 sep 2014 20:29 (CEST)

Huidige problemen

In de kroeg werd ik aangemoedigd de huidige problemen op te sommen. Ik zet hieronder een genummerde lijst, om de boel te kwantificeren en om in verder overleg hieronder naar de nummertjes te kunnen verwijzen. Misschien is het handig als jullie hier ook, met de gebruikelijke ~~~~, aan deze lijst de huidige problemen toevoegen. Door de ontwikkelaars opgeloste problemen kunnen we dan later doorhalen, zo hebben we een overzicht. –Frank Geerlings (overleg) 9 jul 2014 13:41 (CEST)

coor

Na bewerken van een pagina met een coordinaatsjabloon {{coor}} staat het coordinaat niet alleen rechtsboven waar het hoort, maar ook ergens rechtsboven dwars door de tekst heen in een ander lettertype. –Frank Geerlings (overleg) 9 jul 2014 13:41 (CEST)

1. Net getest. Bedoeld probleem zie ik niet. Heb je een link naar een wijziging waar het wel voorkomt? Ad Huikeshoven (overleg) 9 jul 2014 13:58 (CEST)

   Zie de afbeelding hier rechts. Je hoeft het betreffende artikel alleen maar te bewerken met de visuele editor, dan gebeurt dit al. –Frank Geerlings (overleg) 9 jul 2014 14:28 (CEST)

   

   Beeldafdruk van een fout in de visuele editor van mediawiki of een ander component van de nederlandstalige wikipedia, waardoor in de visuele editor, of bij het voltooien van het bewerken met de visuele editor, het coordinaat dat doorgaans met sjabloon Coor wordt aangebracht, tweemaal wordt getoond, waarvan eenmaal dwars door de tekst

   Zal wel browser afhankelijk zijn, want ik zie het niet in Safari iig. Die positie is trouwens de 'originele' positie waar in de nederlandse Wikipedia coordinaten staan. Als je Javascript uit zet verschijnen de coordinaten daar ook, normaal gesproken corrigeert een scriptje dat naar de locatie rechtsboven de streep. TheDJ (overleg) 9 jul 2014 15:14 (CEST)

   Ik keek met Chrome. Met zowel Windows 7 als Mac OS X (met een retina-scherm, als dat nog uitmaakt) gebeurt dit. –Frank Geerlings (overleg) 9 jul 2014 15:24 (CEST)

   Het viel me ook al op. Het ligt sterk aan het artikel of die tekst heeft die breed genoeg is en of er elementen voor die tekst staan. Romaine (overleg) 9 jul 2014 15:55 (CEST)

status: cosmetische bug, ziet er extreem knullig uit maar geen functionele belemmering

TemplateData

Zeer veel sjablonen missen nog TemplateData. Daardoor zijn er geen hulpteksten en zijn de argumenten niet bij naam benoemd. –Frank Geerlings (overleg) 9 jul 2014 13:41 (CEST)

Dat probleem wordt veroorzaakt doordat Visual Editor niet standaard aan staat. Daardoor is het probleem niet voor iedereen zichtbaar. Zodra het zichtbaar is, gaan er mensen aan werken. Het is aan de lokale groep bewerkers om bedoelde TemplateData toe te voegen. Ad Huikeshoven (overleg) 9 jul 2014 14:03 (CEST)

Ik denk dat we alvast wat voorwerk moeten doen door de meest gebruikte sjablonen alvast voor te bereiden. Aangezien het toch dezelfde mensen zijn die in de praktijk die TemplateData toevoegen, maakt het niet echt uit of dat voor of na invoering gebeurt, dus zeg ik voor. Er zijn nog genoeg andere problemen. –Frank Geerlings (overleg) 9 jul 2014 14:14 (CEST)

Voor wie de TemplateDataEditor wil gebruiker, zie en:User:NicoV/TemplateDataEditor voor documentatie en wat je aan je .js moet toevoegen om het 'aan' te zetten. Ad Huikeshoven (overleg) 10 jul 2014 21:22 (CEST)

status: Toevoegen van TemplateData is uitdaging, maar geen belemmering voor invoeren VisualEditor

Witruimte onderaan

Soms staat onderaan een artikel veel witruimte. Als je die weghaalt dan verwijder je ook de categorieën die daar stonden, want die zijn onzichtbaar. -Frank Geerlings (overleg) 9 jul 2014 13:41 (CEST)

Heb je een link of screenshot waaruit dit blijkt? Heel vervelend als dat zo is. Waarom zou je witruimte willen weghalen? Ad Huikeshoven (overleg) 9 jul 2014 14:09 (CEST)

Witruimte wil je weghalen omdat-ie er niet hoort, maar eigenlijk is het ook vaak het algemeen friemelen en schaven aan een tekst. Volgorde alinea's veranderen, dat soort dingen. Het soort ding dat je doet als je een artikel schrijft. Daarnaast: Pure bug, geen verstoppertje achter waarom noodzakelijk. De omschrijving is afdoende voor een ontwikkelaar om het probleem op te lossen zonder screenshot. –Frank Geerlings (overleg) 9 jul 2014 14:54 (CEST)

De visuele tekstverwerker toont het artikel niet zoals die in het echt getoond wordt, dit heeft als gevolg dat gebruikers dit gaan proberen te corrigeren, waardoor ze dingen verwijderen en kapot maken, vaak zonder dat ze het doorhebben en zonder dat ze snappen dat het probleem in de software ligt. De visuele tekstverwerker is juist ook bedoeld om het voor dummies mogelijk te maken om Wikipedia te bewerken, maar op dit punt is ze nog niet geschikt om door hen massaal te laten gebruiken. Romaine (overleg) 9 jul 2014 16:52 (CEST)

Elders zag ik links naar witruimte bovenaan pagina's. Kennelijk toont Visual Editor die in de edit modus omdat er broncode regels staan. Friemelen met witregels is kennelijk niet de bedoeling in Visual Editor. Ad Huikeshoven (overleg) 9 jul 2014 17:45 (CEST)

Het is waar dat in VE bewerkmodus het lijkt of onderaan extra witruimte ontstaat. Via paginainstellingen zijn de categorieën te bewerken. Het is niet mogelijk door weghalen witruimte onderin pagina de categorieën weg te halen zoals geclaimd in de eerste regel.Ad Huikeshoven (overleg) 20 jul 2014 17:18 (CEST)

Kan je verwijzen naar een voorbeeld waaruit blijkt dat dit niet meer kan? Beweren is bewijzen. Frank Geerlings (overleg) 20 jul 2014 20:29 (CEST) Ik heb een hele kleine steekproef genomen en ik kan het niet meer reproduceren. Mooi, lijkt gefixt te zijn! –Frank Geerlings (overleg) 20 jul 2014 20:50 (CEST)

status Het is niet mogelijk categorieën weg te halen door verwijderen witruimte onderaan de pagina in VE bewerkmodus. Categorieën zijn alleen te bewerken via menu paginainstellingen van VE.

Appendix sjabloon

Het sjabloon {{Appendix}} is niet onbruikbaar, maar het is nodig om alsnog wiki-syntax te gebruiken. Gezien hoe vaak dit sjabloon wordt gebruikt erg jammer. –Frank Geerlings (overleg) 9 jul 2014 13:41 (CEST)

1. Waar heb je specifiek wiki-syntax bij nodig bij gebruik van sjabloon Appendix? Ad Huikeshoven (overleg) 9 jul 2014 14:04 (CEST)

   Een heel simpel voorbeeld is de appendix van het artikel AMVER. –Frank Geerlings (overleg) 9 jul 2014 14:14 (CEST)

   Feature not a bug. Geval van sjabloon in een sjabloon kennelijk. Een manier van syntax gebruik die wel kon, maar wat met VE anders opgelost kan worden. Ik heb de appendix sjabloon aangeklikt in artikel AMVER in VE en zag in bewerkscherm inderdaad de wiki-syntax. Die is daarin te bewerken. Dat leidt niet tot fouten. Ad Huikeshoven (overleg) 9 jul 2014 17:45 (CEST)

   Het bestempelen van het niet kunnen omgaan met het meest gebruikte sjabloon dat rechtstreeks op artikelen wordt ingevoegd als een feature is verbazingwekkend. Tevens denk ik dat er een te beperkt beeld bestaat van de toepassing van dit sjabloon. Romaine (overleg) 9 jul 2014 21:29 (CEST)

Overlegpagina's

De visuele editor werkt niet op overlegpagina's –Frank Geerlings (overleg) 9 jul 2014 13:41 (CEST)

1. Dat klopt. De Visual Editor is slechts voor een beperkt aantal naamruimtes op nl.wp ingeschakeld. Het kan op meer naamruimtes worden ingeschakeld. Daar kan om gevraagd worden. Ik weet niet of dat een sysop of een dev dat moet doen. Als we willen dat het op overlegpagina's aangaat, dan gaat dat gebeuren. Overigens werken de ingenieurs van WMF aan "Flow", een nieuwe manier van ondersteunen van discussies op overlegpagina's. Ad Huikeshoven (overleg) 9 jul 2014 14:03 (CEST)

   Flow. Ook al zoiets waar niemand om gevraagd heeft. EvilFreD (overleg) 9 jul 2014 14:08 (CEST)

   Eens met Ad en Fred, just sayin' – hoeft wat mij betreft niet aan (Flow ook niet). –Frank Geerlings (overleg) 9 jul 2014 14:14 (CEST)

   "Als we willen dat het op overlegpagina's aangaat, dan gaat dat gebeuren." -> zo werkt dat dus niet. De visuele tekstverwerker wordt niet in de ovelregnaamruimte aangezet omdat die daar niet voor ontworpen is en ook niet voor bedoeld is! Romaine (overleg) 9 jul 2014 16:52 (CEST)

   En als we de VE niet aan willen hebben op de overlegpagina's, dan gaat die daar niet aan. Sterker nog, het niet aanstaan van VE aldaar is geen belemmering om VE op de hoofdnaamruimte aan te zetten. Ad Huikeshoven (overleg) 9 jul 2014 17:45 (CEST)

   Weer lees je niet wat ik schrijf. Wat heeft reageren dan nog voor zin? Romaine (overleg) 9 jul 2014 21:30 (CEST)

Andere naamruimtes

De visuele editor werkt geloof ik ook niet voor andere naamruimtes dan de hoofdnaamruimte? –Frank Geerlings (overleg) 9 jul 2014 13:41 (CEST)

1. Zie de reactie bij het vorige punt. Geen stopper voor invoeren Visual Editor op de hoofdnaamruimte. Ad Huikeshoven (overleg) 9 jul 2014 14:06 (CEST)

Witruimten bovenaan pagina in VE bewerk modus

probleem van een hele serie lelijke witrijen in een artikel die niet gecorrigeerd kunnen worden nog steeds aanwezig (lijkt erger geworden) – (zoals gemeld in WP:K door Romaine) –Frank Geerlings (overleg) 9 jul 2014 13:56 (CEST)

Heb je een link naar een voorbeeldwijziging waaruit dit blijkt? Ad Huikeshoven (overleg) 9 jul 2014 14:06 (CEST)

In de bewerkingssamenvatting zeg je "beweren is bewijzen", maar ik vind dat je zoiets niet kunt roepen als je je niet eerst echt verdiept in het onderwerp. Er was namelijk in de Kroeg allang gelinkt de pagina waar een serie voorbeelden staat. Enkele voorbeelden: bovenaan, bovenaan, bovenaan, bovenaan + kopje externe links, onder kopjes, bovenaan, enzovoorts. Dit lijkt misschien onschuldig, maar het roept in de praktijk gebruikers op ze weg te halen met schade aan de artikelen als gevolg. Romaine (overleg) 9 jul 2014 16:31 (CEST)

Dank voor het hier plaatsen van de links waarmee je voorbeelden geeft van wat jij lelijke witrijen noemt. Ik zie nergens een oproep aan gebruikers om die rijen weg te halen, en gebruikers zouden dat ook niet moeten doen. De witrijen zijn niet lelijk, dat is het probleem niet. In de lees-modus zie je die rijen niet, in de bewerk-modus van VE zie je ze wel. Dat vind je ongewenst of verwarrend. Daar zou een bugmelding voor gemaakt kunnen worden. Ad Huikeshoven (overleg) 9 jul 2014 17:45 (CEST)

Dit is, of is gerelateerd aan bug 49806, Ad Huikeshoven (overleg) 9 jul 2014 20:42 (CEST)

Je snapt duidelijk niet wat deze witregels voor effect hebben op gebruikers die nieuw zijn en serieus aan een tekst gaan werken. Je bagatelliseert de effecten en de problemen die er uit voort komen maar ik betwijfel of ik jou straks zie als de problemen op honderden pagina's hersteld moeten worden. Iedere serieuze redacteur die een hoop witregels bovenaan een artikel ziet staan en niet weet dat dat een keiharde bug is van de software, haalt die witregels weg, met alle gevolgen van dien. Romaine (overleg) 9 jul 2014 21:34 (CEST)

Die bug even bekeken, die heeft het over lege sjablonen. Ik heb een paar van de voorbeelden van Romaine bekeken, en het lijkt erop dat dat komt door afbeeldingen die daar ingevoegd worden maar door bijv een infobox naar beneden gedrukt worden. Het lijkt me dus subtiel anders, alhoewel de oorzaak vergelijkbaar kan zijn. Verder eens met Romaine, dit nodigt uit tot 'verbeteren' van de lege regels, met alle gevolgen van dien. Akoopal _overleg 9 jul 2014 21:37 (CEST)

Als je die lege regels verwijderd zie je stuk voor stuk de plaatjes, etc. verdwijnen. Als je dan op save drukt weet je dat je de pagina hebt gevandaliseerd. Daar is dan niets per ongeluk aan. Stratoprutser 10 juli

In het artikel Justine Henin staan (momenteel) drie lege regels bovenaan. Daar kan je schijnbaar ongestraft twee regels weghalen. Alleen de regel waarmee je de infobox weghaalt brengt een zichtbare verandering teweeg. De andere twee regels kunnen dus verwijderd worden zonder dat je dat merkt. –Frank Geerlings (overleg) 10 jul 2014 22:16 (CEST)

Die witregels ontstaan door het gebruik van het sjabloon {{largethumb}}. Haal ze maar eens weg en kijk naar de wijzigingen. Sjoerd de Bruin (overleg) 10 jul 2014 22:23 (CEST)

Dat snap ik Sjoerd, dat is nu juist het probleem. Als je een lege regel weghaalt hoef je natuurlijk niet naar de wijzigingen te kijken, dat spreekt voor zich. Dus dat doe je dan niet, en dat is het probleem. Je hoeft mij er dus niet op te wijzen, je moet iedere gebruiker er bij iedere wijziging op wijzen. Dat noem ik een showstopper. –Frank Geerlings (overleg) 10 jul 2014 22:26 (CEST)

Dit lijkt een specifiek gevolg van het sjabloon largethumb, zie hier: https://gerrit.wikimedia.org/r/#/c/110095/ Kan een bot dat sjabloon niet normaliseren? Stratoprutser, 11 juli.

Dat is absoluut ongewenst om dat aan te gaan passen. Het is een uitermate eenvoudig sjabloon en het is de software die daar niet mee overweg kan. Dan is het de software die daarop gecorrigeerd dient te worden. We gaan niet de wiki maar helemaal anders inrichten omdat bepaalde software bugs heeft. Romaine (overleg) 11 jul 2014 00:59 (CEST)

Wikipedia bestaat niet bij gratie van haar sjablonen, de sjablonen bestaan bij gratie van Wikipedia. Dit is een heel erg simpel en kennelijk heel erg uniek sjabloon, dat bij bepaalde functionaliteit problemen veroorzaakt. Dan zijn er twee oplossingen waarvan er eentje niet Romaines voorkeur heeft. Stratputser, 11 juli

Wikipedia bestaat niet per gratie van de visuele tekstverwerker, maar de visuele tekstverwerker bestaat bij de gratie van het goed kunnen interpreteren van de bestaande inhoud van artikelen. Problemen dienen opgelost te worden op de plaats waar ze veroorzaakt worden, dat is hier de software van de visuele tekstverwerker. Romaine (overleg) 11 jul 2014 01:08 (CEST)

Laat eerst de developpers maar eens achterhalen wat het probleem is. Als daaruit komt dat het sjabloon zelf iets aangepast moet worden kan ik daarmee waarschijnlijk leven, als de aanroep van het sjabloon met een bot aangepast zou moeten worden lijkt me dat een stuk minder acceptabel. Maar eerst moet de oorzaak beter bekent zijn, een aanpassingsverzoek kan eventueel van de developpers komen. Akoopal _overleg 11 jul 2014 09:51 (CEST)

De developers hebben bepaalde verborgen sjablonen zichtbaar gemaakt met 'slugs' wat Romaine lelijke witte rijen noemt. De genoemde voorbeelden heb ik toegevoegd aan bug 49806. James Forrester verwees me door naar bug 47790. Die was al gefixed en een half jaar geleden uitgerold. De oplossing was om de 'slug' zichtbaar te maken als je er me de muis overheen ging zodat het er anders uit ziet dan een lege regel. Ook daar nu de voorbeeld hier genoemd herhaald en aangegeven dat het niet om per ongeluk verwijderen van sjablonen/infoboxen (alleen) gaat maar ook om per ongeluk verwijderen van afbeeldingen. Laatst genoemde bug wijst overigens ook door naar bug 55336 over "FocusableNodes (e.g. Infoboxes) are too easy to accidentally delete, especially when floated". Die zou ook gefixed zijn om die onderdelen niet-verwijderbaar te maken. De gegeven voorbeeld laten zien dat het nog wel kan. Ad Huikeshoven (overleg) 11 jul 2014 23:44 (CEST)

Eenvoudige afbeeldingen

eenvoudige afbeeldingen worden niet goed weergegeven (was vorig jaar geen probleem) – (zoals gemeld in WP:K door Romaine) –Frank Geerlings (overleg) 9 jul 2014 13:56 (CEST)

1. Vorige week kwam ik daar nog voorbeelden van tegen, maar weet niet meer uit mijn hoofd waar. Romaine (overleg) 9 jul 2014 16:52 (CEST)

   Laat maar weten wanneer je daar weer een voorbeeld van ziet. Het komt kennelijk niet altijd overal voor. Ad Huikeshoven (overleg) 9 jul 2014 17:45 (CEST)

status: gesloten. Voel je vrij om het te heropenen met een link naar een pagina of afbeelding die niet goed weergegeven wordt.

Geavanceerde tabellen

volledige tabellen die helemaal overhoop liggen bij het bewerken van de tool (identiek aan vorig jaar) (echt een breaking point) – (zoals gemeld in WP:K door Romaine) –Frank Geerlings (overleg) 9 jul 2014 13:56 (CEST)

Heb je een link of screenshot waaruit dit blijkt? De testedit van Romaine is van een jaar geleden. Een edit van mij van vandaag toont dat probleem niet. Ad Huikeshoven (overleg) 9 jul 2014 14:09 (CEST)

Je doet de meest simpele bewerking in een uiterst simpele tabel, daar kun je echt niks uit opmaken. Je haalt er bovendien een bewerking bij die van een infobox is (iets heel anders). Mag het alsjeblieft wat zorgvuldiger? Romaine (overleg) 9 jul 2014 15:38 (CEST) -mwa, een infobox is een sjabloon om een tabel heen. Ad Huikeshoven (overleg) 9 jul 2014 17:45 (CEST)

Voorbeeld. Romaine (overleg) 9 jul 2014 17:04 (CEST)

Mooi voorbeeld. In de VE bewerkmodus krijg je de wiki-syntax te zien van een tabel cel in die complexe cel. Die tabel cel is dan als sjabloon te bewerken. Dat werkt. Het ziet er misschien raar uit. Feature not a bug. Misschien is de tabelopbouw onnodig complex en is dat het probleem, niet VE Ad Huikeshoven (overleg) 9 jul 2014 17:45 (CEST)

Je bagatelliseert hier opnieuw. Dat de visuele tekstverwerker met een heel eenvoudig sjabloon niet om kan gaan is een keiharde bug. Niks geen feature. In de normale editor wordt dit sjabloon prima getoond, het probleem ligt hier puur bij de visuele tekstverwerker. Romaine (overleg) 9 jul 2014 21:39 (CEST)

(na bwc)Als zoiets te complex is, is dat niet heel erg, maar mijn inziens zou VE het dan in ieder geval onmogelijk moeten maken de betreffende tabel te wijzigen totdat ze het wel aankunnen. Dit om problemen te voorkomen. Akoopal _overleg 9 jul 2014 21:40 (CEST)

Geen breaking point Ik zie het verschil niet? In de VE wordt code getoond, in de wikitexteditor wordt code getoond. Je zou wel gek zijn om in die code in de VE te gaan bewerken, dat is een ander verhaal, maar dat de VE daar gewoon code toont, en niet de html parsed, dat kan je de VE niet kwalijk nemen. Vraag een n00b gebruiker om een pagina met zo'n tabel te bewerken in de VE of in de wikitekst editor, en raad waar de voorkeur ligt? Als je van de 'rare' code afblijft, slaat de VE de tabel gewoon goed. Dus ik zie hier niet echt het probleem? Nu vallen we oningelogde gebruikers op https://nl.wikipedia.org/w/index.php?title=Justine_Henin&action=edit&section=23 lastig met

{| class="wikitable" style="line-height: 1.0" |-  ! Toernooi !! [[WTA-seizoen 1999|1999]] !! [[WTA-seizoen 2000|2000]] !! [[WTA-seizoen 2001|2001]] !! [[WTA-seizoen 2002|2002]] !! [[WTA-seizoen 2003|2003]] !! [[WTA-seizoen 2004|2004]] !! [[WTA-seizoen 2005|2005]] !! [[WTA-seizoen 2006|2006]]!! [[WTA-seizoen 2007|2007]] !! [[WTA-seizoen 2008|2008]] !! [[WTA-seizoen 2009|2009]] !! [[WTA-seizoen 2010|2010]] !! [[WTA-seizoen 2011|2011]] !! Carrière Winst-Verlies |- |colspan="20" align = "center" | '''[[Grandslamtoernooi]]en''' |- |style="background:#e5d1cb"| [[Australian Open (tennis)|Australian Open]] | {{Tabelcel tennis|–}} | {{Tabelcel tennis|2R|Australian Open 2000 (vrouwen)}} | {{Tabelcel tennis|4R|Australian Open 2001 (vrouwen)}} | {{Tabelcel tennis|KF|Australian Open 2002 (vrouwen)}} | {{Tabelcel tennis|HF|Australian Open 2003 (vrouwen)}} | {{Tabelcel tennis|W|Australian Open 2004 (vrouwen)}} | {{Tabelcel tennis|–}} | {{Tabelcel tennis|F|Australian Open 2006 (vrouwen)}} | {{Tabelcel tennis|–}} | {{Tabelcel tennis|KF|Australian Open 2008 (vrouwen)}} | {{Tabelcel tennis|–}} | {{Tabelcel tennis|F|Australian Open 2010 (vrouwen)}} | {{Tabelcel tennis|3R|Australian Open 2011 (vrouwen)}} |{{Tabelcel tennis|38-8}} |-

Dat gaan ze natuurlijk ook niet updaten.
Ah, in de VE kan je niet eens per ongeluk die code aanpassen/de tabel 'slopen', want-ie komt uit het sjabloon. Stratoprutser 10 juli

@Romaine ik schreef nu juist dat in VE de eenvoudige sjabloon in die tabel juist wel te bewerken is met VE. Daar maak jij van dat 'Dat de visuele tekstverwerker met een heel eenvoudig sjabloon niet om kan gaan is een keiharde bug.' terwijl ik met een link naar een wijziging met label VE juist aantoon dat dat sjabloon te bewerken is met VE. Sterker nog met VE is die tabelcel veel eenvoudiger te bewerken dan in de broncodemodus. Ad Huikeshoven (overleg) 10 jul 2014 21:57 (CEST)

Waar het om gaat is dat de tabel correct wordt weergegeven. Als de software niet kan omgaan met een tabel, moet ze deze blurren of zoiets net zoals met andere delen van artikelen wordt gedaan als ze die niet bewerken/verwerken kan. Het tonen van broncode van sjablonen is een duidelijke bug die nieuwe gebruikers oproept om die code te gaan verwijderen, en dat is niet de bedoeling. Met andere woorden, zoals Akoopal het al zei. Romaine (overleg) 11 jul 2014 01:04 (CEST)

Ik heb naar het artikel Justine Henin gekeken. Enkele tabellen daar werken prima maar niet allemaal: Als je naar beneden scrollt naar de "Prestatietabel enkelspel" en "Dubbelspel" dan tref je daar een paar totaal onwerkbare tabellen aan. Het is niet nodig dit onderwerp verder te bespreken. De tabel werkt nu NIET met VisualEditor. Je kan de tabel aanpassen zodat-ie met VE werkt, of je kan VE aanpassen zodat-ie met de tabel werkt. Maar hier welles-nietesen lost het niet op. Argumenten waarom dit nu al werkbaar zou zijn zijn niet nodig. –Frank Geerlings (overleg) 10 jul 2014 22:12 (CEST)

Hoi Frank - Ik gaf een link naar een wijziging in het artikel Justine Henin waarin een tabelcel in de "Prestatietabel" werd aangepast. De weergave in VE bewerkmodus laat inderdaad in de cel wiki-syntax zien, zoals eerder opgemerkt. De tabelcel is echter wel bewerkbaar. In de [https://en.wikipedia.org/wiki/Justine_Henin_career_statistics?veaction=edit engelstalige versie van hetzelfde onderwerp staat ook zo'n prestatietabel en daarin doet het probleem zich niet voor. De tabel werkt WEL met VE, vertoont alleen wikisyntax in bewerkmodus. Het probleem is aan te pakken door de tabel variant van bijvoorbeeld de engelstalige Wikipedia over te nemen. In VE mode doet daar het probleem zich niet voor. Ad Huikeshoven (overleg) 10 jul 2014 22:29 (CEST)

Bedankt voor de toelichting. De status is hiermee onveranderd. Kan een bot alle tabellen die niet werken fixen, of moet Visual Editor worden verbeterd? Misschien kan iemand met verstand van bots hier iets zinnigs zeggen... –Frank Geerlings (overleg) 10 jul 2014 22:35 (CEST)

Het is een duidelijke bug in de software die dan ook in de software zelf verbeterd dient te worden. Romaine (overleg) 11 jul 2014 01:05 (CEST)

VE bewerkmodus laat zien wat in sjabloon:Tabelcel tennis ook te zien is, namelijk "align="center" style="background:#F9F9F9;"|". Met dergelijke sjablonen kan VE niet werken. Zoals Brion Vibber in 2011 al gezegd heeft, VisualEditor zal het gebruik van bepaalde sjablonen breken. De tabellen in Justine Henin zijn aangepast, dwz sjabloon Tabelcel tennis is vervangen. Nu is de tabel in VE wel bewerkbaar. Dit is geen bug in VE, dit betreft ongewenst gebruik van sjablonen. Ad Huikeshoven (overleg) 11 jul 2014 10:27 (CEST)

Ongewenst gebruik van sjablonen? Doe eens normaal. Dit is al jaren staande praktijk, dat een nieuw stukje software er niet mee om kan gaan zegt meer over de software dan over ons. Sjoerd de Bruin (overleg) 11 jul 2014 10:44 (CEST)

status: Sommige algemeen gangbare tabellen die veel voorkomen zijn onbewerkbaar.

Het lijkt mij op zijn zachtst gezegd zeer onverstandig om artikelen aan te gaan passen om het voor VE bewerkbaar te maken, dat is de achterdeur uit. Dit soort constructies is gekozen om een reden, en daar zomaar vanaf te stappen omdat VE het niet ondersteund is gewoon niet de weg. Als VE simpel aangeeft 'sorry, niet bewerkbaar via VE, gebruik de standaard editor' is misschien een tussenvorm. Akoopal _overleg 11 jul 2014 23:27 (CEST)

ik ben het eens met Akoopal, laat mensen de tabellen en sjablonen gewoon op de gebruikelijke manier bewerken! Gebruiker:Schildpad2208 (overleg) Tank-fan 12 jul 2014 10:42 (CEST)

Het aangehaalde voorbeeld ligt nu niet overhoop in de bewerkmodus van Visual Editor, zie ook bugzilla:67850. De tabel die eerst overhoop lag kan nu wel bewerkt worden in VE en ook correct opgeslagen, zie ook bugzilla:67856 hetgeen een duplicaat is van bugzilla:51146. James Forrester, product manager VisualEditor is tijdens Wikimania volgende maand beschikbaar om met Wikipedianen uit Nederland hierover te overleggen en hij neemt daarvoor ook zijn Nederlands sprekende ontwikkelaars mee. Ad Huikeshoven (overleg) 20 jul 2014 17:10 (CEST)

Infoboxen

vreemde verspringingen, positiekaartprobleem lijkt opgelost, vreemde effecten op infoboxen (nog steeds een probleem) – (zoals gemeld in WP:K door Romaine) –Frank Geerlings (overleg) 9 jul 2014 13:56 (CEST)

Een voorbeeld. Romaine (overleg) 9 jul 2014 16:52 (CEST)

Het voorbeeld drie keer bekeken (Chrome), maar ik zie het vreemde effect niet. Kun je het effect concreet en specifiek beschrijven? Ad Huikeshoven (overleg) 9 jul 2014 21:07 (CEST)

De infobox wordt een stuk langer gemaakt met daarin een vreemd leeg kader en extra regels. Romaine (overleg) 9 jul 2014 21:41 (CEST)

Ja, nu zie ik ook dat in de VE bewerk modus de infobox onderin lege extra regels krijgt. Na opslaan zijn die lege extra regels weer weg. Dus dat klopt. De vraag is of en zo ja tot welke ongewenste bewerkingen dat zou kunnen leiden. Ad Huikeshoven (overleg) 9 jul 2014 23:59 (CEST)

Sjabloon wrapper

wrapper gaf problemen (lijkt opgelost, maar doet nog wel vreemd) – (zoals gemeld in WP:K door Romaine) –Frank Geerlings (overleg) 9 jul 2014 13:56 (CEST)

1. Voorbeeld van wrapper, er staan elementen in die niet kloppen en bij weghalen klopt het ook niet. Romaine (overleg) 9 jul 2014 16:52 (CEST)

2. vreemde uitwerking op tabellen (nog steeds aanwezig) – (zoals gemeld in WP:K door Romaine) –Frank Geerlings (overleg) 9 jul 2014 13:56 (CEST)
   

   Heb je een link of screenshot waaruit dit blijkt? Ad Huikeshoven (overleg) 9 jul 2014 14:09 (CEST)

Appendix

niet om kunnen gaan met Appendix (een van de meest gebruikte sjablonen, nog steeds een probleem). – (zoals gemeld in WP:K door Romaine) –Frank Geerlings (overleg) 9 jul 2014 13:56 (CEST) (duplicaat van #4)

Links

Toevoegen van links naar niet bestaande artikelen kleurt ze blauw, niet rood. –Frank Geerlings (overleg) 9 jul 2014 14:05 (CEST)

1. Heb je een link of screenshot waaruit dit blijkt? Ad Huikeshoven (overleg) 9 jul 2014 14:09 (CEST)

   Ik probeer het nu en het gedrag is beter dan voor de laatste update lijkt het. Het is nu moeilijker, maar het lukte me nog wel. Ik begrijp alleen niet hoe, want ik kan het niet reproduceren. U hoort nog van ons. :) –Frank Geerlings (overleg) 9 jul 2014 15:04 (CEST)

   Dit is onderdeel van bugzilla:37902. TheDJ (overleg) 9 jul 2014 15:36 (CEST)

Bij mij kleurt een niet bestaande artikel link direct rood. Stratoprutser, 16 juli

Verborgen sjablonen

Sjablonen zoals {{Link FA}} die geen (in het artikel) zichtbare output hebben verwijder je makkelijk, net zo makkelijk als categorieen, die feitelijk ook geen zichtbare output in het artikel hebben. Hier zie je hoe ik dat weer rechtzet, verwijdering gebeurde ongemerkt in de edit ervoor: deze bewerking fixt het weer – je moet HEEL goed opletten wil je dit opmerken. –Frank Geerlings (overleg) 9 jul 2014 14:58 (CEST)

Een van de grootste gevaren met de visuele tekstverwerker is dat er dingen op een artikel verwijderd worden zonder dat men dat doorheeft. Je geeft een heel goed voorbeeld wat bij invoering voor iedereen heel vaak verkeerd zal gaan. Dat lijkt me erg schadelijk. Romaine (overleg) 9 jul 2014 15:58 (CEST)

Voor verborgen sjablonen zie bugzilla:49806 over hidden templates. Je kan de witruimte aan het einde verwijderen maar je hoeft het niet te doen. Overigens de interwikilinks staan al op Wikidata. De aanduiding dat een taalversie "featured article" status heeft zou ook op Wikidata uiteindelijk terecht moeten komen. Dat lost dit probleem op. Merk overigens op dat het niet lukt om met verwijderen witruimte aan het einde van het artikel de categorieën te kunnen verwijderen (daar is de 'page settings' dialoog voor). Ad Huikeshoven (overleg) 20 jul 2014 16:58 (CEST)

status voor {{Link FA}}: de data betreffende de status van artikelen zoals 'featured', 'etalage', 'good' en dergelijke zijn inmiddels verhuisd naar wikidat.org. Het is niet meer mogelijk ze hier met VE per ongeluk te verwijderen.

Sorry, maar dit is iets te vroeg geconcludeerd. De sjablonen staan allemaal nog gewoon lokaal en worden in de komende maand waarschijnlijk verplaatst. Romaine (overleg) 30 aug 2014 09:12 (CEST)

Spellingscorrectie

Als ik met Firefox in de tekst op een verkeerd gespeld woord rechts klik en dat conform de suggestie van de browser verbeteren door te klikken, dan krijg ik het vaak voor dat als er één letter wordt toegevoegd deze letter ook nog eens helemaal bovenaan het artikel wordt toegevoegd. --MichielDMN 🐘 (overleg) 12 jul 2014 19:11 (CEST)

Kan je aangeven welk woord in welk lemma? Bij mij werkt de spellingscontrole in FF in Win 7 zoals te verwachten? - Stratoprutser, 16 juli

Ik heb het al in meerdere artikels gehad. Ik zocht nu net even op artikels met zo'n spelfout, maar nu kreeg ik het niet ... Als ik het tegenkom, signaleer ik het nog wel eens. MichielDMN 🐘 (overleg) 26 jul 2014 17:22 (CEST)

Het probleem is Bugzilla:63395. Whatamidoing (WMF) (overleg) 28 jul 2014 19:54 (CEST)

Cool thanks for keeping an eye out! Stratoprutser, 29-7-2014

Opslaan

Bij het opslaan en het niet-ingeven van een samenvatting, hoor je normaal twee keer te bevestigen. Ik krijg vaak niet de tweede bevestiging, maar de eerste blijft maar staan en lijkt de tweede eeuwig te laden. --MichielDMN 🐘 (overleg) 12 jul 2014 19:11 (CEST)

Hoe bedoel je dat je normaal 2x hoort te bevestigen? Wordt de wijziging uiteindelijk opgeslagen? Stratoprutser, 16 juli

Ik denk dat Michiel de optie "Een melding geven bij een lege bewerkingssamenvatting" heeft aanstaan, en dat deze niet werkt in de VE. Sjoerd de Bruin (overleg) 16 jul 2014 19:30 (CEST)

Categorieën

Eerder een suggestie dan een probleem, maar het stoort me wat dat de categorieën van het artikel nergens meer te zien zijn binnen de visuele verwerker. Ze kunnen aanpassen/uitbreiden zou natuurlijk nog beter zijn. --MichielDMN 🐘 (overleg) 12 jul 2014 19:11 (CEST)

Ze zijn zichtbaar, aanpasbaar en uitbreidbaar, zie Wikipedia:Visuele tekstverwerker/Gebruikershandleiding#Categorieën bewerken - Stratoprutser, 16 juli

Ah zo, fijn om te weten :-). Had ik nog niet opgemerkt. Dankjewel! --MichielDMN 🐘 (overleg) 26 jul 2014 17:24 (CEST)

Afzender

VE kan niet goed overweg met het afzender sjabloon. Gebruikelijke format is {{afz|Mbch331}}, echter VE maakt er van {{afz|Mbch331 = }}, waardoor je de afzender niet te zien krijgt. Zie hier voor een voorbeeld. Mbch331 (Overleg) 13 jul 2014 11:37 (CEST)

Dat sjabloon heeft nog geen template data, hoe kreeg je het uberhaupt ingevoegd? Ik heb het net getest, en door aan variabele 1 een ip adres toe te voegen ging het zonder problemen in (Firefox). Stratoprutser, 15 juli 2014

Templatedata is niet nodig om een sjabloon met VE in te kunnen voegen. Is alleen nodig om aan een gebruiker uit te leggen waar ieder veld voor staat. Als je een ip-adres toevoegt aan variabele 1, dan krijgt je {{afz|1=0.0.0.0}}, wat nog steeds niet hetzelfde is. Mbch331 (Overleg) 16 jul 2014 09:02 (CEST)

– De voorgaande bijdrage werd geplaatst door 0.0.0.0 (overleg · bijdragen) - niet hetzelfde als wat? Stratoprutser, 16 juli

De visuele tekstverwerker is bedoeld voor in artikelen. Dit sjabloon is bedoeld voor op overlegpagina's. Er is geen reden waarom de visuele tekstverwerker met dit sjabloon overweg zou moeten kunnen. Romaine (overleg) 16 jul 2014 09:21 (CEST)

Bv Help:Helpdesk. Stratoprutser, 16 juli

Dan nog is de visuele tekstverwerker daar niet voor bedoeld. Romaine (overleg) 16 jul 2014 09:40 (CEST)

Hoi Mbch331. Aan sjabloon afzender zijn de TemplateData toegevoegd. Mij lukt het nu uitstekend om het sjabloon te gebruiken. Het sjabloon werkt in alle naamruimten waar ik het heb uitgeprobeerd. Tegen de tijd dat Flow op deze wiki wordt aangezet is dat sjabloon grotendeels overbodig. Flow is bedoeld voor overlegpagina's en met Flow hoef je je opmerkingen niet te ondertekenen, dat doet Flow automatisch. Voor deze pagina is er wel behoefte aan toepassing van het sjabloon afzender, maar in deze naamruimte staat VE niet aan. Via Echo notificatie heb je waarschijnlijk al gezien op welke pagina ik met VE het invoegen van het sjabloon getest heb. Ad Huikeshoven (overleg) 20 jul 2014 16:49 (CEST)

status Opgelost

Hotcat

Zodra VE geactiveerd wordt, werkt de extensie Hotcat niet meer. Zonder VE ingeschakeld werkt Hotcat wel. Hotcat is juist erg makkelijk om snel categorieën aan te passen in een artikel. Als je alleen VE gebruikt heb je Hotcat niet nodig, maar als je zoals ik soms VE en soms geen VE gebruikt om te bewerken, dan kan je Hotcat niet gebruiken. Mbch331 (Overleg) 4 sep 2014 23:47 (CEST)

Hi, you might want to notify the HotCat creator, he might be able to fix the issue. Thanks, Elitre (WMF) (overleg) 8 sep 2014 17:08 (CEST)

Wat bedoel je met niet werken? Het lijkt bij mij gewoon te werken. Uiteraard niet in edit-modus, maar in gewoon lees-modus zie ik gewoon de knoppen van hotcat. Akoopal _overleg 8 sep 2014 20:16 (CEST)

Internet Explorer 11

Hi, sorry this message is not in Dutch. I'm writing to let you know, in case you have missed this announcement in the Tech News during the last weeks, that IE 11 users will soon be able to use VisualEditor as well. I don't anticipate any visible consequences since this browser version is not so popular among the global Wikipedia users (should be ~5%); you might just notice edits revealing the editors' inexperience with VE or with editing in general. Please let us know of any unknown bugs or sudden issues, of course. Thanks a lot, Elitre (WMF) (overleg) 10 sep 2014 18:05 (CEST)