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