https://bugzilla.wikimedia.org/show_bug.cgi?id=26786
--- Comment #5 from Happy-melon <happy.melon.w...@gmail.com> 2011-01-21
22:21:24 UTC ---
There are fairly substantial differences between {{cite}} and {{convert}}. The
latter is big and messy and expensive because it's doing something wikitext
wasn't designed for (numerical conversions and string manipulation). It's
immediately obvious how OOP, regular expressions, or even array structures and
intrinsic maths, can help improve both the readability and performance of that
code. I think I've largely finished refining [[Template:Convert]] and its
**three thousand** subtemplates into ~700 lines of PHP, of which 200 are data
constants. It doesn't even attempt to implement all the stupidly many features
of {{convert}}, but it does the heavy lifting and lets templates put the shiny
bells on, if desired, probably in a single moderately complicated wrapper
template.
The {{cite}} templates are a different kettle of fish altogether. They're
there to do what wikitext is *designed* to do: format plain text into pretty
patterns and output it in a consistent way. The reason the templates are so
cumbersome is that a) they try to cover every possible permutation of
parameters for every type of source in one enormous metatemplate, and b)
there's a huge amount of code that's included purely to keep various groups
from tearing each other's throats out over trivial stylistic differences. The
default solution when two groups have spent a year editwarring over the manual
of style over whether authors should be separated by a wiggly line or a
straight line, is to say "either style is acceptable, be consistent within an
article, and don't convert articles from one style to another without local
consensus". Hence a plethora of silly variations from one template to another
and even within uses of the same template, all of which need to be supported in
the metatemplate.
Moving this parsing logic from wikitext to PHP would aid in reducing that
redundancy and bloat, but not by much; there is a genuine need for quite a lot
of flexibility in citation layout, and we certainly can't be moving it into PHP
if it's only going to get code updates pushed once a year; unless and until
Wikimedia gets back onto a more vigorous scap schedule, it would be a recipe
for disaster to require code updates for any change to reference formatting.
I can see a way forward for citations which takes them out of wikitext and into
the software, but not as merely a string-processing widget. It would need to
be a comprehensive change to citation style, making them more semantic and
preferably out of wikitext altogether. Special pages to define field
structures with clear semantic meaning, and separately define 'citation styles'
which cherry-pick particular fields to be included in a given type of citation
(web, news, journal, etc). AJAX-y out-of-edit-window editing of citations, and
just a tiny XMLish tag <citation 123456/>, or more likely <ref
name="usefulPerArticleTitle"><citation globallyUniqueName/></ref> left in the
wikitext, that can easily be picked out by future WYSIWYG editors. Search
listings to identify and merge identical references, and identify broken links,
old accessdates, etc; and no doubt to allow our intrepid bot operators to run
various exciting maintenance tasks on the entire corpus of citations en masse.
That level of integration would be a proper justification for removing what is
fundamentally a text presentation issue, from the medium which wikis generally
use to present text -- wikitext -- and making it a software implementation.
But taking it out of the wikitext purely to improve performance, while keeping
the interface exactly the same, would actually be very difficult; writing a
{{#cite: ... }} parser function which was flexible, adaptible and still usable,
would be very challenging.
Would giving it the whole nine yards like that improve performance? Very
possibly. We could disable brace constructs in the input to citation fields,
and cache the final output indefinitely. It would probably measurably increase
database load and measurably decrease apache load, and would certainly need
careful deployment. But I don't really think there's much value to be gained
from half measures for this particular corner of wikitext.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
