Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
While the nLab is down (edit: now back up), maybe I should use the time to finally say the following, since it already came up elsewhere.
As of recently, Andrew Stacey has handed back the tenant-ship of the Lab server to me and is withdrawing from administering the Lab software installation. From now on Adeel Khan Yusufzai is kindly offering help with/is taking care of whatever it takes to administer the server. I hope the workload will be light.
So, there will be no need for a major migration (in terms of software changes) ? Good, if so.
I hope the workload will be light.
I do too. Many thanks to Adeel for taking this on!
Zoran: well, having to restart the server every couple days is not that fun. We are slowly working on setting up a MediaWiki version of the nLab so we can see how that compares.
I once had access to restart the server, but it was an unusual log-in system (not password-based) and I lost the codes that gave me access. If I got access again, then I could help with the restarting instead of only posting complaints.
Adeel, can you elaborate a bit on the mediawiki plans? There were a number of discussions before. Also, PlanetMath and WorkingWiki were considered.
FWIW, I would be very unhappy at having to use Mediawiki markup syntax on the nLab; I find instiki’s syntax infinitely easier to use.
Is that a countable or an uncountable infinity? (^_^)
I also prefer Markdown to MediaWiki, although it's not a big deal; but I definitely prefer Itex to texvc.
Currently we have a migration script that takes an Instiki installation and sets up a MediaWiki installation with the same pages. We decided to stick with iTeX, so the actual math code is not being converted, but the rest of the Instiki syntax is. This script has been mostly complete for a while, but as you can imagine there are some loose ends that need to be dealt with, which I have been postponing for a while. We are in discussions with Lee Worden, the author of WorkingWiki, and is likely that we may take advantage of his software as well (which is basically an add-on to MediaWiki).
Mike, I don’t know if you mean just the math syntax or you mean everything else as well. In the latter case, I can’t imagine it would take too long to get used to the MediaWiki syntax, and I hope everyone would agree it would be worth it if it resolves the other issues we are having with Instiki.
Everything else as well. Getting used to it is not the question, I’ve used mediawiki for other projects; I just don’t like it. It’s ugly as heck for one thing.
If we have clear tests showing that MediaWiki will resolve issues that we have, then migration is probably worth it, especially since we can keep Itex. This would mean, at minimum, side-by-side installations of both platforms with the same content, in which the Instiki one shows our problems and the MediaWiki one does not. But if switching to MediaWiki doesn't solve our problems, then I wouldn't want to do it, even keeping Itex.
There appear to be some mediawiki extensions that enable Markdown parsing; maybe we could try some of them?
Is the mediawiki itex going to generate mathml or use mathjax? In addition to the itex input syntax, one of the things I like a lot about instiki is that it generates mathml directly for browsers that understand it, so one doesn’t need to wait forever for mathjax to render a page while it messes up all the scrolling.
Another problem with mediawiki is that its redirect facility is pretty broken. I didn’t realize this until Jacques implemented a non-broken redirect facility for instiki, but the difference is really huge. AFAIK with mediawiki you have to create a separate page for each redirecting name containing a “redirects to” command, whereas with instiki you simply put commands on the page being redirected to that say all of the different names that should redirect to it. When we have one page that is redirected to by 20-30 different names, obtained by all possible combinations of pluralizations and variations in terminology, I think it’s much easier to manage when we have all the redirects in one place.
@12: I’ll try to implement your request about the “linked from” section. I don’t completely agree with your diagnosis of the Instiki issues, but I would have to do an audit of the code to say for certain where the performance problems are. I’m willing to do that in case the MediaWiki test doesn’t give positive results.
@13: I agree completely. I should stress that the MediaWiki experiment is just that, an experiment, unless we see significant improvement in performance.
@14: There is various software designed specifically for the purpose of running such tests.
@15: I tried one at some point with not much success, but I’ll look into it again. The iTeX will be converted to MathML, which will be rendered by the browser or otherwise by MathJax. Regarding the redirect function, I would say it’s Instiki’s redirect function which is broken: there are multiple instances of nLab pages which both “want to be redirected” from the same thing. In these cases the software makes an arbitrary decision about which one gets the redirect. Also, the majority of redirects are for plural forms, which in MediaWiki are usually not necessary, due to the possibility of writing e.g.
[[scheme]]s
Sure, this doesn’t always work, but I wouldn’t say the system is “broken”. Wikipedia hasn’t had any problem with it, for example.
Yes, thanks Mike, MathML is also important to me.
I think that neither Instiki nor MediaWiki do redirects sensibly, so what do y'all think of that! (^_^)
the majority of redirects are for plural forms
This is not true; the plural forms are the least important and I personally use them almost never (and list them just because of peer pressure as I was criticised by Urs and others for not creating some plural aliases in old days of Lab). Majority of redirects is about various spellings of names (including Witten vs. E. Witten vs. Edward Witten), abbreviated vs. very long versions (cf. scheme vs. algebraic scheme, or look at long list of versions for BV formalism/theory, BV-BRST etc. nonabbreviated etc)) and the entries which unify temporarily or permanently close-by entries or topics. For example, Urs was recently suggessting on having absolute value and valuation in the same entry (some, including me were opposing this, but never mind). There are also redirects to some abandoned earlier titles of the page in the history, not to loose the external links. These are all quite essential uses and we have spent huge amount of time (esp. Toby) to properly keep track of all these issues. One should also think of external links which already link to Lab and crosslinkings with personal labs.
I do not think it is a good approach to neglect issues as “minority of cases” and alike qualifications. It is better first to analyze the logical and semantical structure of what we have or tended to build in last several years and then to see what can be possibly changed. Thank you for your kind effort, but please be aware of the rich semantic structure beyond the mere existence of links and iTeX.
The redirects will continue to work as they are now, if that is your concern.
will continue to work as they are now
So, can you include all the redirect commands in the same page or not ? I mean do you mean just from the point of view of viewer or the creator or the page as well ?
Yes, thanks Mike, MathML is also important to me.
For me that is important only when I am (with my laptop) on an expensive and slow mobile network what is quite often (in fact this is the only choice at least all my weekends).
No, I mean that readers of the nLab won’t see any difference. Your post #18 seemed to be worried that only plural redirects would continue to work.
Your post #18 seemed to be worried that only plural redirects would continue to work.
My concern is that the standard job of creator of Lab includes quick creation and changes in the structure of various links, not only plurals (what can maybe be automated, hence skipped if well done, in future), and one likes to have control and overview of them from a single page (surely not that important if the same page where the text is, but for all redirects a single place to compare and edit, copy and paste with simple variations etc.).
I just found the following MediaWiki extension which seems to replicate the redirect behaviour of Instiki: http://m.mediawiki.org/wiki/Extension:IndexFunction. It also seems not to be “broken” in the sense I mentioned above:
Multiple pages can share the same indexes, instead of redirecting to the page, the titles will redirect to an automatically generated disambiguation page.
I would be happy to install this extension.
Excellent! If we can install the IndexFunction extension and also one of the Markdown extensions, then most (maybe all) of my objections to mediawiki would disappear.
If we do move to mediawiki, we would also have the possibility to experiment with its more powerful templating/inclusion capabilities, and maybe even the semantic mediawiki extensions.
I guess, we could also start using bots, i.e. one for generating and correcting citations. Of course, we have to be careful not to let it be too eager.
For more semantics approaches planetmath may be better, but I have not looked at the details carefully. Mike did you have specific semantic mediawiki extensions in mind?
I should note that Jacques has already (!) addressed the problem with the redirect function I mentioned (#16). Now that I’ve applied the latest update, there is a small disambiguation notice on affected pages: see for example presheaf category, projective spaces, 1-type, univalent foundations.
Re #12: I’ve just removed the linked from area for now. If somebody complains I’ll add a link to generate it on request, as Zoran suggested.
Great, thanx!
I like having linked-from, but it's not that useful, because what we really need is one that also counts links to redirects (as MediaWiki's does).
Re #26, I recall some discussion of a “database of categories” a while ago that I thought could be maintained better using semantic-wiki info on nLab pages.
Re #27, Jacques’ ability to fix things on request is certainly one advantage of instiki.
Mike, it could have been this one. Discussion started with a database for counterexamples in topology combined with ATP.
Re #27, Jacques’ ability to fix things on request is certainly one advantage of instiki.
Instiki is in version 0.19.7, so with such a programmer behind the scene, much more is expected in future…
1 to 33 of 33