Just tried the new editor on the English Wiktionary. I don't want to sound too negative, but at this stage there are very few reasons why I would use it. Syntax highlighting / (more importantly maybe, checking) will make a difference. The main feature I'm missing though is support for template autocompletion, not sure if that is planned?
Topic on 2017 wikitext editor/Feedback
When you say "missing", do you mean features you would like to see in the future, or are these implemented in a gadget and you feel switching to this means you lose them?
Syntax checking/highlighting is very computationally expensive, and many of our users have relatively slow machines, so enabling it for all users would not be reasonable. Adding the feature for people to opt into is something we're considering.
I'm not quite sure what you mean by "template autocompletion", however — is this for editing existing templates or inserting new ones? In general we've had very good feedback on the template inserting tool, though often the deciding factor is the quality of the TemplateData for the template that has been written by the template's author.
Missing as in what I would like to see in the future. Autocompletion I mean in the way as it is implemented in most code editors today. An example: you start to type opening braces, then the first few letters and you get presented with possible completions (all templates starting with the previously typed letters). You pick one, type a pipe symbol and get a list or the name of the first parameter, and potentially a list of possible values. This system would help users who are already familiar with templates and manual coding but sometimes forget param order or values. A typical use case would be language data on Wiktionary: the language data for a word must be entered as a 2 to 3 letter code, of which currently over 3000 exist. I know some by heart but often have to look them up. Autocompletion would massively help there.
This would work for both existing and new templates. Regarding the missing TemplateData, it occurred to me that you could try to document the existing templates based on usage, even if there's no documentation provided, by looking at occurrences and typical usage and then offer completion data based on these values. This could be done with some simple statistical analysis.
I think that what you want is available in the visual editor. In the wikitext mode, you need to click Insert > Template to reach it.
The TemplateData GUI tool can 'read' most templates and suggest a list of parameters when you are creating the TemplateData block. But this needs to be done on the template's documentation, not while someone is editing (especially since a bare list of parameters does not provide important descriptive information or examples). When you edit the template, click the button to 'Manage TemplateData' at the top of the page to see how the GUI works.
The "Insert > Template" dialog does provide a list of templates, but the point is that I don't want to use the visual editor, I don't want to click anywhere, I just want to type. I don't want a "wizard"-type dialog which interferes with my workflow, with modal dialogs. With the visual editor, to insert a new template, I have to:
- Click Insert
- Click template
- Type
- Click on Name
- Click Add template
- Insert data
- Click Insert
That's 5 clicks for one single template insert! And there's no option to remember recently used templates etc. so I have to go through all steps again every time.
Also, the autocompletion only works for the template name, not for the template values, so the assistance provided is quite limited.
> Syntax highlighting / (more importantly maybe, checking) will make a difference.
Probably something like this (Help:Syntax_highlighting).
>The main feature I'm missing though is support for template autocompletion
Maybe something like this?: Link_suggestions.
That would be fine for templates, and is easy to implement. However, complete support for auto-completion of template parameters is a pipe dream. A code editor can work properly because there are a finite number of tokens in a programming language (and it can store values already in a page), while there can be millions of template parameters, and their expected values (e.g. parameter = "value1").
ACE editor already supports auto completion of programming code and values entered in the same page (just press Ctrl + space), and this is already working for lua, javascript, and css pages.
Basic auto-completion could theoretically be supported in the 2017 wikitext editor, and possibly even VisualEditor.
> Also, the autocompletion only works for the template name, not for the template values, so the assistance provided is quite limited.
This probably needs something like https://phabricator.wikimedia.org/T53375 .
The disadvantage though is that one would need to enter all 3000 values in your case, and populate add values to all templates that are used frequently
As I said earlier, a naive statistical approach might work for pre-populating values, and would require less maintenance work. It would be a good way to “kickstart” this feature, without template editors having to add more metadata.
To illustrate: I run a data-analysis on the Wiktionary dump and parse all template usages of {{m}} (which would be {{m|en|...}}, {{m|fr|...}}, {{m|de|...}} etc). I could infer the possibly values for the first parameter to be "en", "fr", "de". Even better, I could suggest more common usages first in the dropdown.
This is obviously not going to work perfectly in all cases but it could be a good start.
On a more positive note (not directly related to the new text editor though): I've just started to add a few TemplateData sections to commonly used Wiktionary templates.
I think this will definitely make casual editing a lot easier, for users who are not familiar with the “low-level” spiderweb of technical details.
The help texts could be placed a bit more prominently though, they are quite hidden at the moment.
Do you realize how many templates and arguments are used in wikis like English wikipedia and company? It is likely that they have more than 10000 templates, and some templates have more than 200 parameters. Multiply that with the number of possible permutations of each template value and you could have a serious problem. A parameter without an explanation and context is pointless,e.g. "fr" (fund raiser) and "tlh" (Total Laparoscopic Hysterectomy ) can mean many different things.
Yes, it is possible to do a database dump and populate these parameters, but for some templates it would quickly become outdated, and wouldn't even be a very good picture of the status quo because some parameters are dependent on others, for example, a citation cannot be a book and a newspaper at the same time. It might just confuse newcomers who may add incompatible parameters, and piss off experienced contributors who have to clean up the mess added by people who don't understand how certain templates work.
Right now those who don't know what they mean are unlikely to dig through thousands of template docs to find out. But if these start getting naively exposed, they will start messing up pages at a faster rate.
That's why I created https://phabricator.wikimedia.org/T87444 for. There are thousands of templates to which TemplateData should be added, and resolving that bug would allow prioritizing it.
As I said, it won't be perfect :) And yes, I realize what a mess the current template system is, but didn't expect it to be that bad. 200 parameters – that's insane.
If you just pick the top combinations the system I'm suggesting could work performantly. It's not going to help document parameters on its own but I think that when you see a list of possible completions you get a good idea of the purpose of the parameter.
Also, the point is that this would mostly help experienced users (who are also likely to use the new text editor as opposed to the pure visual editor). I'm not sure if this is the intended split of target audiences (visual editor for new / casual editors, text-based for experienced users) – @Jdforrester?
> And yes, I realize what a mess the current template system is, but didn't expect it to be that bad. 200 parameters – that's insane.
Don't take my word for it, see:
https://en.wikipedia.org/w/index.php?title=Template:Citation/doc
I'd argue that one shouldn't make the situation worse by reinforcing bad practices. Templates that have an extreme amount of parameters or don't have proper documentation should be improved.
So rather than simply generating these automatically for the wikitext editor, a better solution is to use your idea to generate template data for most of them. Editors can then gradually improve their descriptions and documentation instead of simply dumping the parameters and values.
It is already possible to extract some arguments used by templates in fact the templatedata editor does this (although it will fail miserably at extracting lua arguments).
That is a already good starting point.