User talk:Vladimir Panteleev
Hello! I've started toying around with Semantic now and it seems great! One thing I realised is that we really need Semantic Forms. For two reasons:
- Adding "things" gets sane. As some properties only have an enumerated set of values, it's almost impossible for users to know which values are valid, and they are bound to enter invalid values, which are just ignored. With forms it's clear.
- We get the #arraymap template which is needed to add several properties of the same type through templates. (Ie more than one Author etc.) It's still possible using "plain" property declarations, but it's confusing for users, and will likely be used the wrong way. (Ie we get an author with the name "Name 1, Name 2", instead of two authors "Name 1" and "Name 2".)
I also checked and more or less all those websites that use Semantic also use Semantic Forms, it seems to be a key component, and I think I can start seeing why.
I understand and respect if you're busy or reluctant to adding stuff, of course. Allow me to reassure though, this one thing seems quite essential, at least to me.
- Sounds good, installed. --Vladimir Panteleev (talk) 01:10, 27 November 2012 (CET)
Multi-dimensional hierarchies - Semantic Wiki
I've looked some more into this, and I've come across Semantic_MediaWiki. I'm still researching this, but my initial impression is that this would Solve-All-Our-Problems™. What I really like is that it solves the problem of keeping data in one place and present views into it "proper", by introducing a layer of data on the wiki that is more database-like and queryable. It also seems well-established and used.
Some example sites using Semantic Wiki:
wiki.mozilla.org also uses it, but they don't seem to make use of the features that much. Good for reference though.
Another good thing is Form Templates, which seems nice for users and would increase the chances of correct data input. Here's an example form template in action. (A bit too long, but one can get a feel for it.)
Another thing that's nice is the query-based search feature, here's an example (Never mind the annoying yellow bg and overpopulated tag clouds.) One can certainly imagine having things like tutorials for "Beginners", "Intermediate" etc. as well as "Graphics", "Networking" etc. Nice.
It also seems to provide good presentation features, should one want to, like map, calender etc. But that's overkill for now imho.
What do you think? At the moment it feels like overkill, but imagine if this wiki grows, then things like this would certainly be very useful? And if we want it in the future, it's probably good to set it up early. Still, I'm not sure yet. Just sharing my thoughts.
- Looks like a cool project! Installed. --Vladimir Panteleev (talk) 02:40, 26 November 2012 (CET)
I'm looking at moving over the DIPs but I think we need subpages in order to do it properly http://www.mediawiki.org/wiki/Help:Subpages It would be used to keep the DIP Archive and DIP Alternatives as on ProWiki. At least the WikiMeda help says that's a good use for subpages too. Seems without subpages we have to change the DIP process itself (See "Usage" in DIP1) which could get political?
Could we turn it on for the main namespace, or perhaps now is good time to actually create a DIP-namespace (Or "Dev"?) and have it turned on just there?
- Am I right that all this feature does is generate a link to the "parent" page (page with the title up to the last slash)?
- For another wiki, we've simply used a template for that. It also has the advantage that a page can have multiple "parents", and does not clutter URLs. Example: http://worms2d.info/Software
- I'm not against enabling the feature, just making sure this is what you want. Let me know if I should go ahead and enable it. --Vladimir Panteleev (talk) 16:26, 24 November 2012 (CET)
- Ha, yeah, I think you're right. Man, I'm learning a lot : ) Sorry for bugging you. I say we just keep it as it is for now, we can still use "/" in names to express the intention of a subpage, and then later if the link to the parent page is needed, we can activate it then perhaps, through a template or whatever seems best. --Kraybit (talk) 16:34, 24 November 2012 (CET)
Here's a problem: It would be nice to have a page with all projects that are D-related, open source, proprietary, experimental, stable—everything! Then, it would also be very nice to be able to list a subset of those projects, only those that are "stable", "open source" and so on. Do you know of any way to achieve this without duplicating entries? --Kraybit (talk) 16:52, 24 November 2012 (CET)
- So we're looking for a table or article list that allows dynamic filtering?
- I think this could be achieved using a template which takes one parameter for each criteria. It would emit a table with one entry per row; however, each row is wrapped in a conditional which checks for the appropriate conditions.
- Perhaps these extensions could be useful as well: 1 2 3 --Vladimir Panteleev (talk) 17:00, 24 November 2012 (CET)
- Aaah, templates, ok, now I get it : )
- Your idea sounds great! Hm, I must admit, I can't really tell if these extension would accomplish that though. My impression:
- CategorySearch — With this every project must have a page (which is perhaps not bad?), so it seems excessive, yet!, for thinks like the Cookbook that seems to be great! We could then show lists of howto's/guides etc. by a query of categories, like all howtos in "Meta programming" and "Beginner". (Or? Is this just a search-widget, or can we embed queries in a page and get a table? At least then users could do a meaningful search.)
- DynamicPageList — Again for projects every projects must have their own page — yet! — this could be great for showing a list of the "5 latest tutorials" or "5 latest projects" etc., so again this seems very useful!
- TemplateTable — I can't quite grasp this one. While it creates tables, I don't see any possibility to filter by criteria?
- It feels like perhaps we need to just give every project a page of their own so that we can put it in a category, and that way be able to show different lists, somehow. Again, I must admit I can't see clearly how all this would work. Perhaps some more research into this is a good idea?
- --Kraybit (talk) 17:51, 24 November 2012 (CET)
- Well, let me know what you decide. We shouldn't install extensions we don't need, as it pointlessly increases the amount of maintenance work, increases the attack surface, and creates the risk of getting us stuck at an old MediaWiki version if an extension we rely on stops receiving compatibility updates. --Vladimir Panteleev (talk) 17:56, 24 November 2012 (CET)
- Aren't they almost identical? I recreated ours from the dlang.org logo before I noticed I was just duplicating the old wiki's one. --Vladimir Panteleev (talk) 03:14, 11 December 2012 (CET)
FYI today I noticed in Special:RecentChanges that there are several new users with suspicious-looking user pages. You may want to keep watch on new users and perhaps install some kind of CAPTCHA mechanism to prevent abuse of the wiki.—Quickfur (talk) 23:02, 16 December 2012 (CET)
- Sign of progress ;) Our wiki is no longer completely obscure. I've purposefully delayed enabling any anti-spam measures until its first appearance to avoid hampering initial contributors. I've enabled them now. --Vladimir Panteleev (talk) 01:51, 17 December 2012 (CET)
Enable setting DISPLAYTITLE
It would be nice if we could set the DISPLAYTITLE to any value as described here: http://www.mediawiki.org/wiki/Manual:$wgRestrictDisplayTitle
- Would enabling subpages (the MediaWiki feature) be a better option? --Vladimir Panteleev (talk) 21:59, 21 July 2013 (CEST)
- As far as I know the subpage feature unfortunately doesn't change the page title at all, it only inserts the backlinks automatically. It would really be the best solution if we could somehow make this work for all subpages automatically, but that probably means editing mediawiki source code. Johannes Pfau (talk)
I wonder whether Portals ( http://www.mediawiki.org/wiki/Portals ) would be useful. At least the main page, DMD, LDC and GDC could use it. We could also add Portals for special architectures (x86 / arm / ), OS (linux, windows, ...) or devices NintendoDS / ...
However, Portals seem to be difficult to install on the wiki so I wonder if it's worth doing.
- I'm not really sure what the goal is. What are portals (from a technical perspective - e.g. how are they different from normal pages or categories), and how would they help us? --Vladimir Panteleev (talk) 22:00, 21 July 2013 (CEST)
- They are overview pages. A portal is an entry point for a specific topic the wiki similar to the main page. Kinda like a main page for this specific topic. We could of course also use the table based layout from the main page for these pages so I'm really not sure if portal pages are worth the trouble. The technical difference is that portals do not use table based layouts, css styling is more flexible(that's not really important for us..), it's possible to have a box displaying a random subpage/article, the content of the 'boxes' is stored in subpages and the source code for the portal pages is supposed to be easier to read/write. The goal is to have overview/entry pages for specific topics so that we can spread links to those. For example if we had a D port on NintendoDS, we could advertise the wiki.dlang.org/NintendoDS link in the DS homebrew community. wiki.dlang.org/NintendoDS would then be an overview page similar to the main page with links for setting up an IDE, supported compilers, tutorials, FAQs, ... all Nintendo DS specific. --Johannes Pfau (talk)
- Aside from creating a specialized namespace (which simply gives you a ":" in the URL), here is nothing magical about portals. All those features (table-based layouts, random articles, subpage templates) can be done as with any other MediaWiki page. So, I'm not really sure what you're asking. --Vladimir Panteleev (talk) 11:52, 24 July 2013 (CEST)