Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 7/29/13 10:50 PM, Erik Moeller wrote: On Mon, Jul 29, 2013 at 1:12 PM, Jan Ainali jan.ain...@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 ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Jul 30, 2013 3:49 AM, Marc A. Pelletier m...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 30 July 2013 07:39, Martijn Hoekstra martijnhoeks...@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. ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
Beside being way more effort than it is worth, what is particularly Lovecraftian about that? Cheers, Peter - Original Message - From: Martijn Hoekstra martijnhoeks...@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 m...@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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Jul 30, 2013 4:58 AM, Marc A. Pelletier m...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Tue, Jul 30, 2013 at 9:36 AM, Peter Southwood peter.southw...@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 martijnhoeks...@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 m...@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-requ...@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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Jul 29, 2013, at 11:39 PM, Martijn Hoekstra martijnhoeks...@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 ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra
martijnhoeks...@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
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Tue, Jul 30, 2013 at 11:43 AM, Robert Rohde raro...@gmail.com wrote:
On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra
martijnhoeks...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
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
martijnhoeks...@gmail.com wrote:
On Jul 30, 2013 4:58 AM, Marc A. Pelletier m...@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
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 30 July 2013 09:06, Martijn Hoekstra martijnhoeks...@gmail.com wrote: 6. 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. ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Tue, Jul 30, 2013 at 12:26 PM, Robert Rohde raro...@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
martijnhoeks...@gmail.com wrote:
On Jul 30, 2013 4:58 AM, Marc A. Pelletier m...@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
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Tue, Jul 30, 2013 at 1:01 PM, David Gerard dger...@gmail.com wrote: On 30 July 2013 09:06, Martijn Hoekstra martijnhoeks...@gmail.com wrote: 6. 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 30 July 2013 04:36, Martijn Hoekstra martijnhoeks...@gmail.com wrote: On Tue, Jul 30, 2013 at 1:01 PM, David Gerard dger...@gmail.com wrote: On 30 July 2013 09:06, Martijn Hoekstra martijnhoeks...@gmail.com wrote: 6. 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. jforres...@wikimedia.org | @jdforrester ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
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 jforres...@wikimedia.org On 30 July 2013 04:36, Martijn Hoekstra martijnhoeks...@gmail.com wrote: On Tue, Jul 30, 2013 at 1:01 PM, David Gerard dger...@gmail.com wrote: On 30 July 2013 09:06, Martijn Hoekstra martijnhoeks...@gmail.com wrote: 6. 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. jforres...@wikimedia.org | @jdforrester ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 30 July 2013 15:44, Ziko van Dijk vand...@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. ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 30 July 2013 08:02, David Gerard dger...@gmail.com wrote: On 30 July 2013 15:44, Ziko van Dijk vand...@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. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Mon, Jul 29, 2013 at 11:18 PM, Marc A. Pelletier m...@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.
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
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 ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
2013/7/29 Marc A. Pelletier m...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
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 m...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Mon, Jul 29, 2013 at 1:12 PM, Jan Ainali jan.ain...@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. -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 7/29/2013 1:50 PM, Erik Moeller wrote: On Mon, Jul 29, 2013 at 1:12 PM, Jan Ainali jan.ain...@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 ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
2013/7/29 Michael Snow wikipe...@frontier.com On 7/29/2013 1:50 PM, Erik Moeller wrote: On Mon, Jul 29, 2013 at 1:12 PM, Jan Ainali jan.ain...@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? ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 7/29/2013 2:44 PM, Jan Ainali wrote: 2013/7/29 Michael Snow wikipe...@frontier.com On 7/29/2013 1:50 PM, Erik Moeller wrote: On Mon, Jul 29, 2013 at 1:12 PM, Jan Ainali jan.ain...@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 ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
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 ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 29 July 2013 23:41, Marc A. Pelletier m...@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. ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
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.w...@gmail.com On Jul 29, 2013, at 6:48 PM, Marc A. Pelletier m...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On Mon, Jul 29, 2013 at 4:00 PM, David Gerard dger...@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. -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
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 m...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
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 ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
On 29 July 2013 23:18, Marc A. Pelletier m...@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 ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)
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.w...@gmail.com On Jul 29, 2013, at 7:58 PM, Marc A. Pelletier m...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe
