Dear friends, On German Wikipedia, our dear Superbass has contributed a short opinion piece on the principal resistance against the Visual Editor. I think that it should be withhold from you, and I hope that my translation transfers its wit. Ziko
Let us not fool ourselves: The imperfection of the Visual Editor will have an end once; the legitimate arguments to hide it from public will loose their strike capablity. Maybe in half a year, maybe after one whole year, one will implement the thing. What then? Will anybody be capable to contribute? Why did I swot for months to learn wiki code, can now - with some copy and paste and consulting three help pages - code a nearly flawless sortable table and even build a reference without any tool. Was that all for nothing?
Will we then stand on a Medieval Fair, alongside coopers, tinkers, charburners, stenographs and Brockhaus editors, and tell children how Wikipedia has been made once? And in the meanwhile every Tom, Dick and Harry edits without any programming skills our articles. Professor of German, ethnologist emeritus and clerk at eye level with students of computer science, supported by a trivialised input interface. My grandma does professional image editing, champagne can be purchased at Walmart, the type setter is replaced by a content management system and now democratization, or even, ragtagization of Wikipedia.
No lemons help, but don't worry, the last fortress still stands: our set of rules which we have set up with our bare hands from dull basic principles. Complex, convoluted, and permanently differentiating itself, it will also in future distinguish the pimpf from the pro, and hold back the gentrification of the free online encyclopedia. At least, as long as the Foundation creates no tool for that, too.
Machen wir uns nichts vor: Die Unvollkommenheit des Visual Editors wird irgendwann ein Ende haben; die berechtigten Argumente, ihn noch vor der Öffentlichkeit zu verstecken, verlieren an Schlagkraft. Vielleicht in einem halben Jahr, vielleicht in einem ganzen, dann wird man das Ding einsetzen. Was kommt dann? Kann dann hier jeder mitmachen? Wozu habe ich mir monatelang Wikicode erschlossen, kann inzwischen – mit etwas Copy and Paste und Nachschlagen auf drei Hilfeseiten – fast fehlerfrei eine sortierbare Tabelle coden und sogar ohne Hilfsmittel einen Einzelnachweis bauen. War das alles umsonst? Können wir uns dann zu den Küfernhttp://de.wikipedia.org/wiki/K%C3%BCfer, Kesselflicker http://de.wikipedia.org/wiki/Kesselflicker, Köhlernhttp://de.wikipedia.org/wiki/K%C3%B6hler, Stenotypisten http://de.wikipedia.org/wiki/Stenotypist und Brockhausredakteuren auf den Handwerkermarkt stellen und den Kindern zeigen, wie man früher Wikipedia gemacht hat? Und währenddessen bearbeiten Krethi und Plethi bar jeder Programmierkenntnis unsere Artikel. Germanistikprofessor, pensionierte Ethnologin und Sachbearbeiter auf Augenhöhe mit Informatikstudenten, mittels eines trivialisierten Eingabeinterfaces. Meine Oma macht professionelle Bildbearbeitung, den Champagner gibts bei Aldi, statt des Schriftsetzershttp://de.wikipedia.org/wiki/Schriftsetzerhats ein Content-Management-Systemhttp://de.wikipedia.org/wiki/Content-Management-Systemund jetzt auch noch die Demokratisierung, was red ich, Pöbelisierung der Wikipedia. Da helfen auch keine Zitrusfrüchte, aber keine Sorge, noch steht die letzte Bastion: Unser Regelwerk, das wir mit unserer Hände Arbeit aus kargen Grundprinzipien aufgebaut haben. Komplex, verschachtelt und sich permanent ausdifferenzierend scheidet es auch in Zukunft den Pimpf vom Profi und hält die Gentrifizierung der freien Online-Enzyklopädie auf. Jedenfalls so lange, bis die Foundation auch dafür ein Tool entwickelt. -- Superbass http://de.wikipedia.org/wiki/Benutzer:Superbass (Diskussionhttp://de.wikipedia.org/wiki/Benutzer_Diskussion:Superbass) 23:13, 28. Jul. 2013 (CEST)
-------------------------------------------------------------------------------- Ziko van Dijk voorzitter / president Wikimedia Nederland deputy chair Wikimedia Chapters Association Council
Vereniging Wikimedia Nederland Postbus 167 3500 AD Utrecht http://wikimedia.nl --------------------------------------------------------------------------------
On 07/29/2013 03:30 PM, Ziko van Dijk wrote:
On German Wikipedia, our dear Superbass has contributed a short opinion piece on the principal resistance against the Visual Editor. I think that it should be withhold from you, and I hope that my translation transfers its wit.
My poor German suffices to estimate that your translation was "close enough", at least, but leaves one question open to my mind: was this meant as satire or was this in earnest?
Because if it's the latter, I'm really worried about the health of a community that would actively bemoan greater democratization of a project whose entire /raison d'etre/ was the democratization of knowledge.
-- Marc
2013/7/29 Marc A. Pelletier marc@uberbox.org
Because if it's the latter, I'm really worried about the health of a community that would actively bemoan greater democratization of a project whose entire /raison d'etre/ was the democratization of knowledge.
I have not read the vision statement as it is the production of knowledge that need be availible to every human being, but the consumption. To let a lot of people edit is mere a very useful tool to provide readers with the sum of all human knowledge rather than a reason for itself. If there are other tools more effective, we ought to investigate them (or make the vision clearer).
-- Marc
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Mon, Jul 29, 2013 at 1:12 PM, Jan Ainali jan.ainali@wikimedia.se wrote:
I have not read the vision statement as it is the production of knowledge that need be availible to every human being, but the consumption.
Actually, having co-drafted the Vision Statement (it was drafted at the October 2006 Board retreat in Frankfurt and then finalized after community discussion), I can assure you that that was not the intent. I recall that Florence and I talked about that specific aspect a fair bit. We proposed the language "share in" over "given free access to" in order to emphasize that it's not a one-directional process (some treasure trove of knowledge that you are given access to), but a process we are creating an opportunity to participate in. It could be made clearer, but that was the intent.
On 7/29/2013 1:50 PM, Erik Moeller wrote:
On Mon, Jul 29, 2013 at 1:12 PM, Jan Ainali jan.ainali@wikimedia.se wrote:
I have not read the vision statement as it is the production of knowledge that need be availible to every human being, but the consumption.
Actually, having co-drafted the Vision Statement (it was drafted at the October 2006 Board retreat in Frankfurt and then finalized after community discussion), I can assure you that that was not the intent. I recall that Florence and I talked about that specific aspect a fair bit. We proposed the language "share in" over "given free access to" in order to emphasize that it's not a one-directional process (some treasure trove of knowledge that you are given access to), but a process we are creating an opportunity to participate in. It could be made clearer, but that was the intent.
In any case, I'm not sure why we'd conclude that making the production of knowledge more widely available is somehow harmful to the cause of making the consumption of knowledge available to everyone. Because the success of Wikipedia has been built on rather the opposite of that. In that context which comes first, production or consumption, is sort of a chicken-or-the-egg question about the origin of network effects.
--Michael Snow
2013/7/29 Michael Snow wikipedia@frontier.com
On 7/29/2013 1:50 PM, Erik Moeller wrote:
On Mon, Jul 29, 2013 at 1:12 PM, Jan Ainali jan.ainali@wikimedia.se wrote:
I have not read the vision statement as it is the production of knowledge that need be availible to every human being, but the consumption.
Actually, having co-drafted the Vision Statement (it was drafted at the October 2006 Board retreat in Frankfurt and then finalized after community discussion), I can assure you that that was not the intent. I recall that Florence and I talked about that specific aspect a fair bit. We proposed the language "share in" over "given free access to" in order to emphasize that it's not a one-directional process (some treasure trove of knowledge that you are given access to), but a process we are creating an opportunity to participate in. It could be made clearer, but that was the intent.
In any case, I'm not sure why we'd conclude that making the production of knowledge more widely available is somehow harmful to the cause of making the consumption of knowledge available to everyone. Because the success of Wikipedia has been built on rather the opposite of that. In that context which comes first, production or consumption, is sort of a chicken-or-the-egg question about the origin of network effects.
--Michael Snow
Firstly, the clarification from Erik is very valuable. Perhaps I am the only one making that interpretation from the wording in the vision statement, but if what Erik say is the intention is correct (and I have no reason to think otherwise) it could perhaps be stressed further to let everyone in the movement be aware of the importance.
Michael, I would not say we should conclude that it is harmful, rather I would say (or at least, before Eriks clarification) that we would need to justify why "democratization of production" as an end would be more important than giving free access to the sum of all human knowledge. As a thought experiment, what if the question is not chicken-or-the-egg, but rather-natural-born-chicken versus science-improved-production-of-hens? Is the nutrition gained for the consuming population less worth than the employment of farmers?
On 7/29/2013 2:44 PM, Jan Ainali wrote:
2013/7/29 Michael Snow wikipedia@frontier.com
On 7/29/2013 1:50 PM, Erik Moeller wrote:
On Mon, Jul 29, 2013 at 1:12 PM, Jan Ainali jan.ainali@wikimedia.se wrote:
I have not read the vision statement as it is the production of knowledge that need be availible to every human being, but the consumption.
Actually, having co-drafted the Vision Statement (it was drafted at the October 2006 Board retreat in Frankfurt and then finalized after community discussion), I can assure you that that was not the intent. I recall that Florence and I talked about that specific aspect a fair bit. We proposed the language "share in" over "given free access to" in order to emphasize that it's not a one-directional process (some treasure trove of knowledge that you are given access to), but a process we are creating an opportunity to participate in. It could be made clearer, but that was the intent.
In any case, I'm not sure why we'd conclude that making the production of knowledge more widely available is somehow harmful to the cause of making the consumption of knowledge available to everyone. Because the success of Wikipedia has been built on rather the opposite of that. In that context which comes first, production or consumption, is sort of a chicken-or-the-egg question about the origin of network effects.
Firstly, the clarification from Erik is very valuable. Perhaps I am the only one making that interpretation from the wording in the vision statement, but if what Erik say is the intention is correct (and I have no reason to think otherwise) it could perhaps be stressed further to let everyone in the movement be aware of the importance.
Michael, I would not say we should conclude that it is harmful, rather I would say (or at least, before Eriks clarification) that we would need to justify why "democratization of production" as an end would be more important than giving free access to the sum of all human knowledge.
I don't think anybody is trying to say that "democratization of production" is more important than "free access" or even universal free access. But given that the question originated in discussions about the visual editor, I'm not sure why access is being invoked that way, since the editing interface has no direct impact on the reader experience.
The collaborative nature of our projects is also one of our important values. It may be more of a means to an end rather than a goal like the vision statement. But in some sense, achieving the sum of all human knowledge requires all humans to collaborate in it.
--Michael Snow
On 07/29/2013 06:00 PM, Michael Snow wrote:
achieving the sum of all human knowledge requires all humans to collaborate in it
+1
This is particularly important as the quality of coverage decreases sharply as you stray further from the interests that coincide with the profile of current editors (male-dominated, Eurocentric, tech-aware).
We're not going to get coverage from the perspective of other cultural groups until they participate, and they're not going to participate until we make it possible from them to do so without having to face a wall of wikimarkup.
Nostalgia for the "good old days" of hand-spun wikitables with baroque hacked together syntax notwithstanding.
-- Marc
On 29 July 2013 23:41, Marc A. Pelletier marc@uberbox.org wrote:
Nostalgia for the "good old days" of hand-spun wikitables with baroque hacked together syntax notwithstanding.
MediaWiki wikitext should indeed be set on fire and put in a bin and fired into the sun, with any other horrible and termina fates we can think of. (Though ten billion words of legacy content is a pretty good reason we can't do that.)
But one of the unfortunate things about the way the VE rollout's gone is that it's led to people building castles the present otherwise-indefensible disaster of MW wikitext. When what they really need is assurance that a fully capable markup of some sort will remain.
Are there any wikitext constructions that are actually going to be deprecated? With a defined set being what is supported? (Some of which will be [[spandrel (biology)|]]s from wikitext literally being defined as "what the PCRE code in PHP happens to do", but which editors will have come to rely upon.) Will said set be developed with extensive consultation with, how are staff phrasing it these days, "grumpy power users"?
- d.
On 07/29/2013 07:00 PM, David Gerard wrote:
Are there any wikitext constructions that are actually going to be deprecated?
I'm not privy to the architecture decisions, but I'm pretty sure that the absolute worst monstrosity is the possibility of opening markup in a (possibly deeply recursive or, worse, conditional) template that is closed in a different template. Getting it rid of /just/ that would lose us no content (though it would break some frankenstein-grade markup) and gain us a couple orders of magnitude in parsoid reliability and simplicity.
And probably would make most of the VE team cry in relief.
-- Marc
If I'm reading this right, it *would* cause massive problems on the English Wikipedia, with templates like https://en.wikipedia.org/wiki/Template:S-start and https://en.wikipedia.org/wiki/Template:S-end (170,303 transclusions).
Thanks,
Rschen7754 rschen7754.wiki@gmail.com
On Jul 29, 2013, at 6:48 PM, "Marc A. Pelletier" marc@uberbox.org wrote:
On 07/29/2013 07:00 PM, David Gerard wrote:
Are there any wikitext constructions that are actually going to be deprecated?
I'm not privy to the architecture decisions, but I'm pretty sure that the absolute worst monstrosity is the possibility of opening markup in a (possibly deeply recursive or, worse, conditional) template that is closed in a different template. Getting it rid of /just/ that would lose us no content (though it would break some frankenstein-grade markup) and gain us a couple orders of magnitude in parsoid reliability and simplicity.
And probably would make most of the VE team cry in relief.
-- Marc
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 07/29/2013 10:02 PM, Rschen7754 wrote:
If I'm reading this right, it *would* cause massive problems on the English Wikipedia
Oh, it *would* if the syntax was just disabled outright!
Now, if it were me that was in charge of fixing wiki markup, this is what I would do:
(a) require that syntactic elements opened in a template be closed in that template during transclusion* (without a change in code now; i.e.: deprecate but not enforce yet). (b) provide a mechanism by which templates which do this are categorized/marked and otherwise findable. (c) wait suitably long (d) convert current invalid (according to (a) and identified by (b)) syntax by substituting still transcluded templates inline (thus not breaking content) (e) delete/blank/comment out those templates (f) render the previous syntax invalid (by implicitly closing any syntactic construct at the end of transclusion) (g) provide a list of all the subst done in part (d) to the community so that automated tools can fixup/convert/cleanup with new markup/LUA where applicable.
Hopefully, whatever the delay in (c) is would need to be long enough that the more egregious cases or complicated templates have time enough to be transitioned manually, leaving the following subst/cleanup to take care of edge cases and little used templates where the disruption is nowhere as bad.
-- Marc
* This would include, indirectly, the "code fragment" templates like Erik describe since they contain fragments meant to be interpreted in the context of an open syntactic element** -- those are trickier to /find/, but (f) would make them pointless. ** Making, potentially, a giant leap towards making wikimarkup context-free which would solve so many problems with parsoid it's not even funny.
Well, all I know is that we have a couple million instances of {{hat}} and {{hab}} unbalanced templates, which are used daily on hundreds of pages, and they serve a very important function.
Risker
On 29 July 2013 22:58, Marc A. Pelletier marc@uberbox.org wrote:
On 07/29/2013 10:02 PM, Rschen7754 wrote:
If I'm reading this right, it *would* cause massive problems on the
English Wikipedia
Oh, it *would* if the syntax was just disabled outright!
Now, if it were me that was in charge of fixing wiki markup, this is what I would do:
(a) require that syntactic elements opened in a template be closed in that template during transclusion* (without a change in code now; i.e.: deprecate but not enforce yet). (b) provide a mechanism by which templates which do this are categorized/marked and otherwise findable. (c) wait suitably long (d) convert current invalid (according to (a) and identified by (b)) syntax by substituting still transcluded templates inline (thus not breaking content) (e) delete/blank/comment out those templates (f) render the previous syntax invalid (by implicitly closing any syntactic construct at the end of transclusion) (g) provide a list of all the subst done in part (d) to the community so that automated tools can fixup/convert/cleanup with new markup/LUA where applicable.
Hopefully, whatever the delay in (c) is would need to be long enough that the more egregious cases or complicated templates have time enough to be transitioned manually, leaving the following subst/cleanup to take care of edge cases and little used templates where the disruption is nowhere as bad.
-- Marc
- This would include, indirectly, the "code fragment" templates like
Erik describe since they contain fragments meant to be interpreted in the context of an open syntactic element** -- those are trickier to /find/, but (f) would make them pointless. ** Making, potentially, a giant leap towards making wikimarkup context-free which would solve so many problems with parsoid it's not even funny.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 07/29/2013 11:10 PM, Risker wrote:
which are used daily on hundreds of pages, and they serve a very important function.
Yeah, but they are duct tape over weaknesses/flaws in wikimarkup, not a valuable feature. This revolves back to the difficulty in trying to pretend a talk page in wikimarkup is a discussion medium and doing "forum" kind of things with it.
You can break nuts by hitting them with your glasses; I'd rather give you a nutcracker than keep trying to reinforce your glasses so that they don't break. :-)
-- Marc
On 29 July 2013 23:18, Marc A. Pelletier marc@uberbox.org wrote:
On 07/29/2013 11:10 PM, Risker wrote:
which are used daily on hundreds of pages, and they serve a very important function.
Yeah, but they are duct tape over weaknesses/flaws in wikimarkup, not a valuable feature. This revolves back to the difficulty in trying to pretend a talk page in wikimarkup is a discussion medium and doing "forum" kind of things with it.
You can break nuts by hitting them with your glasses; I'd rather give you a nutcracker than keep trying to reinforce your glasses so that they don't break. :-)
Okay, now you're just being silly. My point is that these things exist, they're pervasive, and there has to be contingency for addressing deprecated features such as these because many of those pages will remain active.
In addition, these are features that require a parallel in any future system.
Risker
On Mon, Jul 29, 2013 at 11:18 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 07/29/2013 11:10 PM, Risker wrote:
which are used daily on hundreds of pages, and they serve a very important function.
Yeah, but they are duct tape over weaknesses/flaws in wikimarkup, not a valuable feature.
Templates such as {{hat}} and {{hab}} don't exist so much because of weaknesses in wikimarkup as because passing the content as a parameter would rapidly exceed the Template argument size limit, and possibly other parser limits. Any solution to this "problem" would have to take that into account, unless the vaguely mentioned "new parser" doesn't have such limits.
There's also the fact that a {{hat}}/{{hab}} pair can be clearer than {{hidden|text= with }} 2000 lines further down in the text. Although I suppose the comeback to that is that people using VE don't see such things.
This revolves back to the difficulty in trying to pretend a talk page in wikimarkup is a discussion medium and doing "forum" kind of things with it.
Not entirely. Templates such as {{hidden begin}} and {{hidden end}} are used to hide long lists in a way that Flow is unlikely to satisfactorily support. While HTML markup for multi-column lists is trivial enough to enter directly in a page, people still like to use templates such as {{div col}} / {{div col end}}. And it's not long ago that {{col begin}} / {{col end}} were required to give a (hacky) cross-browser multi-column layout. Nor does this address the "succession box" templates mentioned above.
On 7/30/13 6:40 PM, Brad Jorsch (Anomie) wrote:
Templates such as {{hat}} and {{hab}} don't exist so much because of weaknesses in wikimarkup as because passing the content as a parameter would rapidly exceed the Template argument size limit, and possibly other parser limits. Any solution to this "problem" would have to take that into account, unless the vaguely mentioned "new parser" doesn't have such limits.
There's also the fact that a {{hat}}/{{hab}} pair can be clearer than {{hidden|text= with }} 2000 lines further down in the text. Although I suppose the comeback to that is that people using VE don't see such things.
From an editing perspective, it seems what's wanted here is a way to mark regions of text, and then to specify what processing is done on this region. As you note, {{foo|giant parameter consisting of the whole region}} is one way to do that, but currently doesn't work technically, and looks a bit weird syntactically. Perhaps some kind of region-definition could be a first-class supported feature?
-Mark
On 30 July 2013 13:58, Mark delirium@hackish.org wrote:
On 7/30/13 6:40 PM, Brad Jorsch (Anomie) wrote:
Templates such as {{hat}} and {{hab}} don't exist so much because of weaknesses in wikimarkup as because passing the content as a parameter would rapidly exceed the Template argument size limit, and possibly other parser limits. Any solution to this "problem" would have to take that into account, unless the vaguely mentioned "new parser" doesn't have such limits.
There's also the fact that a {{hat}}/{{hab}} pair can be clearer than {{hidden|text= with }} 2000 lines further down in the text. Although I suppose the comeback to that is that people using VE don't see such things.
From an editing perspective, it seems what's wanted here is a way to mark regions of text, and then to specify what processing is done on this region. As you note, {{foo|giant parameter consisting of the whole region}} is one way to do that, but currently doesn't work technically, and looks a bit weird syntactically. Perhaps some kind of region-definition could be a first-class supported feature?
That'd be great, yes (and really easy to do using Parsoid's DOM) - we could do annotations, comments, content collapsing, etc. - but I can't see how it would work with wikitext in a way that would leave it sanely-editable for users. I'm not sure we want to start building features that only for work VisualEditor users at this point.
J.
On Tue, Jul 30, 2013 at 2:23 PM, James Forrester jforrester@wikimedia.org wrote:
That'd be great, yes (and really easy to do using Parsoid's DOM) - we could do annotations, comments, content collapsing, etc. - but I can't see how it would work with wikitext in a way that would leave it sanely-editable for users. I'm not sure we want to start building features that only for work VisualEditor users at this point.
Which, for the record, is one of our biggest challenges if we want to be tied to the idea of markup based editing for all eternity. The more metadata we want to tie to specific aspects of the markup (e.g. authorship annotations, comments, regions, etc.) the more we really run into the limitations of easy markup-based editing.
This is already the case for some of our features, like the translation extension, which makes it possible to mark up parts of the document as being in need of translation. So you end up with markup like this:
{| class="wikitable" |- ! <translate><!--T:21--> Revenue</translate> !style="text-align:right"| <translate><!--T:22--> $50,559,430</translate> |- | '''<translate><!--T:23--> Expenses:</translate>''' || |- | <translate><!--T:24--> Engineering Group</translate> |style="text-align:right"| <translate><!--T:25--> $13,523,471</translate> |- | <translate><!--T:26--> Fundraiser Group</translate> |style="text-align:right"| <translate><!--T:27--> $3,265,731</translate>
etc.
At the very least, as visual editing becomes more powerful, markup editing likely will become even more cumbersome when dealing with a lot of this kind of complexity. I also doubt that features like realtime collaboration will be supportable in the markup mode. That's why our goal is to really build a visual editor that appeals to advanced users as well as new ones (which is why we've wanted it to be so visible to advanced users). We've still got a long way to go in that regard, of course.
That doesn't mean, however, that we're comfortable just inheriting wikitext paradigms into the visual editing experience in order to win over advanced users early. We do have to say "no" to some requirements, and one of the "asks" which we will definitely not implement is parsing wikitext in VisualEditor to offer the equivalent functionality. That way lies madness.
Erik
On 7/30/13 11:23 PM, James Forrester wrote:
On 30 July 2013 13:58, Mark delirium@hackish.org wrote:
On 7/30/13 6:40 PM, Brad Jorsch (Anomie) wrote:
From an editing perspective, it seems what's wanted here is a way to mark regions of text, and then to specify what processing is done on this region. As you note, {{foo|giant parameter consisting of the whole region}} is one way to do that, but currently doesn't work technically, and looks a bit weird syntactically. Perhaps some kind of region-definition could be a first-class supported feature?
That'd be great, yes (and really easy to do using Parsoid's DOM) - we could do annotations, comments, content collapsing, etc. - but I can't see how it would work with wikitext in a way that would leave it sanely-editable for users. I'm not sure we want to start building features that only for work VisualEditor users at this point.
For the wikitext syntax, I'm not sure what the best approach is, but would some kind of start/end tag syntax work? I had in mind a region-annotation approach similar to either HTML or LaTeX: <region type="foo"></region> or that kind of thing. Where "foo" is the template (or some other kind of processor) it gets handed off to.
It wouldn't necessarily even have to be much different from what a {{foo-start}} and {{foo-end}} pair do currently, just the parent document needs some way of knowing that the pair create a region, whereas something like regions is currently implicitly created by unmarked pairs of start/end templates like {{hat}} / {{hab}} that generate fortuitously matching markup fragments.
-Mark
On 07/30/2013 05:23 PM, James Forrester wrote:
That'd be great, yes (and really easy to do using Parsoid's DOM) - we could do annotations, comments, content collapsing, etc. - but I can't see how it would work with wikitext in a way that would leave it sanely-editable for users. I'm not sure we want to start building features that only for work VisualEditor users at this point.
Surely the solution is as simple as making that a first class syntactic element with a well-defined open and close syntax rather than rely on template trickery.
-- Marc
But is subst:ing the code and then deleting the template the right solution for a template that is transcluded over 170,000 times?
Overall, I find solutions to such problems that require extensive volunteer manpower to implement and remove functionality from the editor to be quite problematic.
Thanks,
Rschen7754 rschen7754.wiki@gmail.com
On Jul 29, 2013, at 7:58 PM, Marc A. Pelletier marc@uberbox.org wrote:
On 07/29/2013 10:02 PM, Rschen7754 wrote:
If I'm reading this right, it *would* cause massive problems on the English Wikipedia
Oh, it *would* if the syntax was just disabled outright!
Now, if it were me that was in charge of fixing wiki markup, this is what I would do:
(a) require that syntactic elements opened in a template be closed in that template during transclusion* (without a change in code now; i.e.: deprecate but not enforce yet). (b) provide a mechanism by which templates which do this are categorized/marked and otherwise findable. (c) wait suitably long (d) convert current invalid (according to (a) and identified by (b)) syntax by substituting still transcluded templates inline (thus not breaking content) (e) delete/blank/comment out those templates (f) render the previous syntax invalid (by implicitly closing any syntactic construct at the end of transclusion) (g) provide a list of all the subst done in part (d) to the community so that automated tools can fixup/convert/cleanup with new markup/LUA where applicable.
Hopefully, whatever the delay in (c) is would need to be long enough that the more egregious cases or complicated templates have time enough to be transitioned manually, leaving the following subst/cleanup to take care of edge cases and little used templates where the disruption is nowhere as bad.
-- Marc
- This would include, indirectly, the "code fragment" templates like
Erik describe since they contain fragments meant to be interpreted in the context of an open syntactic element** -- those are trickier to /find/, but (f) would make them pointless. ** Making, potentially, a giant leap towards making wikimarkup context-free which would solve so many problems with parsoid it's not even funny.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Jul 30, 2013 4:58 AM, "Marc A. Pelletier" marc@uberbox.org wrote:
On 07/29/2013 10:02 PM, Rschen7754 wrote:
If I'm reading this right, it *would* cause massive problems on the
English Wikipedia
Oh, it *would* if the syntax was just disabled outright!
Now, if it were me that was in charge of fixing wiki markup, this is what I would do:
(a) require that syntactic elements opened in a template be closed in that template during transclusion* (without a change in code now; i.e.: deprecate but not enforce yet). (b) provide a mechanism by which templates which do this are categorized/marked and otherwise findable. (c) wait suitably long (d) convert current invalid (according to (a) and identified by (b)) syntax by substituting still transcluded templates inline (thus not breaking content) (e) delete/blank/comment out those templates (f) render the previous syntax invalid (by implicitly closing any syntactic construct at the end of transclusion) (g) provide a list of all the subst done in part (d) to the community so that automated tools can fixup/convert/cleanup with new markup/LUA where applicable.
Something like the following process might be a little easier on the projects. Assuming that ultimately want each page to be a valid fragment, suitably defined:
Introduction period:
1. Deprecate the alternative *right now*, by publicly announcing what it is exactly we would rather not see exist, wikitext wise.
2. Start engaging the projects, and set up wikiprojects that are responsible for finding the cases where no reasonable alternative for the current legitimate uses is, and work on expanding the language to make sure these cases are covered as well as being responsible for setting up forums for getting help on how to migrate away from depricated syntax.
Transition period:
3. For a suitably long time, display a warning when such a page is saved, refering users to the local working group that can help them learn how to write New Wikitext. More legitimate uses will emerge, and reasonable alternatives must be found or created for everything we are able to do now.
4. Block the creation of new templates with deprecated syntax. Also block saving templates that were free of deprecated syntax would an edit introduce deprecated syntax.
5. When the wikiprojects are no longer buckling under the load of the stream of unimagined creative and useful yet horrible uses of wikitext they didn't forsee, and a good deal of templates have been fixed, start showing warnings when saving pages that transclude pages with deprecated syntax. Repeat the above steps of waiting and fixing.
6. Announce a date from where on saving a page with a transcluded legacy template will be blocked. Expect public outcry.
7. Deal with the outcry by making a list of things yet to be fixed. Move the deployment date to a month after all* bugs have been closed.
8. Block saving pages that contain brokenness. Expect outcry.
If outcry, roll back and go to 7.
9. With sufficient technical ingenuity, freeze and archive the dark legacy. Don't make it mix with the brave new world.
10. Celebrate successful deployment, and wish each other a happy 2020.
An important consideration that all developers must keep in mind is that though the current syntax is quite horrible, it also serves a purpose, and though its existence in itself is quite horrible, the fact that it is widely used is completely reasonable.
*: for a sufficiently reasonable value for all.
Hopefully, whatever the delay in (c) is would need to be long enough that the more egregious cases or complicated templates have time enough to be transitioned manually, leaving the following subst/cleanup to take care of edge cases and little used templates where the disruption is nowhere as bad.
-- Marc
- This would include, indirectly, the "code fragment" templates like
Erik describe since they contain fragments meant to be interpreted in the context of an open syntactic element** -- those are trickier to /find/, but (f) would make them pointless. ** Making, potentially, a giant leap towards making wikimarkup context-free which would solve so many problems with parsoid it's not even funny.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote: <snip>
- Block the creation of new templates with deprecated syntax. Also block
saving templates that were free of deprecated syntax would an edit introduce deprecated syntax.
<snip>
Strictly speaking this is impossible. While there are some common cases that could be recognizable on a per template basis, there are other cases that are only recognizable as problems when placed in the context in which the are used.
To give a ridiculous example:
A template {{foo}} consisting of "> Nothing here <" looks innocuous enough until embedded in a page that reads "<div{{foo}}/div>".
Because templates can contain tag, table, and other markup fragments, the implications for the parser aren't necessarily clear until the template is used in context with other elements. So one could identify this as an issue when saving the page that uses it, but there is no general way to identify all templates that might be problematic at the time the template is written.
-Robert Rohde
On Tue, Jul 30, 2013 at 11:43 AM, Robert Rohde rarohde@gmail.com wrote:
On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
<snip> > 4. Block the creation of new templates with deprecated syntax. Also block > saving templates that were free of deprecated syntax would an edit > introduce deprecated syntax. <snip>
Strictly speaking this is impossible. While there are some common cases that could be recognizable on a per template basis, there are other cases that are only recognizable as problems when placed in the context in which the are used.
To give a ridiculous example:
A template {{foo}} consisting of "> Nothing here <" looks innocuous enough until embedded in a page that reads "<div{{foo}}/div>".
Because templates can contain tag, table, and other markup fragments, the implications for the parser aren't necessarily clear until the template is used in context with other elements. So one could identify this as an issue when saving the page that uses it, but there is no general way to identify all templates that might be problematic at the time the template is written.
-Robert Rohde
Drat, you are clearly right. I was hoping there was a way to dream up a transition where at no point a seperation between "old syntax transcusion" and "new syntax transclusion" would have to be made until the very last moment (my step 9 above). It should still be possible to find and mark templates that are broken through a one time exhaustive search (find all transclusions, and check if the generated DOM for the transcluded fragment is identical to the generated DOM of the fragment itself) and make a split there.
My first thought was that it would be completely unfeasible bordering impossible to do that on every page save, but now that I think of it, while it would undoubtably be very rough on the backend, for a cause as noble as moving away from template madness it might be worth it ( a single extra query and the number of inclusions extra full page parses - but some parse results could be cached for a transitional period, and you can stop once you have found one failing parse). The WMF devs should be far more able to estimate its impact, but It's a little soon to discuss that, as the wish to deprecate the current semantics hasn't even been officially stated.
--Martijn
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
When discussing issues like this. One should keep in mind that we don't really want to be in the business of "solving" hard problems simply by pushing the difficulties onto other people. Wikitext has some characteristics that make parsing it hard (some might say ridiculous). Changing wikitext will create problems elsewhere (and a lot of work for volunteers). In addition one should be careful that any changes are made in such a way that important workflows are not made significantly harder for editors.
To give a common example, see {{nom}}, which consists of:
style="background: #FDD; color: black; vertical-align: middle; text-align: {{{align|center}}}; {{{style|}}}" class="no table-no2" | Nominated
A clever person will quickly realize that this is used in a table context like:
{| | Golden Globes || Best Actress || {{nom}} |}
Where the {{nom}} template carries with it not just the text "Nominated" but also part of the styling to be applied to the table.
This would seem to be a hard example to reimplement in a context agnostic way. At present the template content only makes sense because it is placed in the context of a wiki table. Getting around that would seem to be awkward. You could try to fudge it by applying the {{nom}} styles to something like a div block. However, placing that block within the table cell would run the risk of cell padding and other table properties causing conflicts or bad appearance, not to mention that such an approach couldn't be used if the template is also passing colspan / rowspan directives to the cell. Alternatively, one would pretty much have to pull all or most of the table into the template, which would seem to lead to new headaches and make the source that is much more complicated for authors than the present version.
This is one of the examples where there would seem to be few good alternatives. Maybe the devs who are imagining reengineering wikitext can also think up good alternatives for some of the uses they might contemplate making obsolete?
-Robert Rohde
P.S. {{nom}} and its sister templates are an example of templates that VE can't presently handle.
On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Jul 30, 2013 4:58 AM, "Marc A. Pelletier" marc@uberbox.org wrote:
On 07/29/2013 10:02 PM, Rschen7754 wrote:
If I'm reading this right, it *would* cause massive problems on the
English Wikipedia
Oh, it *would* if the syntax was just disabled outright!
Now, if it were me that was in charge of fixing wiki markup, this is what I would do:
(a) require that syntactic elements opened in a template be closed in that template during transclusion* (without a change in code now; i.e.: deprecate but not enforce yet). (b) provide a mechanism by which templates which do this are categorized/marked and otherwise findable. (c) wait suitably long (d) convert current invalid (according to (a) and identified by (b)) syntax by substituting still transcluded templates inline (thus not breaking content) (e) delete/blank/comment out those templates (f) render the previous syntax invalid (by implicitly closing any syntactic construct at the end of transclusion) (g) provide a list of all the subst done in part (d) to the community so that automated tools can fixup/convert/cleanup with new markup/LUA where applicable.
Something like the following process might be a little easier on the projects. Assuming that ultimately want each page to be a valid fragment, suitably defined:
Introduction period:
- Deprecate the alternative *right now*, by publicly announcing what it is
exactly we would rather not see exist, wikitext wise.
- Start engaging the projects, and set up wikiprojects that are
responsible for finding the cases where no reasonable alternative for the current legitimate uses is, and work on expanding the language to make sure these cases are covered as well as being responsible for setting up forums for getting help on how to migrate away from depricated syntax.
Transition period:
- For a suitably long time, display a warning when such a page is saved,
refering users to the local working group that can help them learn how to write New Wikitext. More legitimate uses will emerge, and reasonable alternatives must be found or created for everything we are able to do now.
- Block the creation of new templates with deprecated syntax. Also block
saving templates that were free of deprecated syntax would an edit introduce deprecated syntax.
- When the wikiprojects are no longer buckling under the load of the
stream of unimagined creative and useful yet horrible uses of wikitext they didn't forsee, and a good deal of templates have been fixed, start showing warnings when saving pages that transclude pages with deprecated syntax. Repeat the above steps of waiting and fixing.
- Announce a date from where on saving a page with a transcluded legacy
template will be blocked. Expect public outcry.
- Deal with the outcry by making a list of things yet to be fixed. Move
the deployment date to a month after all* bugs have been closed.
- Block saving pages that contain brokenness. Expect outcry.
If outcry, roll back and go to 7.
- With sufficient technical ingenuity, freeze and archive the dark legacy.
Don't make it mix with the brave new world.
- Celebrate successful deployment, and wish each other a happy 2020.
An important consideration that all developers must keep in mind is that though the current syntax is quite horrible, it also serves a purpose, and though its existence in itself is quite horrible, the fact that it is widely used is completely reasonable.
*: for a sufficiently reasonable value for all.
Hopefully, whatever the delay in (c) is would need to be long enough that the more egregious cases or complicated templates have time enough to be transitioned manually, leaving the following subst/cleanup to take care of edge cases and little used templates where the disruption is nowhere as bad.
-- Marc
- This would include, indirectly, the "code fragment" templates like
Erik describe since they contain fragments meant to be interpreted in the context of an open syntactic element** -- those are trickier to /find/, but (f) would make them pointless. ** Making, potentially, a giant leap towards making wikimarkup context-free which would solve so many problems with parsoid it's not even funny.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Tue, Jul 30, 2013 at 12:26 PM, Robert Rohde rarohde@gmail.com wrote:
When discussing issues like this. One should keep in mind that we don't really want to be in the business of "solving" hard problems simply by pushing the difficulties onto other people. Wikitext has some characteristics that make parsing it hard (some might say ridiculous). Changing wikitext will create problems elsewhere (and a lot of work for volunteers). In addition one should be careful that any changes are made in such a way that important workflows are not made significantly harder for editors.
my point three wasn't something trivial, and will require a heck load of engineering (for refrerence: 3. For a suitably long time, display a warning when such a page is saved, referring users to the local working group that can help them learn how to write New Wikitext. More legitimate uses will emerge, and reasonable alternatives must be found or created for everything we are able to do now. )
To give a common example, see {{nom}}, which consists of:
style="background: #FDD; color: black; vertical-align: middle; text-align: {{{align|center}}}; {{{style|}}}" class="no table-no2" | Nominated
A clever person will quickly realize that this is used in a table context like:
{| | Golden Globes || Best Actress || {{nom}} |}
Where the {{nom}} template carries with it not just the text "Nominated" but also part of the styling to be applied to the table.
This would seem to be a hard example to reimplement in a context agnostic way. At present the template content only makes sense because it is placed in the context of a wiki table. Getting around that would seem to be awkward. You could try to fudge it by applying the {{nom}} styles to something like a div block. However, placing that block within the table cell would run the risk of cell padding and other table properties causing conflicts or bad appearance, not to mention that such an approach couldn't be used if the template is also passing colspan / rowspan directives to the cell. Alternatively, one would pretty much have to pull all or most of the table into the template, which would seem to lead to new headaches and make the source that is much more complicated for authors than the present version.
I'm convinced that the MediaWiki devs will be able to device a way to do this better. My markup and style foo is too weak to even speculate about what that better may be like.
This is one of the examples where there would seem to be few good alternatives. Maybe the devs who are imagining reengineering wikitext can also think up good alternatives for some of the uses they might contemplate making obsolete?
-Robert Rohde
When I said celebrate a happy 2020, it was a case of ha ha only serious. There are easy nor quick fixes for these issues, and any change will not only cost a lot of engineering, but will also require a lot of effort from the communities to fix the breakages it will introduce, which is why I find it so important to have this discussion long before engineering plans are drawn up.
P.S. {{nom}} and its sister templates are an example of templates that VE can't presently handle.
Which is why I think it is very important to have this discussion. I also think I made my points on this thread and list to a sufficient level, and will try to sit back and read what the people who really know what they are talking about have to say about it.
On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Jul 30, 2013 4:58 AM, "Marc A. Pelletier" marc@uberbox.org wrote:
On 07/29/2013 10:02 PM, Rschen7754 wrote:
If I'm reading this right, it *would* cause massive problems on the
English Wikipedia
Oh, it *would* if the syntax was just disabled outright!
Now, if it were me that was in charge of fixing wiki markup, this is what I would do:
(a) require that syntactic elements opened in a template be closed in that template during transclusion* (without a change in code now; i.e.: deprecate but not enforce yet). (b) provide a mechanism by which templates which do this are categorized/marked and otherwise findable. (c) wait suitably long (d) convert current invalid (according to (a) and identified by (b)) syntax by substituting still transcluded templates inline (thus not breaking content) (e) delete/blank/comment out those templates (f) render the previous syntax invalid (by implicitly closing any syntactic construct at the end of transclusion) (g) provide a list of all the subst done in part (d) to the community so that automated tools can fixup/convert/cleanup with new markup/LUA where applicable.
Something like the following process might be a little easier on the projects. Assuming that ultimately want each page to be a valid fragment, suitably defined:
Introduction period:
- Deprecate the alternative *right now*, by publicly announcing what it
is
exactly we would rather not see exist, wikitext wise.
- Start engaging the projects, and set up wikiprojects that are
responsible for finding the cases where no reasonable alternative for the current legitimate uses is, and work on expanding the language to make
sure
these cases are covered as well as being responsible for setting up
forums
for getting help on how to migrate away from depricated syntax.
Transition period:
- For a suitably long time, display a warning when such a page is saved,
refering users to the local working group that can help them learn how to write New Wikitext. More legitimate uses will emerge, and reasonable alternatives must be found or created for everything we are able to do
now.
- Block the creation of new templates with deprecated syntax. Also block
saving templates that were free of deprecated syntax would an edit introduce deprecated syntax.
- When the wikiprojects are no longer buckling under the load of the
stream of unimagined creative and useful yet horrible uses of wikitext
they
didn't forsee, and a good deal of templates have been fixed, start
showing
warnings when saving pages that transclude pages with deprecated syntax. Repeat the above steps of waiting and fixing.
- Announce a date from where on saving a page with a transcluded legacy
template will be blocked. Expect public outcry.
- Deal with the outcry by making a list of things yet to be fixed. Move
the deployment date to a month after all* bugs have been closed.
- Block saving pages that contain brokenness. Expect outcry.
If outcry, roll back and go to 7.
- With sufficient technical ingenuity, freeze and archive the dark
legacy.
Don't make it mix with the brave new world.
- Celebrate successful deployment, and wish each other a happy 2020.
An important consideration that all developers must keep in mind is that though the current syntax is quite horrible, it also serves a purpose,
and
though its existence in itself is quite horrible, the fact that it is widely used is completely reasonable.
*: for a sufficiently reasonable value for all.
Hopefully, whatever the delay in (c) is would need to be long enough that the more egregious cases or complicated templates have time enough to be transitioned manually, leaving the following subst/cleanup to take care of edge cases and little used templates where the disruption is nowhere as bad.
-- Marc
- This would include, indirectly, the "code fragment" templates like
Erik describe since they contain fragments meant to be interpreted in the context of an open syntactic element** -- those are trickier to /find/, but (f) would make them pointless. ** Making, potentially, a giant leap towards making wikimarkup context-free which would solve so many problems with parsoid it's not even funny.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 30 July 2013 09:06, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
- Announce a date from where on saving a page with a transcluded legacy
template will be blocked. Expect public outcry. An important consideration that all developers must keep in mind is that though the current syntax is quite horrible, it also serves a purpose, and though its existence in itself is quite horrible, the fact that it is widely used is completely reasonable.
The question then will be how to keep parsing old versions reasonably. I suppose we could keep an old wikitext parser around. *shudder*
(Or just punt the question into the long grass. Do old page versions pull in contemporary versions of the page's templates or use the current versions? If the latter, then heh, too bad.)
[These are technical questions, but I think they have sufficient impact to discuss more widely, e.g. on this list. Assuming enough relevant devs are around to comment.]
- d.
On Tue, Jul 30, 2013 at 1:01 PM, David Gerard dgerard@gmail.com wrote:
On 30 July 2013 09:06, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
- Announce a date from where on saving a page with a transcluded legacy
template will be blocked. Expect public outcry. An important consideration that all developers must keep in mind is that though the current syntax is quite horrible, it also serves a purpose,
and
though its existence in itself is quite horrible, the fact that it is widely used is completely reasonable.
The question then will be how to keep parsing old versions reasonably. I suppose we could keep an old wikitext parser around. *shudder*
(Or just punt the question into the long grass. Do old page versions pull in contemporary versions of the page's templates or use the current versions? If the latter, then heh, too bad.)
This *sounds* horrible, but is exactly what happens now. If a template changes, old revisions break. I suppose that if MediaWiki would go for a change in template semantics, an option besides letting them break, is to substitute all 'legacy' templates into their parents last revision before the changeover. How many revisions back one would want to do this and in what timeframe sounds like a discussion point, but I don't see this as a far more broken process than template changes cause right now.
[These are technical questions, but I think they have sufficient impact to discuss more widely, e.g. on this list. Assuming enough relevant devs are around to comment.]
- d.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 30 July 2013 04:36, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Tue, Jul 30, 2013 at 1:01 PM, David Gerard dgerard@gmail.com wrote:
On 30 July 2013 09:06, Martijn Hoekstra martijnhoekstra@gmail.com
wrote:
- Announce a date from where on saving a page with a transcluded
legacy
template will be blocked. Expect public outcry. An important consideration that all developers must keep in mind is
that
though the current syntax is quite horrible, it also serves a purpose,
and
though its existence in itself is quite horrible, the fact that it is widely used is completely reasonable.
The question then will be how to keep parsing old versions reasonably. I suppose we could keep an old wikitext parser around. *shudder*
(Or just punt the question into the long grass. Do old page versions pull in contemporary versions of the page's templates or use the current versions? If the latter, then heh, too bad.)
This *sounds* horrible, but is exactly what happens now. If a template changes, old revisions break. I suppose that if MediaWiki would go for a change in template semantics, an option besides letting them break, is to substitute all 'legacy' templates into their parents last revision before the changeover. How many revisions back one would want to do this and in what timeframe sounds like a discussion point, but I don't see this as a far more broken process than template changes cause right now.
That's what we did last time we switched how templates work (the MW 1.2 -> 1.3 transition) . "Template syntax conversion bot" (or whatever) spidered across the corpus and created a new top revision as needed, IIRC.
J.
It's interesting how an essentially social question (being welcoming to new people by a Visual editor) turns quickly into a debate on software. Ziko
-------------------------------------------------------------------------------- Ziko van Dijk voorzitter / president Wikimedia Nederland deputy chair Wikimedia Chapters Association Council
Vereniging Wikimedia Nederland Postbus 167 3500 AD Utrecht http://wikimedia.nl --------------------------------------------------------------------------------
2013/7/30 James Forrester jforrester@wikimedia.org
On 30 July 2013 04:36, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Tue, Jul 30, 2013 at 1:01 PM, David Gerard dgerard@gmail.com wrote:
On 30 July 2013 09:06, Martijn Hoekstra martijnhoekstra@gmail.com
wrote:
- Announce a date from where on saving a page with a transcluded
legacy
template will be blocked. Expect public outcry. An important consideration that all developers must keep in mind is
that
though the current syntax is quite horrible, it also serves a
purpose,
and
though its existence in itself is quite horrible, the fact that it is widely used is completely reasonable.
The question then will be how to keep parsing old versions reasonably. I suppose we could keep an old wikitext parser around. *shudder*
(Or just punt the question into the long grass. Do old page versions pull in contemporary versions of the page's templates or use the current versions? If the latter, then heh, too bad.)
This *sounds* horrible, but is exactly what happens now. If a template changes, old revisions break. I suppose that if MediaWiki would go for a change in template semantics, an option besides letting them break, is to substitute all 'legacy' templates into their parents last revision before the changeover. How many revisions back one would want to do this and in what timeframe sounds like a discussion point, but I don't see this as a far more broken process than template changes cause right now.
That's what we did last time we switched how templates work (the MW 1.2 -> 1.3 transition) . "Template syntax conversion bot" (or whatever) spidered across the corpus and created a new top revision as needed, IIRC.
J.
James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 30 July 2013 15:44, Ziko van Dijk vandijk@wmnederland.nl wrote:
It's interesting how an essentially social question (being welcoming to new people by a Visual editor) turns quickly into a debate on software.
.nl has yet to experience the software in question, and the social issues surrounding it ...
- d.
On 30 July 2013 08:02, David Gerard dgerard@gmail.com wrote:
On 30 July 2013 15:44, Ziko van Dijk vandijk@wmnederland.nl wrote:
It's interesting how an essentially social question (being welcoming to
new
people by a Visual editor) turns quickly into a debate on software.
.nl has yet to experience the software in question, and the social issues surrounding it ...
VisualEditor has been enabled as an alpha on nlwiki for testing since May, same as another 15 wikis, actually. But yes, there's a substantive difference between the usage of the software in a small number of knowingly-testing edits by experienced users (who normally want to do relatively-edge cases) and actual real-world usage in exploring the social, design and technical issues.
J.
On Jul 30, 2013 3:49 AM, "Marc A. Pelletier" marc@uberbox.org wrote:
On 07/29/2013 07:00 PM, David Gerard wrote:
Are there any wikitext constructions that are actually going to be deprecated?
I'm not privy to the architecture decisions, but I'm pretty sure that the absolute worst monstrosity is the possibility of opening markup in a (possibly deeply recursive or, worse, conditional) template that is closed in a different template
I can dream up horrors you can't even imagine. Consider a template consisting if two single quotes. For a demonstration, see http://en.Wikipedia.org/wiki/User:Martijn_Hoekstra/Lovecraftian_horror2
Getting it rid of /just/ that would
lose us no content (though it would break some frankenstein-grade markup) and gain us a couple orders of magnitude in parsoid reliability and simplicity.
And probably would make most of the VE team cry in relief.
-- Marc
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 30 July 2013 07:39, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
I can dream up horrors you can't even imagine. Consider a template consisting if two single quotes. For a demonstration, see http://en.Wikipedia.org/wiki/User:Martijn_Hoekstra/Lovecraftian_horror2
D-:
That's like a story parents tell VE developers to scare them into behaving.
- d.
Beside being way more effort than it is worth, what is particularly Lovecraftian about that? Cheers, Peter ----- Original Message ----- From: "Martijn Hoekstra" martijnhoekstra@gmail.com To: "Wikimedia Mailing List" wikimedia-l@lists.wikimedia.org Sent: Tuesday, July 30, 2013 8:39 AM Subject: Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Jul 30, 2013 3:49 AM, "Marc A. Pelletier" marc@uberbox.org wrote:
On 07/29/2013 07:00 PM, David Gerard wrote:
Are there any wikitext constructions that are actually going to be deprecated?
I'm not privy to the architecture decisions, but I'm pretty sure that the absolute worst monstrosity is the possibility of opening markup in a (possibly deeply recursive or, worse, conditional) template that is closed in a different template
I can dream up horrors you can't even imagine. Consider a template consisting if two single quotes. For a demonstration, see http://en.Wikipedia.org/wiki/User:Martijn_Hoekstra/Lovecraftian_horror2
Getting it rid of /just/ that would
lose us no content (though it would break some frankenstein-grade markup) and gain us a couple orders of magnitude in parsoid reliability and simplicity.
And probably would make most of the VE team cry in relief.
-- Marc
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Tue, Jul 30, 2013 at 9:36 AM, Peter Southwood < peter.southwood@telkomsa.net> wrote:
Beside being way more effort than it is worth, what is particularly Lovecraftian about that? Cheers, Peter
What's bad about it, is that the meaning of the transcluded content changes radically on the context into which it is transcluded.
What's Lovecraftian about it is that it changes the syntactical meaning of elements on the page that it is transcluded in to, without even having to be near it.
--Martijn
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
----- Original Message ----- From: "Martijn Hoekstra" < martijnhoekstra@gmail.com> To: "Wikimedia Mailing List" <wikimedia-l@lists.wikimedia.**orgwikimedia-l@lists.wikimedia.org
Sent: Tuesday, July 30, 2013 8:39 AM Subject: Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Jul 30, 2013 3:49 AM, "Marc A. Pelletier" marc@uberbox.org wrote:
On 07/29/2013 07:00 PM, David Gerard wrote:
Are there any wikitext constructions that are actually going to be deprecated?
I'm not privy to the architecture decisions, but I'm pretty sure that the absolute worst monstrosity is the possibility of opening markup in a (possibly deeply recursive or, worse, conditional) template that is closed in a different template
I can dream up horrors you can't even imagine. Consider a template consisting if two single quotes. For a demonstration, see http://en.Wikipedia.org/wiki/**User:Martijn_Hoekstra/** Lovecraftian_horror2http://en.Wikipedia.org/wiki/User:Martijn_Hoekstra/Lovecraftian_horror2
Getting it rid of /just/ that would
lose us no content (though it would break some frankenstein-grade markup) and gain us a couple orders of magnitude in parsoid reliability and simplicity.
And probably would make most of the VE team cry in relief.
-- Marc
______________________________**_________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l ,
<mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-request@lists.wikimedia.org ?subject=**unsubscribe> ______________________________**_________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-request@lists.wikimedia.org ?subject=**unsubscribe>
______________________________**_________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-request@lists.wikimedia.org ?subject=**unsubscribe>
On Jul 29, 2013, at 11:39 PM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
I can dream up horrors you can't even imagine. Consider a template consisting if two single quotes. For a demonstration, see http://en.Wikipedia.org/wiki/User:Martijn_Hoekstra/Lovecraftian_horror2
Iä! Iä! Cthulhu Fhtagn!
Seriously, awesome example.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Mon, Jul 29, 2013 at 4:00 PM, David Gerard dgerard@gmail.com wrote:
Are there any wikitext constructions that are actually going to be deprecated?
We don't know yet. We try to support almost everything. In addition to the unbalanced templates that Marc mentions, there are templates that literally insert individually meaningless bits of markup (e.g. style="color:#ccc;'' class="foo"|Bar, which is partially table markup and partially CSS) into another context like a table or image thumbnail syntax. Especially when talking about widely used templates, we try to support those constructions in Parsoid -- but if community members are open to changing templates and/or template-invoking pages, that will help at least in the short term. We do try to provide information to this effect in bug reports. And yes, these kinds of uses of templates do make the devs cry. If you listen closely when it's quiet and still, you can hear them wail.
In the long run, we may have to announce some markup as deprecated, and some of the crazier template uses seem likely candidates. At some point when we switch to the new parser, it would then just stop behaving as with the current MediaWiki parser implementation, with appropriate warning. We're still a long way from that, though.
On 7/29/13 10:50 PM, Erik Moeller wrote:
On Mon, Jul 29, 2013 at 1:12 PM, Jan Ainali jan.ainali@wikimedia.se wrote:
I have not read the vision statement as it is the production of knowledge that need be availible to every human being, but the consumption.
Actually, having co-drafted the Vision Statement (it was drafted at the October 2006 Board retreat in Frankfurt and then finalized after community discussion), I can assure you that that was not the intent. I recall that Florence and I talked about that specific aspect a fair bit. We proposed the language "share in" over "given free access to" in order to emphasize that it's not a one-directional process (some treasure trove of knowledge that you are given access to), but a process we are creating an opportunity to participate in. It could be made clearer, but that was the intent.
I second that statement
Florence
Don't worry, Marc, Superbass uses irony and is pro VE. Ziko
-------------------------------------------------------------------------------- Ziko van Dijk voorzitter / president Wikimedia Nederland deputy chair Wikimedia Chapters Association Council
Vereniging Wikimedia Nederland Postbus 167 3500 AD Utrecht http://wikimedia.nl --------------------------------------------------------------------------------
2013/7/29 Marc A. Pelletier marc@uberbox.org
On 07/29/2013 03:30 PM, Ziko van Dijk wrote:
On German Wikipedia, our dear Superbass has contributed a short opinion piece on the principal resistance against the Visual Editor. I think that it should be withhold from you, and I hope that my translation transfers its wit.
My poor German suffices to estimate that your translation was "close enough", at least, but leaves one question open to my mind: was this meant as satire or was this in earnest?
Because if it's the latter, I'm really worried about the health of a community that would actively bemoan greater democratization of a project whose entire /raison d'etre/ was the democratization of knowledge.
-- Marc
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Marc A. Pelletier wrote:
On 07/29/2013 03:30 PM, Ziko van Dijk wrote:
On German Wikipedia, our dear Superbass has contributed a short opinion piece on the principal resistance against the Visual Editor. I think that it should be withhold from you, and I hope that my translation transfers its wit.
My poor German suffices to estimate that your translation was "close enough", at least, but leaves one question open to my mind: was this meant as satire or was this in earnest?
https://en.wikipedia.org/wiki/Poe%27s_law :-)
MZMcBride
wikimedia-l@lists.wikimedia.org