Talk:Main Page

CirrusSearch
Can we implement the CirrusSearch Extension? It makes searching more comfortable because it does spelling correction, among other improvements. --barto (talk) 06:35, 24 August 2017 (EDT)
 * It does seem to require an effort to install, but it is worth it. --barto (talk) 08:50, 31 August 2017 (EDT)

Gadget Extension to see links to disambiguation pages
The Gadget Extension (which Wikipedia has) makes it possible for a user to display links to disambiguation pages in orange instead of blue. (Among other things.) This makes it possible to spot lazy links and fix them. --barto (talk) 15:44, 24 August 2017 (EDT)


 * Possibly, but there are rarely many. I go through them every so often and tidy them up. --prime mover (talk) 16:37, 24 August 2017 (EDT)

On whitespace before headings
I do support the increased whitespace before section headings, for the exact reason as explained in the FAQ. But the way in which it is added has some drawbacks, and in fact MediaWiki:common.css exists precisely for this purpose. I have tested the css-based solution by writing some code at user:barto/common.css so that, for me, the amount of whitespace is now always right. Here are some advantages and disadvantages of using css, after which I discuss alternative solutions and what css can and cannot do. I hope I'm not missing any important aspects. Any thoughts are welcome. (Please comment at the very end only.)

Tl;Dr: Replace all rules about blank lines around section headings by one simple rule, together with some other advantages including section editing, but at the cost of removing double blank lines before headings in the source text, possibly reducing its readability?

Advantages:


 * Easier to contribute. The less conventions (new) users have to keep in mind, the happier they will be to contribute.
 * Less discussions. If whitespace is fixed automatically, users are less likely to express their opinions about it, or to notice the increased whitespace in the first place.
 * Semantics. It is semantically wrong to use  (which is what happens now) to increase top margin.
 * Customizability. A coded solution is customizable, as opposed to relying on specific Wikitext usage on every page.
 * Section editing. Section editing could be allowed again. (See alternative solutions below for why it is not.) It has multiple advantages; some that come to mind are: Less need to scroll when editing Wikitext, more descriptive edit summaries, faster page load when editing/previewing (I've had problems with this when I was editing at places with slower connection than I have at home).
 * One may argue that this is not such an advantage because pages at ProofWiki are, generally, small. Still, even relatively short proofs take quite some space in the Wikitext. Either way it's more elegant to only edit a section, especially if you want to correct a typo, add some extra explanation, add a link in the Also see section, add a source, ... There are other philosophical arguments in favor, such as the idea that unrelated edits should not be done at once.

Doubts you may have:


 * What with existing pages? Increasing the top margin using css, combined with the existing line break on those pages creates too much whitespace.
 * Indeed. That's were jQuery comes to aid: it can remove those empty paragraphs, without affecting anything else.
 * But then the page content jumps when the page is loaded.
 * I don't know how to avoid that. But consider that it will always jump a bit due to MathJax.
 * There are currently about 50000 pages. They would all have to be brought up to the new standard.
 * Unfortunately, yes. I would never punish anyone by having them fix that manually. Except a bot. As long as the job isn't finished, jQuery can take care of them. Remember that it won't have to be done ever again, because the styling of all headings will be automatized.
 * Wikitext readability. Blank lines in the Wikitext make it easier to spot section headings. Especially considering that there are many single blank lines in the source text already, because statements are separated by a blank line.
 * I agree. On the other hand, with section editing there's less need for it. It will be mostly useful for refactoring and restructuring tasks, or when creating a page.
 * Still...
 * To some extent, it's a matter of habit. Consider that the extra blank lines in source text are specific to ProofWiki, and are not used on e.g. Groupprops or Wikipedia, so not everyone will find the extra blank line needed for readability. I discussed this further at Alternative solutions below.
 * I don't think pages in [insert namespace] should be affected.
 * No problem. Common.css can take care of that. See code details below.
 * Not all section headings need more whitespace. For example subsections that come immediately after a section heading, or transcluded definitions at equivalence proofs of multiple definitions.
 * Again, this is no problem for css. Even better: css can be used here to make sure they all follow the same format, and any changes in style will be applied to them all at once.
 * Some templates create section headings, and should not be accessible through section editing.
 * An administrator can lock them.

In summary, the only lasting disadvantage I see is readability of the source text. It has to be decided whether this outweighs the advantages above. Consider also that we could replace all rules about blank lines around headings by just one simple rule:
 * One blank line before a heading, one blank line after.

See also Alternative solutions below.

Alternative solutions


 * 1) Change the default number of blank lines at the end of a section when section editing.
 * When submitting a section edit (or any edit), what the MediaWiki parser does is:
 * Trimming
 * Adding "\n\n" at the end
 * It would be nice to make the parser add "\n\n\n" at the end instead. This would allow section editing while maintaining the right amount of whitespace. It does however not solve other things such as customizability, semantics and special cases like definitions at definition equivalences and perhaps others.
 * Unfortunately, this is not configurable, or at least not without hacking into internal MediaWiki files.
 * 1) Change the way Wikitext is interpreted. Keep the double blank lines before headings, but don't let MediaWiki create empty paragraphs. Add the whitespace using css instead.
 * This would allow multiple blank lines in the source text for readability, without affecting the result. A disadvantage is that section editing removes those blank lines again. Also, it still involves different source code rules on blank lines (though they won't affect the output anymore).
 * I could not find anything about whether it's possible to customize wikitext interpretation (will update when I do) but it's very likely that it is not, again, at least not legally and free from danger.
 * 1) Keep it the way it is.

It must be noted that (unless we resort to more hacking) 1 and 2 would affect all pages, including user pages.

Code details

There are some things to be taken into account in common.css (and common.js for the temporary jQuery script):


 * Headings following headings. We probably don't want as much whitespace as usual between two headings if there's no text between them. No problem for css.
 * Definitions at definition equivalences. It appears that the current policy is to reduce whitespace between them. No problem for css, but requires some more code. Also does not depend on there being a blank line between them in the source code or not.
 * (In general: 2n blank lines in source text = 2n+1 blank lines in source text = n empty paragraphs in output.)
 * Restricting to namespaces. There are some namespaces like Category:, User:, talk pages, that perhaps we don't want to affect. That's no problem, in fact MediaWiki has cues in the source code that are created specifically to distinguish between them when using common.css.
 * Browser compatibility. The css I wrote at user:barto/common.css uses some features of css3, but the most recent versions of all major browsers support them.

For the jQuery paragraph removing script: only empty paragraphs right before headings must be removed, but this is no problem. The following must be taken care of:


 * Empty paragraphs created by blank lines between list items; see e.g. Definition:Open.

The following cannot be affected, because they don't involve empty paragraphs:


 * Double blank lines before "then" in theorem statements or, similarly, in definitions. Or anywhere else between two paragraphs.

Thoughts? --barto (talk) 06:41, 4 September 2017 (EDT)


 * Whatever we need to do that:
 * a) gives me least work to do, I would rebel against a regime that made me do a lot of rework;
 * b) leaves it looking stylistically exactly the same as it is now.
 * Apart from that, I'm okay with whatever is decided. --prime mover (talk) 09:52, 4 September 2017 (EDT)


 * A lot of your points focus on enabling section editing. I consider section editing a flawed means of editing, and I know by experience that the MediaWiki parser code generating it is buggy and unpredictable, especially in combination with transclusion. That right, in combination with what is the single most used MW feature on ProofWiki.
 * Additionally there are very many cases where I would rather avoid that someone changes one part of the page (say, the proof), and accidentally uses different notation from the theorem statement. No thank you.
 * Those qualms regarding section editing (which makes up a good portion of the aims you seem to have with this change) having been mentioned, I think it can only add to the ease of contributing. Not a lot, admittedly, but a bit. And it helps to reduce frustration from header distance not behaving as wanted. So I would be in favour of experiments and a good style sheet.
 * Last point I want to mention here is the behaviour of transclusion. Because of the logical way this technique's tags are placed, we get extra line breaks for free. I would like to see a plan to address this. &mdash; Lord_Farin (talk) 15:11, 4 September 2017 (EDT)


 * On section editing : I'd personally like there to be an option to disallow editing transcluded sections (without having to use html tags for those headers). With the suggestion on transclusion below, I think it is possible.
 * I agree that section editing would slighty increase the possiblity that someone uses different notation than in the theorem statement. On the other hand, experienced users won't, and the bold unexperienced who are not informed about our policies on notations will probably do it anyway. Something we can already do now, is adding a line in ProofWanted as a reminder to use the same notation. --barto (talk) 12:28, 7 September 2017 (EDT)


 * On transclusion : It is infortunate that the placement of the onlyinclude tags matters so much. What would be ideal are tags that trim the text when transcluded.
 * Solution? There is no hope that the behaviour of onlyinclude will ever be changed because many wikis rely on it. However, what should be possible is to create a variant of the tag that does trim. (Alternatively, we could maybe combinine onlyinclude with a trimming template (I'm not sure, because of 's in the source code), but the transcluding syntax will become inelegant.)
 * If it's possible, a key question (but not something to focus on now) will be: should the text be trimmed always, or only when transcluded?
 * Lastly, an advantage of our own onlyinclude tags is that (I think) we could disallow section editing of transcluded sections (by placing everything in a  or something, + common.css) --barto (talk) 12:28, 7 September 2017 (EDT)


 * Editing sections is easy, I'm editing one now. You just right click on the subheading.


 * I've said it before, I'll say it again, and I will continue to say it over and over again until the apocalypse: it ain't broke, don't fix it. If you feel the need for a programming exercise to keep you occupied, bend some thought to how we may be able to add some structure to Category:Specific Numbers.


 * All the dreaming aside, here is a realistic, practical suggestion: From now on, place the onlyinclude tags such that there are no additional linebreaks inside. This does not affect anything, again by mediawiki's whitespace handling. (It's how onlyinclude is supposed to be used.) --barto (talk) 05:40, 8 September 2017 (EDT)


 * "Improving" the MW transclusion mechanism is something that I have been looking into with regard to the ProofWiki extension (having options to increase heading levels and multiple transcludable sections, among other things). However, it turns out to be a pain because the parser code generating the table of contents is an absolute mess and by default will omit sections transcluded that way. While I would encourage such a mechanism to work (because as said, it enables more features than just whitespace control) I think it presupposes work on the table of content generation in MediaWiki. If you are interested I have some discussions on the MediaWiki issues board that should provide a good introduction.


 * Changing the placement of onlyinclude will introduce a major inconcistency in the source code formatting, and make it much harder to find the places where it starts and ends (due to the tags not being on their own line). I don't think this will improve things over time. Maybe we can rely on the jQuery to save us when it comes to transclusion.


 * In summary, I conclude that there is currently nothing in the source code conventions that can be suitably improved at this moment. However I still support the CSS/jQuery experiment to see if we can make steps towards achieving this layout with the proper technical tool. &mdash; Lord_Farin (talk) 05:14, 9 September 2017 (EDT)

css/jQuery proposal
There seems to be some support for testing out the css/jQuery approach. Shall we try it? It can always be limited to specific namespaces. --barto (talk) (contribs) 18:01, 30 October 2017 (EDT)


 * I would definitely prefer this to be thoroughly tested on the user pages before considering to bring a change of this magnitude live. &mdash; Lord_Farin (talk) 14:38, 4 November 2017 (EDT)

Hosting and ads
Below is a discussion I moved from user:barto to here.

Some people tell me they don't want to use or contribute to just because it has ads. That's sad. I think it is not hard to find a university or something that's willing to host the site for free. They tend to have huge servers anyway, so hosting won't make a big difference for them. --barto (talk)


 * I use Adblock so I don't get ads. I'm wary about this site being hosted by a university because I don't go to university and you can bet bullets to bullshit that they'll disallow anyone not an alumnus from contributing. If that happens I'm going on another killing spree, but this time I won't stop when I've reached my age in weeks.


 * Many people don't use adblock, but that doesn't matter. The success of ProofWiki should not rely on Adblock. Whether it's a university or some mathematical society, we still decide what happens to the site. The idea is simply that someone would pay for ProofWiki as an act of generosity. --barto (talk) 17:11, 24 August 2017 (EDT)


 * Nobody ever does anything as an act of generosity. Universities are businesses out to make money, and they do that by charging people for the use of their facilities, and they do that by blocking everybody who isn't a fee-paying student.


 * But I'm just one person, and my opinion bears no more weight than that of everyone else, I just won't be around when it happens. No worries.

Another option is to become part of wikimedia. Reading their criteria it does seem that ProofWiki has a good chance of meeting them. Our goals and style do differ from Wikipedia:WikiProject Mathematics (we're not an encyclopedia but more a dictionary, quite the opposite and complementary to it), any Wikibooks on mathematics (we do not focus on one topic, dictionary style) and Wikiversity (not a collection of courses, nothing is done twice, dictionary style, nonlinear) --barto (talk) 17:05, 4 September 2017 (EDT)
 * If we're to preserve the current structure of requesting an account, the site would have to be independent of SUL. The problems that this site has faced in the past with spambots doesn't make opening up the site to anyone with a Wikipedia account an attractive proposition in my opinion. I'm unsure how open to compromise the sysadmins would be on this, as SUL is deemed to be a relatively important feature. There would be no harm in one of us creating a proposal on meta, however. I could always start drafting one in userspace. Caliburn (talk) 17:20, 4 September 2017 (EDT)


 * IF we were to merge with metawikipedia, then I am afraid that is where and I would part ways. --prime mover (talk) 18:27, 4 September 2017 (EDT)


 * That would be very unfortunate, you are an exceptionally valuable contributor. Again, I do forsee problems involving SUL, and independence also. While we would not lose control of the project, we would most likely have to allow Wikimedia stewards and sysadmins reasonably escalated access. Thank god the WMF is nothing like Wikia, and do keep the interest of the community in mind in their actions. The migration would of course welcome a stream of new, inexperienced users, which is a monumental positive in some senses, and a significant negative in others. I quite like the status quo in terms of the editing environment, so I'm not sure how I'd feel about it, though I've only been here for a few weeks. Caliburn (talk) 18:47, 4 September 2017 (EDT)


 * Yeah well, I've not been here that long myself, I don't think I'd be missed. --prime mover (talk) 01:16, 5 September 2017 (EDT)


 * Good point. I don't know how spam-proof wikimedia is. There are surely other things I haven't thought about. Either way, everyone here would have to agree.
 * Quote from About: The more people we have supporting the project, the bigger and better it will become. --barto (talk) 09:39, 5 September 2017 (EDT)
 * While there's no doubt that an influx of unexperienced editors requires more tidying and explaining policies (which can frustrate you if you let it), it is the only way in which a community can truly become great. It will be impossible for one user to patrol everything, and that's a good thing: there exists more than a lifetime of mathematics to read. --barto (talk) 10:07, 5 September 2017 (EDT)

Just to make clear why I think getting rid of ads is beneficial: And for finding a generous hosting provider: in particular, wikimedia: --barto (talk) 09:39, 5 September 2017 (EDT)
 * Makes the site more attractive
 * Less distraction for those who learn by reading ProofWiki
 * No more need for ads
 * The future of ProofWiki is secured: when one day the current administrators retire, the site will continue to exist
 * Currently people might refuse to contribute because they don't know who owns ProofWiki (a person or a (non-profit) organization?). (Or whether someone is able to shut the site down and take advantage of their contributions for personal gain. I know it sounds paranoid, but it wouldn't surprise me if some people think like that.)
 * Likely to attract many contributors
 * (conjectured) Higher page rank in search engines
 * Technical support as much as we want

I'm currently preparing for Hurricane Irma. I'll try to address this stuff as well once I get some time. --Joe (talk) 10:41, 6 September 2017 (EDT)

Caching problem
Suppose you have a picture which you have uploaded, and included in a page, with a size, for example:

Suppose you then upload a new version of that file, using "Upload file".

However much you refresh the cache, purge, whatever you have to do, it will not update the page to show this new version.

If, instead, you change the size of the image on the page:

... the new version appears.

But then if you go back to the old size:

... you once more get the old version back.

Is there a way of purging these old views of the files, so you don't have to change it size to see the new version? --prime mover (talk) 07:40, 1 October 2017 (EDT)


 * Hm, strange. I checked today and all seemed to be fine when reverting to 400px. It must be caching somewhere, but I cannot determine now if it is server-side or client-side. Also couldn't find any similar cases online. We'll have to keep looking if it reoccurs. &mdash; Lord_Farin (talk) 17:48, 4 October 2017 (EDT)


 * Local caching problem. Sorted. I hate my new machine. --prime mover (talk) 18:27, 4 October 2017 (EDT)

Symbolic Evolution
I have come up against the difference in notational preferences for a sequence or a series: $\left\langle{a_n}\right\rangle$ or $\left({a_n}\right)$ or even $\left\{ {a_n}\right\}$?

For and against:


 * $\left\langle{a_n}\right\rangle$ is also used for the generator of a group, and so can be confused with it. The reason it has been settled on for this site is because it's what I learned in uni, and what I have in certain of my source works, and that is where it settled.


 * $\left\{ {a_n}\right\}$ can be conflated with the set notation, and so carries the subtext "order does not matter, uniqueness does" which are both fundamentally not the case for sequences. No takers for this, I hope.


 * $\left({a_n}\right)$ is what Barto, for one, uses by preference. I have been routinely changing them to $\left\langle{a_n}\right\rangle$ in my ongoing drive for consistency, but I have been minded that it may be "the most sensible" notation -- because it is the same sort of notation as the "ordered tuple", it brings its own subtext that "order matters, and terms may not be unique".

So, a big suggestion for a major refactoring task: should we settle on $\left({a_n}\right)$ for the standard notation on for sequences and series? My vote is: yes, but we don't need to do the change all in one go please. --prime mover (talk) 08:29, 22 October 2017 (EDT)


 * Hmmm... I tend to use $(a_n)$ indeed, I guess because it's what I grew up with or what's easiest to write down (pen & paper, I mean). Regardless of that, I do see some objective reasons to prefer them: $\langle\cdot\rangle$ is sometimes used for generated substructures (e.g. linear span), and $\{\cdot\}$ makes it look like a set (without ordering). I'd like to hear other arguments I'm overlooking. --barto (talk) (contribs) 18:51, 25 October 2017 (EDT)


 * Well, $\langle\cdot\rangle$ can be confused with a generator just as much as $(\cdot)$ can be confused with an ideal... and with the general ubiquity of parentheses in mathematics (both in text, like here, and for order explication, and for function invocation, and ideals as mentioned, and probably for more things), it hardly seems that we need more things using parentheses.
 * Rather, it seems to me that sequences are one of the places where there is a reasonably common alternative with $\langle\cdot\rangle$. I see no harm using it and even less a need to refactor all of them away.
 * But I could live with the compromise that both are allowed (although consistency will suffer). &mdash; Lord_Farin (talk) 11:23, 29 October 2017 (EDT)

Proof count on main page
What about something like currently has about proofs. at the main page? Or does this slow down page loading? --barto (talk) 10:02, 25 October 2017 (EDT)
 * We had this for a long time, I forget why we removed it (anyone remember?). Would be nice to overhaul the main page in general. I'm cool with adding it back if you have a proposal. --Joe (talk) 10:05, 25 October 2017 (EDT)


 * I think you removed it so as to de-clutter the front page a couple of years ago. We used to use it to keep an idea of the count of the proofs so we could add "landmark" proofs: "This is the "n"th proof on ProofWiki!" It would be good to have it back.


 * A count on the "Proven Results" category will in general be an overestimate, because parent pages which are the container for Proof 1, Proof 2, etc. are also counted, because they transclude the qed. But it would be a start. --prime mover (talk) 10:35, 25 October 2017 (EDT)


 * True. But there's no harm in exaggerating a bit, especially if we put "about" before the number. --barto (talk) (contribs) 19:09, 25 October 2017 (EDT)


 * Is there a better way we could estimate? I could add something to our extension. Eg. all pages that contain and don't contain any todos, etc. --Joe (talk) 11:20, 26 October 2017 (EDT)


 * If we could count pages with qed on them and not include the pages they are transcluded into, that would probably be the best technique, to my mind. I would say: keep it simple, and don't exclude pages with todos on them because they shouldn't have a qed on them in the first place. --prime mover (talk) 12:24, 26 October 2017 (EDT)


 * I have this implemented locally. Can anyone think of a good way to likewise count definitions? --Joe (talk) 14:56, 3 November 2017 (EDT)


 * Is it possible to count the contents of a category and all its subcategories? And exclude redirects in the process? --prime mover (talk) 16:05, 3 November 2017 (EDT)


 * The issue is that definition pages sometimes have several subpages including examples. How accurate do we want to be. Consider Definition:Rational_Number, it has several subpages, are these to be counted as more than 1. If so how do we ignore the "note" subpage. One idea I had was count the number of links to unique definitions from proofs. That total is around around 3,500 unique pages. All unique definition links from all namespaces is almost 10,000 (about the same as counting all pages in the definition namespace). Which of these feels more accurate? --Joe (talk) 16:15, 3 November 2017 (EDT)


 * If all subpages are themselves individual pages in the "Definition" category, then that should work surely? "note" subpages are in categories in a different namespace. Or am I missing something? --prime mover (talk) 20:07, 3 November 2017 (EDT)


 * Pages like Definition:Rational Number/Linguistic Note will also be counted. This is not a real definition. --Joe (talk) 23:10, 3 November 2017 (EDT)


 * But it's in the "Linguistic Notes" category, which is not a subcategory of Category:Definitions. This is what I'm trying to understand: is it possible to count all the pages in Category:Definitions and all its subcategories (excluding redirects)? Can something be set up that doesn't count the namespaces?


 * Here's a radical suggestion: like we have the qed template, select a symbol e.g. $\diamond$ or whatever the code is for a black one of them which can be used to signify the end of a definition, build a template with that and a category to put them all in like for qed, and then etc. etc. --prime mover (talk) 06:28, 4 November 2017 (EDT)


 * Okay, I see what you mean now. This should be pretty easy to scrape from the database. --Joe (talk) 10:56, 4 November 2017 (EDT)


 * So pages like Definition:(0,_1)-Matrix/Examples should not have a Definition category link? --Joe (talk) 18:55, 4 November 2017 (EDT)


 * Some of our structure may need to be tightened. There are some special cases like this which need to be thought about. Perhaps "examples" need to be removed from the Definitions category, or that we deliberately implement "Examples" categories which do not count, but then the "Rook Matrix" example should be a definition, and ... and... my brain hurts. --prime mover (talk) 19:12, 4 November 2017 (EDT)


 * Okay, well for now I won't worry about it and will just count definitions as you described above. --Joe (talk) 19:14, 4 November 2017 (EDT)

Subpages and the horror of refactoring
I've been working on an alternative for subpages: User:Barto/Sandbox/navigation. At least, for subpages except things like multiple (numbered) definitions, historical notes, multiple (numbered) proofs, ... Basically it's meant for the type of subpages that are commonly linked to (definitions, mostly).

Pros: Prevents using direct links to subpages, Page titles become neater, Refactoring easier (hierarchy is easily changed, we can even go to much deeper levels just by adding links)

Cons: The absence of slashes in the title makes the hierarchy less clear, despite the "navigation bar". In some cases the structure of the title (e.g. "Continuous Real Function at Point") still reflects the hierarchy: "Continuous/Real Function/at Point"


 * Another con: having to learn yet another page structure template, and one which is horribly non-intuitive, for no benefit. --prime mover (talk) 13:34, 27 October 2017 (EDT)

Thoughts? Probably some stylistic improvements can be made. --barto (talk) (contribs) 18:41, 25 October 2017 (EDT)


 * How's that for a big suggestion for a major refactoring task? :) Might be the last of its kind though. --barto (talk) (contribs) 19:00, 25 October 2017 (EDT)


 * I'm going to need a lot of convincing. There are going to be some pages with a big ugly blue box on them which looks shit, and it's going to mean a colossal amount of work to get it into that shape in the first place. So, I'm out. --prime mover (talk) 01:42, 26 October 2017 (EDT)


 * Some examples: Definition:O Notation/Big-O Notation/Real/Point could become Definition:Big-O Estimate of Real Function at Point and we could easily add another level "Asymptotic Notation" in the hierarchy, without making the page title longer. The theorems transcluded at Triangle Inequality (e.g. the reverse) could link back to that page, improving navigation.


 * We've already got Definition:Big-O Estimate for Real Function at Point so I really don't see what the point is. --prime mover (talk) 12:30, 26 October 2017 (EDT)


 * I don't mind doing the work. Style of the box can be changed to your liking.
 * If you want, I can test out an actual example, e.g. Triangle Inequality. --barto (talk) (contribs) 02:55, 26 October 2017 (EDT)

Made some stylistic changes, looks more intuitive now and fits within the color scheme: User:Barto/Sandbox/navigation. --barto (talk) (contribs) 05:54, 26 October 2017 (EDT)


 * Actually this is exactly how subpages work, and how the buildup of the backlink structure of subpages is set up. I don't see a need to improve upon this. Although the argument regarding the page titles is a fair one. (But who cares about the title anyway if there is a redirect? What we actually want is that the search functionality improves so that it becomes easier to find pages.)


 * As to refactoring, you are still going to transclude the subpages, and whether you do that with the redirect as the main page or not, the fact remains that they need to be changed. I am assuming here that a rename will also affect any and all subpages (which is ideally the case to ensure consistency). Therefore I struggle to see the benefit from this scheme.


 * It could be decided that we can improve upon the backlink structure by making it customisable, but then I would say we should invest into getting this a MediaWiki extension proper and not develop some hand-written workaround that sits beside the MediaWiki solution.


 * As to the labeled section transclusion extension mentioned, we had a look into it and it was deemed insufficient. Our own extension is supposed to fix this better but is not finished yet (the major problems with section headings and nested tags continue to exist; we might try to steal the syntax of LST, if it works them I'm all for it (although it is of course a bit against XML standards)).


 * But I'm open for hearing more arguments, and want to thank you for looking into it in any case! &mdash; Lord_Farin (talk) 06:54, 26 October 2017 (EDT)


 * Thanks for the feedback. Still, while there are redirects, it takes a few clicks to find them, which, apparently (and understandably), is too cumbersome for the average contributor.
 * As for refactoring, I don't think I understand "I am assuming here that a rename will also affect any and all subpages [...]" - the idea is to not use subpages anymore (except
 * I don't expect MediaWiki to create an extension for such navigation, as it is already possible with LST, I believe. I'd like to learn more about our own extension, although I don't think it is needed here. --barto (talk) (contribs) 07:24, 26 October 2017 (EDT)
 * Confirmed, LST suffices for the improved version: User:Barto/Sandbox/nav/2. --barto (talk) (contribs) 08:21, 26 October 2017 (EDT)


 * Well, regardless of whether it is a subpage or not, if we are transcluding onto Definition:Continuous Real Function the page Definition:Continuous Real Function at Point, then I assume that any rename of the former will naturally lead to a rename of the latter (by application of the same principle). Moreover, dropping this principle would open us up to losing consistency in naming (because the rename need not be consistently applied). But maybe you see this differently; if so I would like to hear an example.
 * As to LST, I was referring to its functionality as a whole, which makes the transclusion mechanism more flexible. We very much have a need for this with our deep transclusion practices (which can sometimes call for distinct subsections of pages to need transclusion, e.g. when transcluding to overview pages). This is where the need for our own, more versatile extension sprouted, see Help:ProofWiki Extension for how it works.
 * With regard to the extension I was mentioning, please be aware that it is perfectly possible to create a MediaWiki extension of your own. We don't have any dependency on MW here, I just imagined that it would help us if something like this would be included in the backli nk structure of subpages, instead of relying on a specific cumbersome application of LST, with the MW version sitting besides it to confuse the reader.
 * From a practical perspective, since the PW extension and LST both use the  tag, I fear there is a breaking incompatibility at work. &mdash; Lord_Farin (talk) 12:03, 26 October 2017 (EDT)


 * About the renaming: that's true, and the renaming job would be less efficient. But. :) It seems to me that most of the times such a page is renamed, it's either because (*) it has an ambiguous title or (*) something is wrong with the subpage hierarchy. What I want to say is, and I may be naive, I think a page with a title like Definition:Continuous Real Function at Point will never have to be renamed, with the hierarchy being independent of titles. (Okay, yes, there's always the possibility that someday a majority will prefer "Continuity of Real Function [...]". But hey, if we're talking about aesthetics, "Continuous Mapping/Real Function[/...]" isn't better :) In any case, "never" can safely be replaced by "much less often".) --barto (talk) (contribs) 13:52, 26 October 2017 (EDT)


 * It's only when someone decides to stride in and rename everything for reasons not completely understood that we have these renaming exercises in the first place.


 * As was established early on in the life of, there are multiple names for concepts, and different approaches that can be made. Having settled on one approach, and decided on a particular direction to come from, it was expected that this would be what it would be. It makes no sense at all just to arbitrarily rename and restructure everything. Yes, arbitrarily. --prime mover (talk) 16:12, 26 October 2017 (EDT)
 * I have worked out an example here to let you taste: Definition:N-Ary Operation Induced by Binary Operation.
 * It uses the ProofWiki transclude extension. You only have to give the title of the parent page.
 * Makes it very comfortable to restructure. No danger for links to subpages. --barto (talk) (contribs) 07:41, 27 October 2017 (EDT)

Okay so I've looked at Definition:Indexed Iterated Binary Operation, and I need to ask: do we really need to add all that stuff at the top of the page complete with all those "includeonly" and "noinclude" tabs and two "section" sections? Nope, no way.

Can you explain again why this is better than making Definition:Indexed Iterated Binary Operation a redirect to a structured hierarchical page in the manner fully supported by the MediaWiki software itself? --prime mover (talk) 09:46, 27 October 2017 (EDT)


 * I refer you to "Pros" in the beginning of the section, or the last line just above your comment. No need to repeat it. --barto (talk) (contribs) 10:01, 27 October 2017 (EDT)


 * Are those really pros?
 * "Prevents using direct links to subpages" -- that's not necessarily a pro, sometimes you might want to make a direct link to a subpage.
 * "Page titles become neater" -- what do you mean, "neater"? Clarity is always to be preferred over neatness -- and slash-separated page names make it completely clear what the hierarchy of page names is.
 * "hierarchy is easily changed" -- there's only one person here insistent on changing the hierarchy, and I for one do not want to make this easy, under any circumstances, for blindingly obvious reasons.


 * Now, can you find me some pros?


 * As for the heavy syntax, that's indeed unfortunate, and is probably the best reason not to implement it now. I'm planning to file a request at Phabricator to improve the functionality of LST, in a way that would allow to do this with a single template, as in  --barto (talk) (contribs) 10:06, 27 October 2017 (EDT)
 * Fun fact: the aspired version of LST would also allow to automatically populate, for each book, a page with links to all pages on ProofWiki where it is cited, in the same order as the results appear in the book. Without any changes to the wikitext (thanks to prev & next)). I.e. a detailed online version of it. --barto (talk) (contribs) 10:35, 27 October 2017 (EDT)

Nope, I can't live with it. Not at all. --prime mover (talk) 12:35, 27 October 2017 (EDT)


 * Some more cents: I agree with PM that the redirects take adequate care of the cry for "readable" page titles. I was thinking that the only thing that could sway me in favour of this mountain of work would be a solution to the issue that we might want the same page to be transcluded on more than one page (one of the things our extension addresses). But then if the hierarchy is still defined to have a single parent, we have no benefit over using the built-in subpage hierarchy.
 * If you manage to find a way to address that, then we might have something worthwhile that I would call a real "pro". Until then, I would call the suggested solution unpractical -- it would be more efficient to extend MW so that the displayed title can be one of the redirects to the page; such would solve the problem the same way, but without having to tamper with our existing pages in any way.
 * Again, thanks for your investigation, but it would just be too much work, and actually additional idiosyncrasy in the PW approach to MW as opposed to using the standard redirect functionality. I doubt this will increase usability for people... &mdash; Lord_Farin (talk) 12:58, 27 October 2017 (EDT)


 * "If you manage to find a way to address that" - I'm not sure here what you mean by "that", is it pages with multiple parents? The navigation template could allow that, yes (it could make recognize common ancestors and merge subtrees in one tree or whatever; design is not the problem).
 * It is already possible to change the displayed page title to whatever you want, see &#36;wgRestrictDisplayTitle. Note also "[...] it breaks the wiki convention that a page's title is its name, and thus can be used for linking to it.", a convention that PW already violates by disrecommending direct links to subpages. --barto (talk) (contribs) 13:37, 27 October 2017 (EDT)
 * Allthough I do think &#36;wgRestrictDisplayTitle=false is a good start. --barto (talk) (contribs) 13:41, 27 October 2017 (EDT)


 * I'm done arguing. --prime mover (talk) 13:40, 27 October 2017 (EDT)
 * arguing? brainstorming :) --barto (talk) (contribs) 13:48, 27 October 2017 (EDT)

The end of MathJax?
I just saw that the MathJax extension at MediaWiki has been archived: mediawikiwiki:extension:MathJax. Not sure what it implies. Are we using that extension or an independent one? --barto (talk) (contribs) 04:41, 27 October 2017 (EDT)
 * We're using that one with a few fixes. See https://github.com/ProofWiki/mediawiki-mathjax --Joe (talk) 12:19, 30 October 2017 (EDT)

Presenting generalizations, special cases
Hi, I've been experimenting a bit with how to mention generalizations and special cases on a page (definition page, mostly). See for example Definition:Summation/Finite Set: I created subsections in the "Also see" section, presenting a generalization as It is a somewhat terse style, but I like it, as it tells you everything you need to know, and I think it fits the general writing style on ProofWiki. Same for the reverse phenomenon, with links in both directions. Comments? Should the headings be level 4 instead of 3? --barto (talk) (contribs) 04:44, 31 October 2017 (EDT)
 * Definition:Generalization, as shown at Proof that it is a Generalization

What is a "Proof"?
In the process of deriving some results regarding a particular logic, I wrote up Definition:Constructed Semantics/Instance 1. Now I want to refactor the validations on Hilbert Proof System Instance 2 is Consistent into separate pages.

However I struggle to determine where to put it. By analogy I would create e.g. a new proof page at Rule of Idempotence/Disjunction/Formulation 2/Reverse Implication but this seems off as the system does not represent "truth" in the ordinary sense. On the other hand, in the future this kind of result might be useful to be collected and described separately (especially for things like specific Kripke models whose theory is fascinating on its own).

It's also not really belonging in an examples category because it is used in a proof. An option I thought of was a subpage structure below the definition, but this puts proofs in the definition namespace.

Any thoughts where I can place these results? &mdash; Lord_Farin (talk) 14:16, 5 November 2017 (EST)


 * I now placed them on subpages for progress' sake, but marked them as candidates for renaming. &mdash; Lord_Farin (talk) 12:20, 7 November 2017 (EST)

Enough
Right that's it, I'm off. This site can sink or swim. --prime mover (talk) 15:05, 5 November 2017 (EST)


 * Sad to hear that. I hope you'll be back soon, your contributions are invaluable. &mdash; Lord_Farin (talk) 15:16, 5 November 2017 (EST)

Category definition template
I created Template:Category definition in order to standardize the way categories are defined. Comments (template name, parameter names) ? --barto (talk) (contribs) 02:36, 7 November 2017 (EST)


 * I don't like the template name so much because it is a departure from the established pattern (no template in use has spaces, or lowercase words). Maybe "DefineCategory"? The verb should keep it distinguished from the MW brand of categories, which at best need to be described.
 * I like the names of the arguments (matching the way they are denoted in TeX) and the proposal to have a template for this – such will make life easier. &mdash; Lord_Farin (talk) 12:20, 7 November 2017 (EST)


 * "DefineCategory" is fine for me. I don't mind so much about capitalization for non-content pages; I've always thought the reasons for capitalization are that (1) it makes links to theorems stand out and (2) it makes the reader focus on the end of page title (often containing important words) and not just the beginning. Finally, to some it just looks better.
 * What I want to say is that (1) and (2) don't apply to templates and short page names (help pages etc), so that title-casing of non-content pages isn't that important to me. For templates, I'd even say it's better not to capitalize, as it makes typing the template name slightly more complicated. But I really don't care so much that I will insist; it's all invisible anyway. --barto (talk) (contribs) 13:33, 7 November 2017 (EST)


 * For page titles in general, you are right. It helps people to focus on the more important words in the page name (also at the top of a definition page). I think the main argument for templates and help pages is consistency with the other namespaces. The difference in effort is not so big and it avoids people wondering about the discrepancy.
 * Alternatively dash-separated lowercase words could be considered like with Template:Begin-eqn c.s. But ultimately it is just a minor thing that is not worth the time to discuss, let alone to go and change throughout. I'm more worried about descriptiveness. &mdash; Lord_Farin (talk) 13:49, 7 November 2017 (EST)


 * Agreed. I don't understand the sentence The verb should keep it distinguished from the MW brand of categories, which at best need to be described. , but both "category definition" and "define category" are fine for me, whitespace or not. --barto (talk) (contribs) 13:59, 7 November 2017 (EST)