Extension talk:TemplateAdventures

Looks like a good idea. Are you aware of User:VasilievVV/Extension:InlineScripts? That's another approach to deal with huge cite templates :). Regards, --Church of emacs talk · contrib 15:18, 5 May 2010 (UTC)

Call for examples and suggestions
These template-replacements are generally written according to examples. I therefore call for the people out there to come with examples of usage of the templates existing in the extension (which is #citation: by now) with the desired output.

In addition, ideas for other heavy resource templates are also welcome. --Svippong 16:19, 19 April 2011 (UTC)
 * Or you could buy / borrow a major humanities style guide (the humanities guides generally cover all possible citations, and all permutations) and systematically walk through the required fields in a highly documented style guide like Chicago. Fifelfoo 23:34, 19 April 2011 (UTC)

Worried about ossifying something that is broken
I fully understand why you are doing this, and I support it. However, I am worried that this might prevent our references style from ever being repaired. Consider this wiki code:



Here is what it produces:


 * Ann Orther; Anne Uther (2011), "What's a title?", Journal of Artificial Citations: 42
 * Sam Riter (2011), How About A Book For A Change?, New Jeans: Levi & Levi, p. 42
 * Why does the year look so different here?, World Wide Websites Inc., 2011

We have been working with this for years, but it is just not acceptable in the long run. On Wikipedia there is no valid reason to introduce the page number sometimes with "p. " and sometimes with ":". On Wikipedia there is no valid reason to put the year sometimes in parentheses and sometimes not. Someone has copied a kludgy, historically grown citation style that tries to cram everything into as little space as possible and has moved it into an environment where consistency is a lot more important than space. Will your extension be flexible enough so that such issues of style can be fixed without changing it? Hans Adler 16:07, 22 April 2011 (UTC)
 * The hope is 'yes, it will'. All rendered text is done with messages, which means page being 'p.' or ':' are two different messages, just change them to the same version, and it will appear as intended.  The placement of the year remains at present unmoveable (and other stuff), but I intend to create - perhaps - a format string, where this structure could be defined, but I have not come up with an appropriate syntax. --Svippong 16:27, 22 April 2011 (UTC)
 * How about the following for a syntax (this is just an example):
 * .  . etc.
 * Idea:
 * Curly brackets indicates a variable. e.g.  means it is the variable 'authors', i.e. the list of authors/creators given to a specific citation.
 * Slashes inside variables indicate OR, i.e. it is one of the variables in the brackets, with the first taking precedence of the next, e.g. means that it is for both 'year' and 'date', but if both are set, only 'year' will appear.
 * Colon indicate which area it belongs to, that is, it will only appear here if that variable is set. So if 'authors' is not set,  will not appear even if 'year' and/or 'date' is set.
 * In addition, the 'authors' part of the variable here tells the system which format it should be rendered as, if there is a desire for date/year to remain different depending on where they are put. It seems to me, that dates appear at the front if authors/editors are set, but at the back if not.
 * Full stops, '.', indicates section separation. If a section is empty, it will of course not be granted a separator.  This is purely for syntax purposes.
 * I hope it made somewhat sense. And I sure hope it is useful too. --Svippong 17:42, 22 April 2011 (UTC)


 * I think that's more or less the right direction, although I guess that your example syntax is not general enough (and that you know it). I think ideally the extension should have nothing to do with citations and just add a new and efficient method of getting things done which happens to be a key to solving the problem with the citation templates. Hans Adler 21:36, 22 April 2011 (UTC)
 * Well, then we might be back to the original problem. The reason the original system is slow, is because it is parsed by a general purpose language that is intended for writing articles rather than programming.
 * I would never suggest to the MediaWiki developers to develop the WikiCode further, it is complicated as it is. While I obviously won't rule your request out, but I don't think the extension cannot be general enough, unfortunately without losing major performance (and adding complexity). --Svippong 21:52, 22 April 2011 (UTC)

Separating semantic content from formatting
Ideally, html code should separate semantic content from formatting wherever possible, and leave formatting to style sheets. For example, instead of hard-coding an italicized journal title, the journal title should ideally be wrapped with something like Physical Review D, and then the italicization can be addressed in the stylesheet. Or if someone wanted to portray journal titles in all caps or small caps or underlined, or in a different color, she would be free to use a style sheet that did so. Wrapping article titles in quotation marks could also be done in the style sheet. I've been hesitant to propose this with respect to the Wikipedia citation/core template because it would add even more complexity. But it seems like it would be a good addition here, and easily done. After I've had some time to study the php code here, I might be able to put together a patch proposal.COGDEN 20:24, 22 April 2011 (UTC)


 * This is not only a good idea, but far better from a developing standpoint, because then I have to consider far less the actual styling of any part of the code, and rather focus on its content (as HTML should be). --Svippong 21:53, 22 April 2011 (UTC)