On Tue, Jul 30, 2013 at 12:26 PM, Robert Rohde <rarohde(a)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(a)gmail.com> wrote:
On Jul 30, 2013 4:58 AM, "Marc A.
Pelletier" <marc(a)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(a)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(a)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(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>