Talk:Table of contents

From ArchWiki
Revision as of 09:55, 30 April 2012 by Kynikos (Talk | contribs) (Layout: rm closed discussion)

Jump to: navigation, search

ToC restructuring

I propose the following (major) changes to the ArchWiki category tree:

Removal of Category:Pages sorted by type (English)
Currently we distinguish between four types of articles: FAQs, General, Guidelines, and HOWTOs. I believe that the majority of FAQ articles should be merged into the main FAQ; the general category is not helpful in any way; almost all articles under guidelines deal with package management (see Category:Package development instead); and every article is a HOWTO in the sense that it explains how to install/configure/etc. something (further, ArchWiki is moving away from the HOWTO style of writing (step 1, step 2, step 3...))
Flattening of the tree
The Category:System administration and Category:Desktop user's guide (English) categories are unnecessary and confusing. Consider Desktop user's guide -> Category:Utilities (English) (utilities not used for system administration?) and System administration -> Software -> Category:Display managers (display managers not used by desktop users?) Similarly, the Category:Hardware (English) and Category:Software categories can easily be eliminated. Categories that relate specifically to hardware can be renamed (e.g. Hardware -> Category:Graphics can become Graphics hardware).
i18n standardization
Non-English categories should follow the naming scheme Title in English (Language). See Help:i18n for details. Template:i18n should be included on all category pages. Furthermore, all category titles should be appropriately capitalized (Like a Title).

Are there any objections? I will prepare an outline of my imagined category tree shortly.

-- pointone 20:20, 10 May 2011 (EDT)

+1 for all. :-) Unfortunately I don't have much time and will have even less. -- Karol 20:33, 10 May 2011 (EDT)
I'm in favour of points 1 and 3 but basically against the systematic flattening of the tree, but it's just a matter of taste, and we are 2 vs 1 here, so I'll just shut up now :D -- Kynikos 09:21, 11 May 2011 (EDT)
Phew! That was one mess of work! No longer do we distinguish between article topics and types. I will propose changes to the tree regarding (2) in detail before committing to anything. -- pointone 17:08, 10 June 2011 (EDT)
Very good job pointone, it has surely been worth the effort! -- Kynikos 10:24, 11 June 2011 (EDT)

Capitalization

[split from a previous discussion, now closed. -- Kynikos 16:48, 23 April 2012 (EDT)]

As I began sorting and standardizing the Spanish categories, I realized that many English categories have improper capitalization. These issues could probably more efficiently be dealt with simultaneously. --Emiralle 21:46, 10 September 2011 (EDT)

I can easily solve this one with my bot, although it's not urgent. -- Kynikos 16:48, 23 April 2012 (EDT)

"also in" links

Do you like seeing the "also in" links next to categories that have more than one parent? -- Kynikos 06:56, 1 March 2012 (EST)

Related discussion: Help talk:Style#Category pages - tree or otherwise? If we return to a tree structure, "also in" links would not exist. -- pointone 19:18, 13 March 2012 (EDT)
But maybe in that case displaying them would be even more important, as a means of detecting violations to the rule. -- Kynikos 08:27, 14 March 2012 (EDT)
Quite right. My vote is conditional upon the tree decision, then. If a tree structure is enforced, display it to detect violations. If we allow multiple categories, however, hide it to avoid clutter. -- pointone 13:04, 15 March 2012 (EDT)
Ah kk your position is perfectly clear. However I wouldn't consider the ToC only as a tool for end-users, I think it's also very useful for maintainers, in fact being able to spot multi-parent categories (be them allowed or not) gives a clearer idea of how the articles are structured.
Some ideas to reduce/avoid clutter:
(I'll probably implement this solution for the next update)
(for this option, place the mouse on the asterisk; we can use another symbol, like + ^ #  !)
-- Kynikos 07:06, 16 March 2012 (EDT)
The first idea is implemented currently with <small>. -- Kynikos 11:56, 18 March 2012 (EDT)

Poll

Display it
[vote with : ~~~~]
thestinger 00:48, 2 March 2012 (EST)
Skydiver 00:51, 2 March 2012 (EST)
Kynikos 05:09, 2 March 2012 (EST)
Don't display it
[vote with : ~~~~]
Fengchao 20:09, 1 March 2012 (EST)
pointone 19:18, 13 March 2012 (EDT)

"also in" translations

Currently only Spanish, French, Italian and Portuguese have a translated "also in" string for categories with more than one parent, all the others are using the English wording. Please request new translations here. -- Kynikos 05:59, 12 March 2012 (EDT)

Flattening of the tree

Move Networking and Development out

The further step I want to do is move Networking and Development out. Then software and system Administration can be merged by bot. So the structure will like:

  1. About Arch
  2. Hardware
  3. Software
  4. Networking
  5. Development
I got no objection here. So I will make the change in next few days. -- Fengchao 23:27, 23 April 2012 (EDT)
Done. -- Fengchao 00:59, 25 April 2012 (EDT)

Change Software category

Technically every article is about "software", even those inside "Hardware" (drivers are software): based on what would remain in "Software" we should see if "Software" can be renamed to a more specific title, what do you think? -- Kynikos 03:54, 20 April 2012 (EDT)

I think the Software category is almost just as generic as the top-level English category. It could apply to pretty much everything in the wiki, so I don't think there would be any harm in just getting rid of it (but I'm fine with it staying too). thestinger 19:50, 20 April 2012 (EDT)
Software is too generic and it contains too much contents even after Networking and Development is out which make the category hard to navigate. I plan to split pages mainly about up layer applications into Category:Applications. Then the pages left seems to be mainly about "System components" such as boot loader, kernel, deamon, init, package manager, ABS, Desktop environment, window manager and so on. We can check whether they fit well into Category:System Compontents. Right now I am starting to move Arch specific topic into Category:About Arch. -- Fengchao 00:00, 21 April 2012 (EDT)
Now Networking and Development become a top category of its own. The new proposal for next step here is:
Split pages in Category:Software and Category:System administration into 2 parts by their difficulty:
  • Category:Applications. It is the easy part. People with no Operation system knowledge can read them.
  • System Components. Pages there are more harder than Applications. To fully understand these pages, Operation system knowledge is needed. And after learning these pages, the reader will become a nerd of computer :).
The steps to take:
  1. Create a new category Category:Applications.
  2. Move pages fit in Category:Applications there.
  3. Move pages left in Category:Software into Category:System administration.
  4. Discuss whether Category:System administration should changed to other name such as Category:System Components.
-- Fengchao 01:34, 25 April 2012 (EDT)
It's an interesting approach, you can try it, the result will be better than the current situation in any case :) -- Kynikos 11:28, 25 April 2012 (EDT)
Ah, by the way I can handle step 3 with my bot, in case there are many articles left there, just ask me ;) -- Kynikos 04:39, 26 April 2012 (EDT)

Merge Category:Wiki Tools to Category:ArchWiki

There is only 3 articles in Category:Wiki Tools and all of the are ArchWiki related. Could we merge it to Category:ArchWiki? -- Fengchao 05:04, 22 April 2012 (EDT)

Well, Emacs Mediawiki and Wiki Monkey are not strictly related to ArchWiki (ArchDocumentalist is indeed), maybe those articles may be categorized also under Category:ArchWiki, but Category:Wiki Tools (without ArchDocumentalist) could be moved (or merged) to Category:Software. -- Kynikos 06:13, 23 April 2012 (EDT)
However there's at least one big distinguishing feature between the articles currently in Category:ArchWiki and those in Category:Wiki Tools: the former are tools (articles) that do reside on the wiki; the latter are external tools; I don't know if mixing them is very constructive. -- Kynikos 06:20, 23 April 2012 (EDT)
ArchDocumentalist should belong under Category:ArchWiki; the others should be categorized like Mediawiki et al (under Category:Web Server at the moment). -- pointone 11:18, 23 April 2012 (EDT)
The fact is that Mediawiki is indeed run on a web server, Emacs Mediawiki and Wiki Monkey are not: they may fit Category:Internet Applications much better IMHO, also taking into account that Emacs MediaWiki is already under Category:Text editors. -- Kynikos 16:41, 23 April 2012 (EDT)
I am convinced that Category:Wiki Tools should not merged to Category:ArchWiki. And +1 to make it a sub category of Category:Internet Applications. -- Fengchao 22:44, 23 April 2012 (EDT)
I know I'm in a conflict of interests being the developer of Wiki Monkey, and my thought may not be objective in this case, so please ignore it if you think so :P Anyway, I didn't mean to make Category:Wiki Tools a sub-category of Category:Internet Applications; I was thinking more of categorizing each of its 3 members directly under existing categories:
Then, still in my opinion, the 3 articles could stay also in Category:Wiki Tools, which should be categorized only under Category:ArchWiki.
-- Kynikos 11:49, 25 April 2012 (EDT)
Imaging there is a user looking for an Arch Wiki download tool. When looking at this table of content, what categroy will he first click ? Category:ArchWiki will definitely have more chance than Category:Scripts or Category:Internet Applications. So let us re category the pages to make them more easy to find for normal user.
Yes, right now Category:ArchWiki only contain pages reside on the wiki, but the general name can not keep other pages out.
-- Fengchao 04:58, 27 April 2012 (UTC)
Perfect, I've completed the job so we can close this discussion I guess. -- Kynikos 13:55, 27 April 2012 (UTC)