Wikipedia:Visuele tekstverwerker/Feedback/Archief/jul 2013

Feedback van Romaine

• Als ik op bewerken klik in de visuele tekstverwerker creëert de software een witregel waar de cursor komt te staan, terwijl daar juist de introzin zou moeten verschijnen.
• Bij het bewerken van artikelen met de biologische taxobox toont deze infobox vreemd: [1] versus normaal Haetera macleannania. Het Commons-icoontje wordt niet getoond, net als het portaal-icoontje en er komt een vreemde witte lijn onder de portaallinks.
• Bij het bewerken van artikelen met een plaatsinfobox toont de infobox vreemd: [2] versus normaal Levanto (Italië). Vlaggetje in kopbalk wordt niet getoond, kaart wordt wit kader, portaal-icoontje is foetsie, maar bovenal worden verschillende cellen naar rechts verschoven. Ook snap ik niet waarom het coördinatensjabloon zowel bovenin als rechtsonder getoond wordt.
• De software lijkt niet om te kunnen gaan met meerdere onder elkaar geplaatste bestanden? Zie: [3] versus Rijn. Tevens is hier het Commons-sjabloon onzichtbaar en staat er in plaats van een witte balk.
• Op [4] doet de visuele tekstverwerker het vreemd met een afbeelding (Aristoteles).

Romaine (overleg) 22 jun 2013 22:56 (CEST)

• The template editor seems to me more difficult in use than just editing the infobox on articles itself. Adding some crap of coding purely based on en-wiki to make the VE work is not reasonable to ask, sorry. Maintaining templates must be easy and remain easy, and not because of VE been made a lot more complex.
• The VE can't cope with the Appendix template (for sources), our number one template on articles to edit which is in practice the most easiest template. The VE fails to keep editing that template easy.
• The VE doesn't understand the Wrapper template like on Sagrada Família, it shows the | and |- which people probably will remove as they don't understand them what will cause that unexperienced users will rmeove them what will give a lot of layout problems.
• On all articles mentioned in my previous post are still problems, almost the same...

Is the feedback given really been used? It doesn't give that impression. Certainly not with so short timeframe of getting the VE live. Romaine (overleg) 10 jul 2013 01:33 (CEST)

• I predict problems with Largethumb as seeing the way how images are processed.
• We have been working hard on removing all the px insertions in favour of thumbnail sizes, the VE recommends users to resize images, which isn't handy. The MediaWiki software recommends not using image sizes hardcoded in the articles.

Romaine (overleg) 10 jul 2013 02:47 (CEST)

• Edit with adding a parameter, this really should not happen. Romaine (overleg) 11 jul 2013 03:34 (CEST)

Onvertaald: "Edit source"

Als je de muis op het knopje "Bewerken" houdt om slechts een paginagedeelte te bewerken, dan verschijnt een knopje "Edit source". Dat zou vast nog vertaald moeten worden, maar ik weet niet om welk bericht het hier gaat. Mathonius 27 jun 2013 16:20 (CEST)

That should be translated now and appear properly when the beta release is put here. Keegan (WMF) (overleg) 6 jul 2013 21:58 (CEST)

Toon bewerking ter controle

Nadat ik op "Pagina opslaan" heb geklikt en vervolgens op "Wijzigingen controleren", kom ik wel eenvoudig terug naar het venster waarmee je de bewerking kan opslaan, maar niet meer naar het bewerkvenster zelf zonder dat je bewerkingen verloren gaan. Dat vind ik jammer. Ik zou liever een makkelijk te vinden optie willen om vanuit het 'opslamenu' terug te gaan naar het bewerkvenster, net zoals je normaal/vroeger op "Toon bewerking ter controle kon klikken" en dan gewoon verder kon gaan met bewerken. Mathonius 27 jun 2013 19:24 (CEST)

Maar misschien ben ik nog niet gewend aan WYSIWYG o.i.d. Mathonius 27 jun 2013 19:30 (CEST)

Ik zie nu dat in rechterbovenhoek van het opslamenu een knopje zit waarmee je terug kan naar het bewerkvenster. Handig, maar echt duidelijk is het niet. Mathonius 29 jun 2013 08:17 (CEST)

How can we make this more clear? Keegan (WMF) (overleg) 6 jul 2013 21:56 (CEST)

Nieuwe interne link toevoegen

Ik vind het moeilijk om een nieuwe interne link toe te voegen als de weer te geven tekst verschilt van de eigenlijke linktekst. Ik wil bijvoorbeeld een link toevoegen naar de pagina Work It (televisieserie), maar deze moet in het artikel natuurlijk worden weergegeven als Work It (zie hier). Ik krijg dit (nog) niet voor elkaar met de visuele tekstverwerker. Mathonius 27 jun 2013 19:28 (CEST)

Wat ook lastig is, is het wijzigen van de eerste letter van een interne link. Als er bijvoorbeeld edinburgh staat en ik wil er Edinburgh van maken, dan komt er al snel Edinburgh te staan. mvg, Michielderoo (overleg) 3 jul 2013 09:02 (CEST)

@Mathonius, you no longer have to use the link and | to change how the name appears. Using your example, you would write "Work It", highlight that, click the link icon, and type in Work It (televisieserie) and VisualEditor should find the article. Select that, and it will automatically create [[Work It (televisieserie)|Work It]] in the source text.

@Michielderoo, you just need to highlight the text click link and it should relink the article properly. Keegan (WMF) (overleg) 6 jul 2013 21:55 (CEST)

Thanks for the reply. The solution will work, but it's not very intuitive, especially for new users. I understand there are several concerns here and it might be hard to find a solution that fits every situation. The problem is also entered on bugzilla now. Michielderoo (overleg) 7 jul 2013 07:48 (CEST)

Excellent, I see the bug is now marked high priority. Keegan (WMF) (overleg) 8 jul 2013 22:29 (CEST)

Feedback van Josq

Heb hier mijn eerste feedback gegeven. Belangrijkste punt: aanpassing van de snelcursus moet klaar zijn bij invoering. Josq (overleg) 5 jul 2013 20:26 (CEST)

Thank you for your feedback, I read over it there. The snelcursus is being translated and will be put here on the Dutch Wikipedia. Keegan (WMF) (overleg) 6 jul 2013 21:59 (CEST)

Te kleine weergave

Wanneer ik een artikel bewerkt heb en op "Pagina opslaan" klik, opent het pop-up scherm bij mij veel te klein. De tekst die erin staat is haast onleesbaar. Dinosaur918 (overleg) 7 jul 2013 14:17 (CEST)

red links are not red

The red links (to non-existing articles) become blue in edit mode. This is weird because currently also our readers are shown red links, making them blue therefore doesn't seem logical. Because it is hard to see the link under water (before the |) you don't recognize wrong links.Bas (o) 7 jul 2013 17:52 (CEST)

Very good catch, Bas. I recreated the bug in my enwiki sandbox and got the same results. I filed a bug. Keegan (WMF) (overleg) 8 jul 2013 22:17 (CEST)

Cellen toevoegen aan een tabel

Ik heb zojuist een tabel bewerkt met de visuele editor, en dat werkt (ook voor ervaren Wikipedianen) beter dan via de broncode, zolang je geen ingewikkelde dingen wilt gaan doen (waarbij een link toevoegen al ingewikkeld is). Nou had ik echter het probleem dat ik af en toe een keer teveel op delete of backspace drukte waardoor een cel verdween, ik kon niet ontdekken hoe ik deze cellen weer terug kon krijgen (ctrl-z was de oplossing, maar dat werkt niet als je gewoon een nieuwe rij of kolom toe wilt voegen). Dus mijn vraag is hoe kunnen eenvoudig cellen in een tabel toegevoegd worden. Iets anders waren vlaggetjessjablonen, deze via de tranclusiefunctie toevoegen is erg ingewikkeld, zou het een mogelijkheid zijn om ook een bewerk bron van cel optie toe te voegen? Of is dat iets wat te specialistisch en onwenselijk is (dan moet je maar gewoon de broncode induiken). Mvg, Bas (o) 7 jul 2013 17:59 (CEST)

This is a complicated bug that needs fixed in Parsoid (the translator between wikimarkup and HTML). The developers are working on it, you can find a couple of "hacks" in the comments on the bug, but for now I suggest just using the Edit source option to work on cells in templates. Keegan (WMF) (overleg) 8 jul 2013 22:23 (CEST)

Categories

Currently it is not (yet?) possible to edit categories using the visual editor (or am I missing it?). For editing categories there is allready the very useful hotcat-gadget. To me this gadget seems to be close to WYSIWYG-editing. Would it be an idea to use something similar to hotcat to make it possible to edit categories with the visual editor? Bas (o) 9 jul 2013 13:34 (CEST)

Only now I find that this is in a different function called "Pagina-instellingen". This seems rather unlogical (it only contains categories but has a non clear name), isn't it possible to simply make a small part at the bottom to edit categories? Bas (o) 9 jul 2013 15:12 (CEST)

I certainly would have expected a section at the bottom to add/change the categories, or at least show them there. Romaine (overleg) 10 jul 2013 01:35 (CEST)

Adding first reference

When a user adds a reference, and there are no references yet, the {{reference}} or similar tag isn't added to the bottom therefore giving this error: "Citefout: Er bestaat een tag <ref> voor de groep "bron1", maar er is geen bijbehorende tag <references group="bron1"/> aangetroffen". On the dutch wiki a lot of articles don't have any references at all, therefore a lot of times when a new user will add a reference this massive error will appear leaving the user further from home than on the moment he didn't have a reference. Also the use of the group for references is unclear to me, I've never seen this used before, but it's very prominent in the reference-interface. Other usefull functions are unclear or missing, making this interface very difficult, even for me as an experienced user. It asks: "what do you want to source". I thought I had to add for example the name of the website I was sourcing eg. "Wikipedia". But instead i've to add [http://nl.wikipedia.org/wiki/Hommels Hommels op Wikipedia] here using links and difficult markup again. In the current form I believe that the reference-helper is making stuff even more complicated by having unnecessary function and the lack of the most vital functions. See this page for my initial test. Wouldn't it be much more intuitive to add different options to the function for example in the first menu u ask: Do you want to cite a book, website, newspaper, scientific paper. After selecting an option you end up in a menu which asks the relevant stuff for each type of source. For a website there is a field for the link and one for the description. For a book the fields from Sjabloon:Citeer_boek can be asked etc. This seems like a more easy way to add this kind of information, making the difficulty of sourcing easier for new users (they don't need to know any wiki-code anymore). Mvg, Bas (o) 9 jul 2013 14:45 (CEST)

Oh, I found out that there is another button: lijst met referenties. I thought this was to watch the list while editing, but it appears this is to add the list. Also in this function the use of "reference groups" is very prominent, but I do not see why grouping the references would be useful most of the time (it's seems something rathers specialistic to me). Bas (o) 9 jul 2013 15:09 (CEST)

Every day I check all articles where the references is missing and add it to the page on the right place. If people make mistakes in the code, the article also shows in red that the template is missing and that I'll fix the same time. Romaine (overleg) 10 jul 2013 01:35 (CEST)

Yes but we should not only rely on your good work. And the issues with the interface being unclear for new users about what to fill in isn't something which always can be fixed (if they simply leave out source information). Mvg, Bas (o) 10 jul 2013 12:01 (CEST)

Infoboxen en parameters

I got some problems while trying to add/edit an infobox.

First of all, when I was trying to add a complete new infobox, I added the blank template and tried to add the first parameters. This is the first thing I would like to see changed: a list which shows all available parameters in a template/infobox, and if you'd click on one it would automatically add itself and you can edit the content of the parameter. Anyways, the way it works now doesn't (yet) work. I wanted to add the first parameter "ontwikkelaar" to a new article using the infobox computerspel. However in the list, in which while adding internal links it shows different possibilities, nothing appeared while typing and when it said "ontwikkelaar" in my screen the visual editor showed me the message "Unknown parameter". It should be known, as it is available in the template. When I clicked Add Parameter it added it and when checking the page the parameter appeared (with it's corresponding text obviously). Very confusing and annoying that the editor tells me that there's an unknown parameter while it's available.

I think both of my points (list of available parameters and the errors) are important matters. If the list of available parameters is added there's less chance that parameters will be forgotten to be added and for new users (which this new interface is mainly concerned about) it will be a lot more intuitive, clear and easy-to-use.

With kind regards, Kippenvlees (overleg‽) 10 jul 2013 15:14 (CEST)

We have functionality that will be going out soon to add parameters that are configured as required automatically when you create a new template using VisualEditor. This functionality depends on the template being described using TemplateData. Which brings me to my next point. If a template is not described using template data, none of it's parameters are "known". You can still add them if you know their names, but they won't show up in the list. We hope that all templates can be supplemented with template data in the near future, as it will improve the user experience of VisualEditor. Trevor Parscal (overleg) 11 jul 2013 02:42 (CEST)

Sorry, putting a lot of code crap on too many templates is not a realistic option. Our templates are in order and adding your suggestion makes template much much more difficult to update. No thanks. We like to keep our templates easy so that most users can change and update them and that it isn't depending on users who are good in coding. Romaine (overleg) 11 jul 2013 03:13 (CEST)

Hmm, I'm not 100% sold on the idea that defining parameters for a template is "code crap." Defining parameters seems to me to be essential for allowing others who were not involved in writing the template to port it and use it as they need, whether it is for VisualEditor or writing with wikitext in the source. For the example given above by Kippenvlees1 even without VisualEditor you are seeing parameters when viewing the source. Templates already have inherent parameters when they are written. But it seems that TemplateData is at an impasse if Romaine is speaking for the Dutch community here in refusing to add this code to the templates. So my question for the Dutch community would be then be how do you find success in utilizing VisualEditor to work with templates if you are unwilling to codify what fields a template should contain? Just trust users to figure it out and/or know already? That seems rather uninviting and is obviously not what VisualEditor's purpose is. What else, in your collective experience, could work instead? I would love to hear the input of other community members about this. Keegan (WMF) (overleg) 12 jul 2013 20:02 (CEST)

Note: Mathonius offered to translate for me as needed, and I left a request for this to be translated into Dutch. Keegan (WMF) (overleg) 12 jul 2013 21:03 (CEST)

Een vertaling van bovenstaand bericht (eigen toevoeging tussen blokhaken):

Hmm, ik ben er niet geheel van overtuigd dat het definiëren van parameters voor een sjabloon "code crap" [d.i. gerommel met codes] is. Het definiëren van parameters is volgens mij essentieel om anderen, die niet bij het schrijven ervan betrokken waren, het sjabloon te laten porten en naar eigen wens te gebruiken, of dat nu voor VisualEditor is of voor het in de bron schrijven met wikitekst. Wat het voorbeeld van Kippenvlees1 hierboven betreft, zelfs zonder VisualEditor zijn parameters te zien als de bron wordt bekeken. Sjablonen hebben al inherente parameters als ze geschreven worden. Maar het lijkt erop dat TemplateData zich in een impasse bevindt als Romaine namens de Nederlandstalige gemeenschap spreekt door te weigeren deze code aan de sjablonen toe te voegen. Mijn vraag aan de Nederlandstalige gemeenschap zou dan dus zijn: hoe lukt het je om VisualEditor voor sjablonen te gebruiken als je geen code wilt gebruiken voor de onderdelen die een sjabloon moet bevatten? Gewoon vertrouwen op gebruikers om het uit te vogelen en/of het al te weten? Dat lijkt niet uitnodigend en is duidelijk niet wat met VisualEditor wordt beoogd. Wat zou, volgens jullie collectieve ervaring, in plaats daarvan kunnen werken? Ik zou graag ook de input hierover van andere leden van de gemeenschap willen horen.

Met vriendelijke groet, Mathonius 12 jul 2013 23:45 (CEST)

"Crap" is the first word that comes in mind if an not code-educated user sees all the code what is needed for the TemplateData, that is not normal. On nl-wiki we have as goal to make most templates easy editable by regular users, whithout having to know too much codes. The Visual Editor should making editing easier, not much much more complicated in templates. Than it misses its goal. "That seems rather uninviting" -> putting all that code in all these templates, that is very much uninviting. Perhaps it is common on en-wiki to make templates which are only editable by much experienced users, on nl-wiki that is not. The community on nl-wiki maintains the contents of infoboxes and other templates, this is already not the easiest for many users but we try to keep it easy. "and is obviously not what VisualEditor's purpose is." -> this is called failure. It is not reasonable at all to put all that coding in templates to make editing so called easier, while it actually makes editing much more difficult. For many years we have been working on putting a standardized empty example infobox on the infobox pages between <pre> and </pre> which users easy copy and paste into articles. The names of the parameters or in almost all templates understandable to fill in easy. The Visual Editor makes changing templates both in articles and in templates more difficult, something which is not thought trough enough. The software developers should provides us tools to make editing easier, not harder, but harder seems now the current situation. I also really think that other language communities do not realize what kind of coding hell the VE will introduce to their templates, I hope many others will realize this in time and protest as well, before they do not have any choice any more and are forced to deal with it against their will. Templates should be easy editable for most users, not for coding experts only. Romaine (overleg) 13 jul 2013 03:45 (CEST)

PS: Speaking for the community is not true. In practice I am one of the few users, if not onliest, who does structural maintenance in the template namespace to keep that namespace in order. We have made templates as easy as possible to enable as much as users as possible to update them easily, that is what we like to keep. Putting a large bunch of coding in the templates will double or triple the workload of fixing mistakes and errors as most users can't work with this coding and back off/give up this editing while we hughly depend on those edits. I early noticed this big disadvantage of the current version of VE, I really hope you start working on improving this big disadvantage, it is too much seen from the view of coding experts without realizing what impact this will have on regular users which would like to update templates properly themselves, this instead of the impression that the developing team is giving the past days: deal with it. Romaine (overleg) 13 jul 2013 04:07 (CEST)

I appreciate your thoughts on the matter, Romaine, which is why I sought them out to begin with. I value your opinions and knowledge of this Wikipedia, its policies and practices, and its history. Development of VisualEditor is not English Wikipedia specific (in fact, a couple of the lead developers of VisualEditor are Dutch themselves), it is for ~280 different language Wikipedias and development for template systems for all of these to match 100% is not something that is happening immediately. That being said, it is why we are seeking out feedback to work with communities to make the software as useful as possible for you here. That my goal, my passion, my priority, and lastly my job. Other communities, including English, French, German, Italian, Finnish, and on and on...are also working with using VisualEditor in the template system, a system which Ward Cunningham once expressed to me face-to-face that he feared would divide participation between wikis. This is not easy, any solution will not be easy to find, it will take work and it will take everyone collaborating together to work out. This is why I invite the rest of the Dutch community to participate here; it is clear the two of us can not do it alone nor should we. Again, Romaine, I will continue to ask for and respect your opinions on the matter. Keegan (WMF) (overleg) 13 jul 2013 05:05 (CEST)

Perhaps it is good to point out the special position of Romaine as regards templates, categories, etc. He has established dominance over these and reshaped these according to his preferences ("brought them into order"). What exactly his objectives are in doing so is unclear (it appear to be mostly what he thinks looks pretty), but it is clear that he will not hesitate to shut down whole areas in Wikipedia main space if these are not 'Romaine-compliant' ("I have a bot and I am using it to enforce my way"). This is not to say he does not have a considerable amount of support in 'the community', and of course he does put in a lot of hours. - Brya (overleg) 24 jul 2013 18:26 (CEST)

@Keelan/others: Brya is a (half)troll, just ignore. Romaine (overleg) 25 jul 2013 09:27 (CEST)

QED. This is as good a demonstration as anyone could ask for of Romaine's attitude towards those who are not into the "Romaine-standards". - Brya (overleg) 25 jul 2013 18:31 (CEST)

There are no "Romaine-standards", there is only a Brya which has as personal job to attack another users because Brya doesn't want to follow the conventions which are set up by the users of this project. Romaine (overleg) 25 jul 2013 23:53 (CEST)

Knowing Romaine, I am sure that if others voice their opinion here, and it goes the other way, he will accept.

Having said that, my own opinion. I see the complete template system as split. Part of the templates are just content inserted on multiple place, think of navigation templates and sidepanel templates (zijbalk in dutch). Other templates are more code to do either calculation or layout. Think of the 'coordinaten' templates. For the first templates the new editor only needs to offer to edit the complete template, for the second one it is more important to edit the parameters with clear help what to fill in. For that, I can't see another way as to describe them. This would include infoboxes.

Regarding the editors of the templates itself, for the first it will be the general editor, perhaps a bit more experienced. The second one however, I mainly see that they are edited by more experienced wikipedians, and not the general editor will edit it. So there I don't mind it being a little bit more complex, although all the the work done with the general infobox in NL has helped making it more open. The infobox is a bit more special as people are a bit more tempted to make a new one then for other templates. But with clear help-text I personally think the overhead of having to describe the parameters is acceptable. If the scheme can be adopted a little that docs for the template can be generated from it as well, it will avoid double work a bit more. Akoopal _overleg 24 jul 2013 21:18 (CEST)

Ik ga even in het Nederlands verder, omdat dit een beslissing is die we als wiki lokaal zullen willen nemen (en geen commentaar richting externen), Nederlands is dan toegankelijker. Bij Navigatie-templates zijn er toch ook gewoon geen parameters Akoopal? Dus hoeven er ook geen parameters gedefinieerd te worden. Dan mijn mening: het lijkt mij belangrijker dat templates in artikelen te bewerken zijn (dus dat mensen de parameters kunnen invullen) dan dat de templates zelf te bewerken zijn. Dit is toch al tamelijk ingewikkeld in sommige gevallen, misschien dat er ook gewoon een goed onderscheid gemaakt kan worden tussen het template zelf en de templatedata, en dat we een categorie/template kunnen maken waarin mensen hulp vragen bij de aanmaak van hun template. Zoveel nieuwe gebruikers gaan niet een template aanmaken, dus volgens mij is in het oogpunt van VE TemplateData gewoon een concessie die we als Wikipedia moeten doen. Tenzij iemand andere suggesties heeft hoe templates automatisch begrepen zouden kunnen worden door de VE en kan overtuigen (de developers overtuigen?) dat dit een meerwaarde heeft ten opzichte van TemplateData. Misschien dat we dit overigens op een wat zichtbaarder plek kunnen bespreken? Mvg, Bas (o) 24 jul 2013 23:04 (CEST)

Hoi Bas, jij vat prima samen wat ik bedoelde. Een navigatie-template heeft inderdaad geen parameters. Dus de TemplateData is alleen voor de tweede groep van belang. Akoopal _overleg 24 jul 2013 23:18 (CEST)

Voor een stuk software dat bedoeld is om het gebruikers eenvoudiger te maken om op Wikipedia te bewerken vind ik het belachelijk dat er zo'n complex code gedoe nodig zou zijn. Vind ik werkelijk onvoorstelbaar. Dat ze op en-wiki alle belangrijke sjablonen beveiligd hebben en alleen moderatoren die sjablonen kunnen bewerken is een heel ander beleid dan we op nl-wiki hebben en dat is sjablonen zo eenvoudig mogelijk te houden zodat zo veel als mogelijk gebruikers ze kunnen aanpassen en aanmaken. Navigatiesjablonen en infoboxen zijn simpel gemaakt zodat een gemiddelde gebruikers deze eenvoudig kan aanpassen en aanmaken. Daar wordt veelvuldig van gebruik gemaakt. Het gaat om vele honderden sjablonen die allemaal bijgehouden moeten worden waarbij al die gebruikers die code moeten kennen plus dat al die sjablonen die lap code moeten krijgen, dat het onderhoudswerk minstens verdubbeld, echt veel te gemakkelijk gedacht. Het is in de praktijk al lastig genoeg om te zorgen dat alles up-to-date blijft in de sjablonen, iets waar we jaren aan gewerkt hebben, daar nog een hele extra nieuwe laag code overheen... Iedere keer dat een infobox gewijzigd wordt (dagelijks worden ze gewijzigd!) moet die codebrij ook aangepast worden. En waar dient het vervolgens toe? Kijk ik wat voor effecten het heeft op en-wiki dat TemplateData gebruikt wordt zie ik vrijwel nauwelijks een verschil ofwel ga je bij parameters nog eens (dubbel) aangeven wat daar ingevuld moet worden, iets wat bij ons de parameternaam al moeit aangeven doorgaans, en dan vraag ik me des te harder af waarvoor al die moeite dan nodig zou zijn. Romaine (overleg) 25 jul 2013 09:27 (CEST)

Romaine: zou je kunnen aangeven hoe je je dat in concept voorstelt? In een template worden een hoop variablen gebruikt, sommigen zijn input, anderen worden misschien tijdelijk gebruikt. Dus sommigen moet je kunnen ingeven, anderen juist niet. Ook wil je bij (bijv) de parameters 'lat' en 'lon' netjes vragen om 'lengtegraad' en 'breedtegraad', wat toch wat vriendelijker is. Als laatste wil je ook een logische volgorde. Dat laatste is specifiek voor de Nederlandse infoboxen te doen, maar bedenk je dat dit generiek voor alle templates moet zijn, en voor alle wiki's. De enige manier waarop ik dat mogelijk zie is om het te vertellen. Ik zeg niet dat TemplateData perse de beste optie is, maar zoiets zal toch nodig zijn. En dit soort informatie wil je ook gebruiken voor de documentatie in de infobox, dus als je dat zou kunnen combineren is de complexiteit nog wat minder. Maar effectief is het een keuze tussen gebruikersvriendelijkheid voor de gebruiker van een infobox op een artikel, en de maker van een infobox. Dan neig ik toch voor het eerste, omdat de laatsten toch meestal wat meer ervaren wikipedianen zijn. Akoopal _overleg 25 jul 2013 10:04 (CEST)

Ik snap nu al totaal niet meer waar jullie het over hebben met die TemplateData. Wat ik wel begrijp is dat de VE het bewerken makkelijker moet maken en dat het dat dus niet op het gebied van sjablonen. Als ik nu al niet meer kan volgen, dan ben ik bang dat ik dat straks helemaal niet meer kan en ik dus hulp in moet schakelen als ik van mening ben dat een sjabloon aanpassingen nodig heeft.

Wat ik ook begrijp uit de bovenstaande is dat de VE niet kan worden geïmplementeerd voordat nlwiki de TemplateData op orde heeft en dat de gemeenschap VE niet wil voordat duidelijk is dat het naar behoren functioneert. één en één is twee, denk ik dan. EvilFreD (overleg) 25 jul 2013 20:16 (CEST)

EvilFred, volgens mij wordt het invullen van een sjabloon in een artikel juist makkelijker. Stel je wilt een sjabloon over een plaats verder invullen (je hebt het kengetal en postcode van die plaats bijv. gevonden die nog niet in de sjabloon in het artikel staan). Met VE en TemplateData krijg je een lijstje van beschikbare invulvelden te zien, waaronder postcode en kengetal. Deze kun je selecteren en vervolgens invullen. Als TemplateData niet wordt gebruikt, moet je als gebruiker maar raden hoe het veld heet: is het netnummer of kengetal of misschien telefoon? Aangezien de sjabloondocumentatie hier veelal ook ontoereikend is, zou je dan zelfs in de sjabloon zelf moeten kijken om uit te vogelen hoe de parameters heten. Ik zie dus zeker meerwaarde in het beschrijven van de parameters voor artikelschrijvers. --Meerdervoort (overleg) 25 jul 2013 21:52 (CEST)

Op deze en deze pagina staat uitleg over TemplateData. De eerste pagina is voor de bewerkers die een sjabloon gebruiken (althans hoe dat werkt), de tweede link gaat over hoe TemplateData in sjablonen ingevoegd moet worden. Dat laatste kan eventueel ook via weer een andere pagina, waardoor dit op het sjabloon zelf onzichtbaar zou kunnen zijn, maar ik vraag me af of dat de boel makkelijker maakt. Het heeft zijn voordelen (voor schrijvers) en zijn nadelen (voor mensen die sjablonen maken). Volgens mij wegen de voordelen op tegen de nadelen en moeten we deze concessie maken om VE een kans te geven (we kunnen moeilijk geenszins meewerken en dan zeggen dat het niet werkt). Mvg, Bas (o) 25 jul 2013 22:05 (CEST)

Als ik het goed begrijp moeten we het inderdaad zo snel mogelijk toevoegen. Het is mij sowieso al te veel gebeurd dat ik enorm moest gaan lopen zoeken naar hoe een template in elkaar steekt om er een variabele bij te zetten. Als ze zoals Romaine, dag in dag uit met templates in de weer bent zal het allemaal wel evident zijn, maar ja, anderen doen ook nog wel eens wat anders. Als ik het goed heb, is dit met template data gewoon verleden tijd. Peilinkje opzetten? -- Stratoprutser (overleg) 25 jul 2013 22:23 (CEST)

@Stratprutser: Zou je per direct kunnen stoppen om in ieder bericht mijn gebruikersnaam te noemen dan wel te verwijzen naar mij. Het is duidelijk dat je het oneens bent met de situatie, voor de rest dragen je woorden niet bij aan een zinvolle discussie hier. Het is verder erg jammer dat je bijzonder weinig tijd steekt in waar het op Wikipedia echt om gaat: de artikelen. Tip! Romaine (overleg) 25 jul 2013 22:49 (CEST)

Je had het eerder vandaag ergens over trollen? EvilFreD (overleg) 25 jul 2013 22:57 (CEST)

Laten we alstublieft de discussie zakelijk houden, en niet persoonlijk worden, de discussie is al lastig genoeg zonder.

@Stratoprutser: een manier om parameters te beschrijven betekent niet dat het ook gebeurd. Ook nu is het vrij makkelijk om documentatie in een infobox te zetten waar de parameters staan, als dat niet gebeurd dan is het er niet, maar dat licht bij de aanmakers. De zorg van Romaine is dat het vergeten word, of dat er fouten worden gemaakt waardoor het niet werkt, en anderen (waarbij hij met dat soort dingen een berg werk verzet) erachteraan moeten dweilen. Ik denk dat iets als templatedata gewoon nodig is, maar de huidige syntax is natuurlijk wel heel techie en meer ontwikkelt op het parsen door een systeem. Aan de andere kant is het met een tool weer te generen. Akoopal _overleg 25 jul 2013 23:18 (CEST)

(na bwc) @Akoopal: Hoe ik wat in concept voorstel? Ik snap je niet.

"In een template worden een hoop variablen gebruikt, sommigen zijn input, anderen worden misschien tijdelijk gebruikt. Dus sommigen moet je kunnen ingeven, anderen juist niet." -> Een infobox heeft parameters, voor de rest snap ik je niet. We hebben vrijwel nergens verplichte parameters, in infoboxen zijn eigenlijk alle parameters in principe optioneel.

"Ook wil je bij (bijv) de parameters 'lat' en 'lon' netjes vragen om 'lengtegraad' en 'breedtegraad', wat toch wat vriendelijker is." -> Of we dat echt willen moeten we ons goed afvragen. Een afweging van de voordelen en nadelen. Op het eerste gezicht wil je het misschien en staat het leuk vriendelijk, maar wat zijn de consequenties en de gevolgen daarvan? Het maakt de toch vrije eenvoudige infoboxen dubbel zo moeilijk en dubbel zo arbeidsintensief om te onderhouden. We hebben bijna 2000 infoboxen en nog veel meer andere sjablonen met parameters. Ik zie dagelijks hoe moeilijk het is om sjablonen bij te houden en up-to-date te houden, er dan zonder meer vanuit gaan dat we dit dan vast wel willen vind ik veel te voorbarig gedacht. De afgelopen 7 jaar hebben we gewerkt om sjablonen zo eenvoudig mogelijk te houden zodat vooral ook gemiddelde gebruikers met weinig sjabloonervaring ze zelf kunnen aanmaken, aanpassen en updaten. We hebben er overigens voor gezorgd dat de meeste parameters als naam al weergeven wat er ingevuld moet worden. Lon en lat zijn dan wellicht een uitzondering maar daarvan willen we helemaal niet dat iemand die handmatig intypt, maar via de tool kopieert en plakt

"Als laatste wil je ook een logische volgorde." -> Zojuist getest, ook dat doet TemplateData niet.

"omdat de laatsten toch meestal wat meer ervaren wikipedianen zijn." -> Het aanmaken en aanpassen van sjablonen is juist ook iets wat vrije nieuwe gebruikers en gemiddelde gebruikers momenteel gewoon zelf doen. Over het algemeen zijn de schrijvers de sjabloonmakers omdat zij een behoefte hebben aan een nieuw sjabloon bij het schrijven van een artikel.

Desalniettemin loop ik al enkele jaren te denken om te zorgen voor een standaard set aan parameters voor bv plaatsinfoboxen.

En echte probleemsjablonen waar juist extra informatie nodig is kan TemplateData niet eens aan om dat goed uit te leggen. Romaine (overleg) 26 jul 2013 01:20 (CEST)

@EvilFred: Er is gezegd dat nl-wiki met de situatie rondom TemplateData vertraagd is in de uitrol, maar dat klinkt buitengewoon ongeloofwaardig in mijn oren, omdat daar de meeste problemen niet liggen. De visuele tekstverwerker kan na meer dan een maand nog steeds niet enkele van de meest eenvoudige sjablonen aan die we hebben en gooit de hele opmaak ermee overhoop. Volgens mij is dat een veel zwaarder wegende factor: nog niet alle sjablonen kan de visuele tekstverwerker aan. Maar als mocht blijken dat het toch puur vanwege de TemplateData is, dan is het mooi meegenomen om minstens eerst te zorgen dat de developers zorgen dat gewoon alle sjablonen goed geïnterpreteerd worden (nota bene de meest eenvoudige sjablonen zijn te moeilijk). Ik deel je egdachte over één en één is twee, ik denk dat we als gemeenschap echt moeten eisen van nieuwe software dat die geen problemen veroorzaakt, en dat doet ie nogthans wel.

Ik tracht er voor te waken dat sjablonen zoals we ze nu kennen ook in de toekomst eenvoudig te bewerken zijn voor gemiddelde gebruikers, waar ik jou wel toe reken. Ik maak me echt grote zorgen wat dat betreft. Romaine (overleg) 26 jul 2013 01:20 (CEST)

@Meerdervoort: :::"Als TemplateData niet wordt gebruikt, moet je als gebruiker maar raden hoe het veld heet" -> In minstens 97% van de infoboxen is dat niet het geval wat je hier zegt, omdat a. in artikelen in principe alle parameters staan en dan ook getoond worden, b. we infoboxen alleen laten opnemen wat er gebruikt wordt. Infoboxen worden daarnaast massaal gebruikt en bij aanmaak meteen ingevuld door bot-creatie.

"Aangezien de sjabloondocumentatie hier veelal ook ontoereikend is" -> Dat is niet juist, er zijn enkele plaats-infoboxen die geen parameteroverzicht hebben, maar de meeste infoboxen hebben een up-to-date parameteroverzicht. We hebben er de afgelopen jaren actief voor gezorgd dat infoboxen in de sjabloonuitleg zeer precies beschrijven welke parameters er mogelijk zijn. Dat je dus in het sjabloon moet kijken is dus onjuist. Romaine (overleg) 26 jul 2013 01:20 (CEST)

@Basvb: We hebben vrijwel alle /doc pagina's opgeruimd door de jaren omdat ze het onderhouden van sjablonen ontzettend moeilijker maakt. Een subpagina lost niets op maar maakt het probleem alleen maar groter.

"Het heeft zijn voordelen (voor schrijvers) en zijn nadelen (voor mensen die sjablonen maken)." -> Over het algemeen zijn de schrijvers de sjabloonmakers omdat zij een behoefte hebben aan een nieuw sjabloon bij het schrijven van een artikel. Romaine (overleg) 26 jul 2013 01:20 (CEST)

(na bwc) @romaine, Ik was misschien niet helemaal duidelijk in mijn bericht, maar het voorbeeld dat ik aan EvilFred gaf mbt de plaatsinfoboxen was niet bedoeld om ook naar te refereren mbt de opmerking over documentatie. Die was algemener van aard, maar gaat ook op voor een aantal Infoboxen over plaatsen. Ik bedoel met documentatie niet alleen een opsomming van parameters, maar ook een beschrijving wat elke parameter betekent (en hoe die gebruikt dient te worden). Dit is overigens geen verwijt, maar enkel een constatering. Verder heb ik in mijn bericht enkel gekeken vanuit het perspectief van de artikelenschrijver, die een sjabloon(parameter) wil toevoegen aan een artikel. Dat een sjabloon direct gevuld wordt bij een botcreatie kan wel waar zijn, maar ik denk dat het voor de artikelenschrijver makkelijk is als er ook enige uitleg wordt gegeven wat elke parameter betekent. Een parameter als code zoals gebruikt in {{Infobox plaats in Frankrijk}} is voor een niet ingewijde natuurlijk totaal onbegrijpelijk (zou het postcode zijn?). Als we met TemplateData een bijschrift maken (en dat kan als ik TemplateData hier zie) is dat alleen maar winst. Mijn bericht moet je dus niet opvatten als een bericht over de bewerkbaarheid van een sjabloon zelf, maar aan het gebruiksgemak van een sjabloon in een artikel. Ik zie dat met het gebruik van TemplateData als winst. Die winst weegt in mijn ogen op tegen het meerwerk voor de maker van een sjabloon. Daarnaast is het niet verplicht om direct TemplateData mee te nemen bij de aanmaak van een sjabloon. Ik ben het dan ook niet eens met je stelling dat het voldoende is om de parameters neer te zetten en dat dat wel begrepen wordt. Ik denk dat daar zeker wat te verbeteren valt; enkel een parameteroverzicht vind ik onvoldoende documentatie. Dat is in mijn ogen geen documentatie. --Meerdervoort (overleg) 26 jul 2013 00:24 (CEST) -- ik zie nu na het opslaan dat Romaine zijn tekst, waar ik op reageer heeft verwijderd. Ik laat dit nu maar even staan en kan gelezen als een verduidelijking van mijn vorige bericht.

Ik had mijn bericht wat gewijzigd omdat ik altijd probeer datgene wat ik schrijf feitelijk correct te hebben, en ik bemerkte een discrepantie in de TemplateData (men had fouten gemaakt in de implementatie van TemplateData.) waardoor ik even mijn woorden wilde heroverwegen. Het grootste deel van mijn bericht als reactie op jou is gelijk gebleven.

"'Een parameter als code zoals gebruikt in {{Infobox plaats in Frankrijk}} is voor een niet ingewijde natuurlijk totaal onbegrijpelijk (zou het postcode zijn?)." -> Op ieder artikel waar dat hoort staat deze code ingevuld. Dat het voor jou onbegrijpelijk is komt enkel puur en alleen doordat je het totaal uit zijn context haalt. Normaal gesproken komt iemand op een artikel, ziet de infobox en dan is meteen duidelijk waarvoor de parameter gebruikt wordt. Erboven staat een parameter met de naam postcode. Verder is nog zinvol om op te merken dat alle andere parameters van die infobox een volledig duidelijke naam hebben, op lat en lon na die met een tool ingevuld dienen te worden.

"Verder heb ik in mijn bericht enkel gekeken vanuit het perspectief van de artikelenschrijver" -> juist de artikelschrijvers passen sjablonen aan...

"Als we met TemplateData een bijschrift maken'" -> krijg ik het gevoel dat we seniel gaan doen. Om wat voorbeelden aan te halen uit Sjabloon:Infobox plaats in Frankrijk, je wilt een bijschrift plaatsen bij postcode, burgemeester, departement, etc? Er zijn vast parameters waarbij het handig kan zijn, maar bij deze is het geen gebruiksgemak maar ga ik het een betutteling vinden naar gebruikers toe met een hoop non-informatie, met daar bovenop dat ze infoboxen helemaal niet meer makkelijk kunnen updaten. Dat noem ik geen winst maar verlies. Zo kan ieder bedrijf winst maken, negeer gewoon alle kosten als je wilt weten hoeveel winst je hebt, dat kan echt niet en is bovendien een vorm van suboptimalisatie. Het gaat hier om een totaalpakket en je kunt niet de nadelen van dat totaalpakket negeren en doen alsof het allemaal zo mooi is. En dat verlies weegt helemaal niet op tegen het meerwerk. Je veegt het hele sjabloononderhoud van tafel alsof het niets is. De basis van infoboxen is dat ze een overzichtelijke set van parameters hebben waarbij de namen van de parameters duidelijk maken waarvoor ze voor dienen. Vervolgens willen gebruikers een infobox eenvoudig snel kunnen gebruiken en kopiëren dan het parameteroverzicht, met daarin duidelijke parameternamen, naar het artikel om het daar in te vullen. In de praktijk van werken met sjablonen is dat het enige wat gebruikers in de praktijk echt nodig hebben.

Op sommige infoboxen staat er wat extra documentatie, maar als ik zie hoe weinig het wordt gebruikt en hoe vaak ik gewoon delen daaruit kan schrappen omdat het al verouderd is, dan is dat zeker niet iets wat we nog eens extra moeten aanbevelen en implementeren. Romaine (overleg) 26 jul 2013 02:06 (CEST)

Ik ben het niet met je eens dat juist artikelenschrijvers sjablonen aanpassen. Dat zal zeker gebeuren, maar evenzeer voegen ze sjablonen toe aan nieuwe en bestaande artikelen. Dat je het gevoel krijgt dat we seniel gaan doen, ben ik het niet mee eens. Ik vind dat enkel het noemen van de parameters onvoldoende is. Bij burgemeester is het wel duidelijk, maar in het geval van code is dat niet zo. Dit is slechts een voorbeeld ter illustratie er zijn vele parameters die ambigu zijn. Als voorbeeld (let wel voorbeeld, er zijn er veel meer te vinden) pak ik het sjabloon {{Infobox vuurtoren}}. Daar staat de parameter afbraak. Zonder enige uitleg is deze parameter in vele opzichten uit te leggen. Jaartal, ja, nee; monument: ja, nee, soort van monument, jaartal van opname als monument enz; karakter: verzin het maar, ik heb geen flauw idee; admiraliteit: ik vermoed dat hier bedoeld wordt onder welk land het valt, maar weet het niet zeker; canada: ik heb werkelijk geen enkel idee. hoogte: tov NAP? vanaf de grond? Dit sjabloon staat niet op zich, maar dit is een voorbeeld van wat ik bedoel met gebrek aan documentatie. En ik heb dan nog niet eens gesproken over het al dan niet automatisch toevoegen van eenheden (bij bijv. hoogte). Al dat soort zaken kunnen met templatedata worden beschreven en maakt het voor mij als artikelenschrijver alleen maar makkelijker. Maar los van templatedate vind ik dus ook dat dit onderdeel gewoon te vaak ontbreekt in de sjablonen. Een voorbeeld waar het wel goed beschreven is, is bijv. {{Infobox plaats in Nederland}}. Naast dit punt kun je ook niet stellen dat alle parameters die beschikbaar zijn ook daadwerkelijk in een bestaand sjabloon in een artikel staan. Ik ben het talloze malen tegengekomen dat dit gewoon niet waar is. Als er sjablonen worden gewijzigd met toevoeging van een nieuwe parameter, wordt dit zeker niet in de artikelen meegenomen. Met het gebruik van templatedata zie je dus dat er een nieuwe parameter beschikbaar is voor het artikel waar je op dat moment mee bezig bent. Dit vergt inderdaad meer onderhoud. Het is echter niet zo, dat ik vind dat dit bij elk sjabloon zou moeten worden toegevoegd. De infoboxen vind ik echter een voorbeeld waar dit voor de eindgebruiker het bewerken een stuk makkelijker maakt. --Meerdervoort (overleg) 26 jul 2013 09:26 (CEST) ps. Ik zie nu net dat ik iets te snel was met de voorbeelden. Een aantal werden wel omschreven (en doorgestreept), maar ook een aantal niet. Punt blijft wel staan dat er genoeg sjablonen zijn waar dit helemaal niet het geval is.

Als ik heel kort door de bocht ga, is het spanningsveld dus gebruiksgemak voor de gebruikers van een infobox en minder complexiteit voor bewerkers van een infobox. Persoonlijk blijf ik erbij dat de eerste het belangrijkste is, maar misschien is deze vraagstelling de goede basis voor een peiling? Daarnaast ben ik zeker bereid te helpen in een soort projectgroep sjablonen om gebruikers te helpen met het aanpassen van complexe sjablonen. Als je daar bijv. in de hulp van de sjablonen goed naar verwijst is dat misschien een goed traject. Die kan zich ook gaan bezighouden met de data toevoegen. Dit is echter niet een eenmalig iets, maar iets dat continuiteit nodig heeft. Akoopal _overleg 26 jul 2013 10:10 (CEST)

En @romaine: ik bedoel: hoe stel jij je voor dat een sjabloon-editor kan werken als er geen informatie is over welke parameters ingevuld kunnen worden. Harvesten over de code zal bijv voor een infobox ook allerlei vage variablen als head1_1 en item1_1 geven, die dus intern zijn. Ik zie dus geen andere mogelijkheid voor een infobox editor dan de input te beschrijven. En als er wat effort komt om uit TemplateData ook een parameter automatisch te genereren, en bijv een tool om uit een parameteroverzicht TemplateData te krijgen, dan is het volgens mij te doen. Akoopal _overleg 26 jul 2013 10:15 (CEST)

Ik denk dat je kort-door-de-bocht samenvatting met het spanningsveld een aardige weergave is. Ik vind ook dat het eerste het belangrijkst is. Een (bredere) projectgroep die helpt bij het aanpassen van sjablonen lijkt mij een uitstekend idee, maar dit wat mag ongeacht de uitkomst van dit overleg hoe dan ook ingevoerd worden. Ik zou hier zeker een steentje aan wil bijdragen. --Meerdervoort (overleg) 26 jul 2013 11:08 (CEST)

@Meerdervoort: Ik ben het met je benaderingswijze totaal oneens, sjablonen trachten we ook op nl-wiki zo eenvoudig mogelijk te houden. Dat je dat zomaar even opzij schuift zonder enige grondslag daarvoor dan protesteer ik daar tegen.

@Akoopal: Je stelt precies de goede vragen. In mijn ogen hebben we van de ontwikkelaars geen andere keuze gekregen en ik zie geen realistisch alternatief dan het toe te passen. Wel denk ik dat het goed is dat we ons bewust moeten zijn van de consequenties en gevolgen die het met zich mee brengt en daar zeker niet gemakzuchtig over moeten doen. Tevens blijven al mijn zorgen staan. Ondertussen is de TemplateData op 3 plekken ingevoegd door gebruikers en op alle drie de plekken ging het fout met het invoegen ervan door onkundigheid van de toevoegers. Romaine (overleg) 27 jul 2013 11:08 (CEST)

Beste Romaine, aangezien het TD nieuw is en de documentatie nog enigszins beperkt is, gaat hier gewoon VJV&GJG op. Al doende leert men. Daag! -- Stratoprutser (overleg) 27 jul 2013 11:22 (CEST)

Hi, ik heb vast een voorschot genomen op Wikipedia:Opinielokaal/Templatedata in_sjablonen - en voor de vorm noem ik even Romaine. -- Stratoprutser (overleg) 26 jul 2013 10:42 (CEST)

FYI, een voorbeeld van templatedata staat op Sjabloon:Infobox vuurtoren en Sjabloon:Bron. Probeer die maar toe te voegen met de visuele editor, en vervolgens enig andere sjabloon. -- Stratoprutser (overleg) 27 jul 2013 11:11 (CEST)

Gezien Romaine zijn reactie denk ik dat een peiling niet echt nodig is. Ik denk dat we beter onze energie kunnen besteden in bespreken hoe wel het beste de TemplateData gaan toevoegen. De foutjes die zijn gemaakt bij de eerste toevoegingen geven aan dat je wel even moet opletten, en dat Romaine's punt dat het ingewikkeld kan zijn best wel hout snijd. Uit het voorbeeld zie ik dat TemplateData een net overzicht geeft van de parameters, waardoor bijv in infobox vuurtoren dat overzicht kan verdwijnen. Een kopieerbaar template moet natuurlijk wel blijven. Mijn voorstel is om TemplateData voorlopig aan het einde van de documentatie te zetten, onder een kopje 'parameteroverzicht' of iets vergelijkbaars. Akoopal _overleg 27 jul 2013 11:43 (CEST)

Onderstrepen

Het zou handig zijn als je ook kan onderstrepen. Of kan dat al? TamerGozubuyuk12 (overleg) 17 jul 2013 16:52 (CEST)

Verplaatst van deze pagina. Bas (o) 18 jul 2013 12:35 (CEST)

Reactie: Ik vraag me af of onderstrepen zo vaak nodig is. Het lijkt me inderdaad logisch als het wel mogelijk is voor die paar keer dat het nodig is. De vraag is echter of het dan zo prominent moet zijn als vaakgebruikte toevoegen van vetgedrukte (elk artikel) en schuine tekst. Mvg, Bas (o) 18 jul 2013 12:35 (CEST)

Onderstrepen gebruik je toch niet op Wikipedia? Ik heb het nooit gezien, althans. Timelezz (overleg) 18 jul 2013 22:44 (CEST)

Volgens mij kan het wel met gewone HTML-code. Bas (o) 18 jul 2013 23:29 (CEST)

Since underlining is not part of wikisyntax like italics and bold are, we are not planning on adding it to VisualEditor. You can still add it using HTML < u >< /u >, as Bas says, if you would like to use that here. Keegan (WMF) (overleg) 19 jul 2013 18:47 (CEST)

Normaal gesproken onderstrepen we geen tekst in artikelen, waar dat gebeurt zijn dat uitzonderingsgevallen. De visuele tekstverwerker moet dat zeker niet gaan promoten door het pontificaal op te nemen, als het echt nodig is kan men via bron bewerken dit toch toevoegen. Romaine (overleg) 20 jul 2013 17:30 (CEST)

Inklappen invoegen transclusie

Bij het bewerken van de tekst kan je iets invoegen. Maar regelmatig wil ik dan even kijken in de tekst wat er nu ook al weer stond. Dit gaat niet als het invoegdialoog (transclusie) groot in beeld is. Het zou fijn zijn als je die even kan inklappen zodat ik nog kan lezen wat er nu ook al weer stond. Timelezz (overleg) 18 jul 2013 22:49 (CEST)

This is caused by not adding TemplateData to templates here, which is a local decision to the Dutch Wikipedia (see the above conversation Infoboxen en parameters). I hope that we can find a better way to add this data to the software without having to add information to templates in the future. Until then parameters will have to be added and checked by hand :\ It's not the best situation; I hope we can make it better soon. Keegan (WMF) (overleg) 19 jul 2013 18:43 (CEST)

Verspringing bij het starten

Als ik de bewerking start, zie ik het scherm eerst even wittig worden, en ook de pagina verspringen. Het wittig worden doet aan alsof de pagina 'hangt' en het verspringen zorgt er voor dat ik even mijn orientatie op de pagina kwijt ben. Als dat beter kan, graag! Timelezz (overleg) 18 jul 2013 22:52 (CEST)

Thank you for letting us know. What browser are you using, and are you having delay when scrolling? Keegan (WMF) (overleg) 19 jul 2013 18:48 (CEST)

Foto's

Foto's worden direct links uitgelijnd. Ook terwijl ze eigenlijk rechts uitgelijnd waren. Dit deed mij verwarren. Ik was bang dat als ik het opsloeg dat dit dan ook opgeslagen zou worden en alle foto's ineens door mij links worden uitgelijnd. Ik ben bang dat veel gebruikers hierdoor zullen afhaken, uit angst iets fout te doen. Ik mis ook opties om de foto's te bewerken. Als ik klik op een foto komen er geen opties tevoorschijn, waarmee ik iets kan bewerken. Timelezz (overleg) 18 jul 2013 22:55 (CEST)

Bedoel je zoiets? Als het iets anders is zou je dan een link kunnen geven naar het artikel waarop dit gebeurde? Mvg, Bas (o) 18 jul 2013 23:30 (CEST)

Het gaat massaal fout met foto's. Daarnaast is het meestal helemaal niet de bedoeling dat foto's bewerkt worden, want in de meeste gevallen wordt dan de afmetingen gewijzigd terwijl die gewoon op thumb of largethumb dienen te blijven staan zodat ofwel aanpasbaar zijn in de voorkeuren van gebruikers (bv slechtzienden) ofwel uitgelijnd zijn op de infobox. Romaine (overleg) 20 jul 2013 17:37 (CEST)

Mijn mening

Ik ben van mening dat de nieuwe editor WEL heel nuttig is. Ik hoop nu ook dat het invoegen van afbeeldingen nu een heel stuk makkelijker zal gaan met deze editor. Deze website (Wikipedia) is een systeem wat door iedereen bewerkt kan worden en is het daarom dus van belang dat er een goede look and feel editor komt. In het verleden heb ik namelijk al eens mijn ongenoegen geuit aan de makers/beheerders van dit medium over de editor die al jaren gebruikt wordt. Ik maak namelijk zelf ook websites en zelfs ik als eenvoudige ICT'er maak gebruik van een systeem met een veel betere en eenvoudigere editor dan dit grote medium. Goed dat er daarom nu aan gewerkt wordt, want de huidige editor is namelijk echt een systeem met een grote K! Mrmark71 23 jul 2013 om 12:49 (CEST)

Ik vraag me eigenlijk af waar jij jouw ongenoegen toen hebt geuit, als ik jouw bijdragen op nl.wiki en op en.wiki bekijk dan ben je de 50 edits verspreid over beide Wiki's nog niet voorbij. Ook zie ik nog geen aanpassingen van jouw hand met het nieuwe systeem. Dqfn13 (overleg) 23 jul 2013 12:56 (CEST)

Aan Dqfn13: Ik heb ze een jaar of wat geleden gemaild. Daarnaast heb ik inderdaad nog niet gekeken naar de nieuwe editor. Misschien ga ik dit nog wel doen, maar ik ga er gewoon van uit dat die een stuk beter wordt dan de huidige. Ik doe ook niet zoveel met dit medium. Mij wordt gevraagd om af en toe eens een pagina aan te passen voor een vriend. That's all. Dat doe ik dan natuurlijk graag, maar verder is dit medium bepaald niet iets waar ik mijn vrije tijd aan wil besteden, vanwege bovenstaande. Ik vind namelijk echt dat bijv. het invoegen van afbeeldingen buitengewoon omslachtig gaat met de huidige editor. DAT kan veel simpeler.

Prima, je brengt het nu alleen alsof het ook echt zo is. Probeer het eens op en.wikipedia, daar draait de nieuwe editor al en er zijn heel erg veel klachten over. Je verwachtingen uitspreken is iets anders dan je mening geven alsof je er ervaring mee hebt... Dqfn13 (overleg) 23 jul 2013 13:20 (CEST)

Aan Dqfn13: Ik sprak inderdaad mijn verwachtingen uit over de nieuwe editor en ik gaf mijn mening over de huidige editor. DAAR heb ik ervaringen mee en dus heb ik DAAR een mening over. Tja... als er nog veel klachten zijn over de nieuwe editor, dan is daar nog veel aan te doen door de ontwikkelaars. De nieuwe editor is dan ook nog in ontwikkelfase en dus nog niet officieel LIVE om op grote schaal gebruikt te worden, neem ik aan.

De nieuwe is al zeker een maand online op en.wiki om daar door iedereen gebruikt te worden en komt dit weekend hier online. Neem anders even een kijk in WP:De kroeg, alwaar meer informatie staat over de datum. Dqfn13 (overleg) 23 jul 2013 13:56 (CEST)

Aan Dqfn13: Okey.. Ik eens een kijkje nemen. ;)