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 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>
_______________________________________________
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>
