Talk:Table of contents

From ArchWiki
Revision as of 08:39, 26 April 2012 by Kynikos (Talk | contribs) (Change Software category: clar.)

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)

English Category Names: Capitalization and Conflict with i18n

Regarding point 3, for i18n to link to english categories, all would have to be renamed: "Name of Category (English)" -> "Name of Category". For example: Category:System administration (Español). Unless I'm missing something. --Emiralle 19:14, 10 September 2011 (EDT)

Definitely, because of how Template:i18n is done atm, English categories can't have the (English) suffix, unless we exploit the 2nd optional argument available, which is used only by the English link (I don't even know why it was made that way): {{i18n|:Category:About Arch|:Category:About Arch (English)}}. -- Kynikos 06:47, 12 September 2011 (EDT)
I agree that we should follow the article naming conventions for category titles (for English, Name of Category, with no language tag). I can move them all very easily with my bot if we decide to rename them. thestinger 17:18, 12 September 2011 (EDT)
+1 for me. I guess pointone would agree too, since he's been the first to propose i18n on all categories, and removing _(English) is a necessary step for doing that. The only opposition I can think of, is the unknown-to-me reason why English categories were named with the suffix, if any reason was there at all. -- Kynikos 04:53, 13 September 2011 (EDT)
This might be the reason that it started. However, I think that was before the nice i18n template, which would serve the same purpose now. thestinger 09:08, 13 September 2011 (EDT)
Yes, I don't like multi-language categories, I'm sure that if the Help link in the navigation pane points to Category:ArchWiki Help (English) with the i18n template it will be perfectly fine, and even better-looking.
There's another problem though, Category:Help contains also ArchWiki:Administrators, would it be moved to ArchWiki Help? The fact is that either that page is categorized in every ArchWiki Help (Language) or it will be visible only to English users.
-- Kynikos 07:17, 14 September 2011 (EDT)
I am stating to Move Category: Hardware out of "System administration" and change the name from "Name of Category (English)" -> "Name of Category". -- Fengchao 01:10, 18 April 2012 (EDT)
Thanks for your hard work, but you'd better not waste time on removing the _(English) suffix manually, that can be done very easily with a bot (e.g. Wiki Monkey) ;) -- Kynikos 08:16, 18 April 2012 (EDT)
Ah, btw there's not even need to update Table of Contents manually, just ask for an update on User talk:Kynikos.bot although I'm updating the table once a week and IMO it's frequent enough. -- Kynikos 10:17, 18 April 2012 (EDT)
Nice script. I just add i18n link to all Category:Software and we can change Category:Software to Category:Software -- Fengchao 01:38, 19 April 2012 (EDT)
Kk, however I'll start from the top of the tree and go down category by category, so I don't get lost. -- Kynikos 07:03, 19 April 2012 (EDT)
You know what, I could relatively easily implement an algorithm for removing the suffix recursively from all the categories, and I think overall it would save even more time, so I'm scheduling it among the upcoming updates to Wiki Monkey ;) -- Kynikos 09:30, 19 April 2012 (EDT)
Great. I will focus on re-structure task only. And leave the rename job to the bot. -- Fengchao 22:33, 19 April 2012 (EDT)
The script is ready and I've tested it successfully on Category:Input devices (English). What it does, for each category with the English suffix, is:
  1. Create the category without the suffix
  2. Recategorize the members of the old category (both pages and subcategories)
  3. Check the number of members in the new category corresponds with the previous one
  4. Update all the backlinks of the old category (except for pages in User and User_talk namespaces)
  5. Delete the old category
The bot is set to do 1 edit every 8 seconds (not counting http requests and generic calculation times), so it may take some hours to complete the job. I will unleash it soon, but note that it's vulnerable to some edits that could be done manually while it's working:
  • Creation of a category "Foo Bar" when there's already a category named "Foo Bar (English)": the bot will stop at step 1, however it should be possible to restart it without problems, but would require manual checking which implies waste of time
  • Categorization of a page inside a category with the English suffix: the bot will stop at step 3, however it should be possible to restart it without problems, but would require manual checking which implies waste of time
  • Removal of a page from a category with the English suffix: the bot will stop at step 3, however it should be possible to restart it without problems, but would require manual checking which implies waste of time
  • Deletion of a category with the English suffix: the bot will stop at step 5, however it should be possible to restart it without problems, but would require manual checking which implies waste of time
  • Creation of a new category with the English suffix: stupid case added for completeness' sake, but the bot won't rename the category
Instead, the following edits are supported even while the bot is running:
  • Change links to categories ([[:Category:Title]])
  • Categorize a page inside a category whose name doesn't have the English suffix
  • Remove a page from a category whose name doesn't have the English suffix
  • Edit the text of a category page
  • All edits not related with categories and categorization
If in doubt, please ask here before performing a possibly conflicting edit.
-- Kynikos 15:43, 21 April 2012 (EDT)
I'm starting the bot in the next minutes, please avoid the edits listed above, thanks. -- Kynikos 06:51, 23 April 2012 (EDT)
Finished, everything should be all right. Closed. -- Kynikos 16:24, 23 April 2012 (EDT)

Layout

The layout of the ToC can be changed relatively easily, please share your opinions. -- Kynikos 06:56, 1 March 2012 (EST)

Update: now language suffixes are removed automatically, and the English table uses an unordered list (I've kept numbered lists for the other languages just for comparison, still waiting for more votes). -- Kynikos 13:11, 11 March 2012 (EDT)

numbered list vs. bulleted list

I propose to replace numbered list whth old bulleted list. I find the numbered list appears a little confusing. It cannot show the levels of categories clearly. A slightly better way is to use way like 1, 1.2, 1.2.3 (as in contents of articles). But I think the best way is using bulleted list, which is more fit with Arch's way of simplicity.

--Skydiver 00:36, 29 February 2012 (EST)

An argument in favour of the numbered list is that it makes it easier to see where is the next sibling of a category with lots of children, since they have subsequent indexes (see for example Category:Software and Category:System recovery in the current table. -- Kynikos 05:09, 2 March 2012 (EST)
I like Skydiver's suggestion, and would vote for the sub-numbering system if it were possible. -- pointone 19:16, 13 March 2012 (EDT)
Well yes it'd be possible (the indices should be hardcoded instead of using # or *), but the result would be something like this:
7. System administration (1)
7.1. Accessibility (6)
7.2. Audio/Video (91)
7.3. Development (63)
7.3.1. Arch development (48) (also in About Arch)
7.3.1.1. Licenses (25)
7.3.1.2. Package development (59) (also in Package management)
7.3.1.3. Pacman development (6)
It looks a bit bloated to me, but of course there's no accounting for taste :) I've taken the liberty to move your vote to a new choice in the poll.
-- Kynikos 06:29, 14 March 2012 (EDT)
To avoid clutter we can 1) flatten the tree somewhat as I have proposed above (and will continue with, once I can find some time...) and 2) limit the ToC display to 3 levels maximum. -- pointone 13:11, 15 March 2012 (EDT)
1) You know I have some reserves about an indiscriminate flattening, however for example Software and Hardware could easily be made direct children of English, and System administration could probably be merged almost entirely with Software (we'd decrease the level of many categories by 1 this way); to sum up, I'd like to discuss possible flattening strategies case by case
2) As I've written in #"also in" links, for me the ToC has mainly a maintenance purpose, so I'm against hiding content only for the sake of aesthetics ^^; IMO if we want to limit the depth of the tree in the ToC, it should be only the consequence of enforcing a rule to limit the depth in the actual category tree.
-- Kynikos 08:20, 16 March 2012 (EDT)
The sub-numbered list is implemented since it had 2 admin votes and it was a 2nd choice for me and Skydiver :) Also note the use of <small>. Currently only English uses it until we find a stable solution. Feedback welcome. -- Kynikos 11:55, 18 March 2012 (EDT)
One annoying bug is that links in definition lists lose the bold font weight, I'd like to submit a bug for that... Those who use Firebug or similar, just try to add dd a {font-weight:bold;} to the style sheet and see how it looks much better. -- Kynikos 15:39, 18 March 2012 (EDT)
Of course a temporary workaround can be adding a left margin or padding to the first <small> tag of each item in place of the colons (entries must be separated with blank lines). -- Kynikos 07:01, 19 March 2012 (EDT)
I never meant to suggest indiscriminate flattening -- my primary concerns were with categories Software, Hardware, System administration, and Desktop user's guide. The latter has since been removed, and I agree with decreasing the levels of Software and Hardware and reorganizing System administration. I don't think we need to enforce a limit... let's see how it looks once this "flattening" is done. -- pointone 23:05, 19 March 2012 (EDT)
Uh sorry for misunderstanding, I thought your idea was to move almost all categories to first level ^^'
Just to make it clear, I'm against the limit too, I mentioned it just as an option.
What about the other formatting problems? Do you like the use of <small>? Would you support a feature request for using bold also for links in definition lists?
-- Kynikos 08:41, 20 March 2012 (EDT)
I see this as a bug, actually -- link formatting should be consistent throughout! The current formatting with small looks great, otherwise. -- pointone 10:08, 20 March 2012 (EDT)
Opened a bug report then: FS#29021. Please vote. -- Kynikos 17:31, 20 March 2012 (EDT)
Poll is closed, once FS#29021 is fixed, all ToCs will switch to sub-numbering. -- Kynikos 07:17, 19 April 2012 (EDT)

Page count or not

Do you like seeing the page count for each category or not? -- Kynikos 06:56, 1 March 2012 (EST)

Poll is closed, page count is already displayed and that's definitive. -- Kynikos 10:52, 25 April 2012 (EDT)

Poll

Display it
thestinger 00:43, 2 March 2012 (EST)
Skydiver 00:51, 2 March 2012 (EST)
pointone 19:16, 13 March 2012 (EDT)
Fengchao 20:05, 1 March 2012 (EST)
Don't display it

"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 Software and Hardware out of system administration

This process seems stalled now. So let me fill in some fuel. :) Imaging we are writing a book and thinking about how should a book's TOC looks like. We can immediately find out the largest problem now is:

"7.System administration" is toooooo large.

My idea here is takeing a small step at a time. The first step is move Software and Hardware to First level. Then we can discuss other changes case by case. Any objections ?

-- Fengchao 02:00, 17 April 2012 (EDT)

That step has already been admin-approved somewhere else in this talk page, probably even more than once :P We're just lacking the time to do it, so it's a very welcome thing if you want to do it :) -- Kynikos 08:18, 17 April 2012 (EDT)
Done. -- Fengchao 23:27, 23 April 2012 (EDT)

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)

Separate Arch specific topic from more general topic

Now Software and hardware is moving out. The next step I want to take is move Arch specific topic into Category:About Arch. Including:

  • ArchWiki
  • FAQs
  • Getting and installing Arch
  • Live Arch systems
  • Website Resources
  • Wiki Tools

All articles in Archwiki should be related to Arch. But some of them only apply to Arch while others can be very useful for users of other distributions.

  • Grouping Arch specific topic together,an Arch user can find info more easily.
  • At the same time, other pages are more general, the info there can be used by non-Arch users with little adjustment, as little as using a different package management tool.
  • This step may not fit into "Flattening of the tree", but once it is done. We can move more category out of "Category : System administration" without mixing up the Tree.
  • In my vision, "Category : System administration" may end up become "Category : Arch system maintenance" with Arch specific maintenance info.

Any objections ? -- Fengchao 03:03, 19 April 2012 (EDT)

I admit it sounds like a good idea indeed.
  1. One question could be about Category:FAQs, which contains TeX Live FAQ: if you want to put that category inside Category:About Arch, would you leave TeX Live FAQ only in Category:TeX? (not necessarily a bad thing, I'm just asking).
  2. About the possible Category:Arch System Maintenance, would you put it inside Category:About Arch?
  3. I can move the members of Category:System administration to Category:Software with the bot (merging the 2 categories), are you interested?
In any case this is a big reorganization, I'd wait for more opinions before putting it into practice.
-- Kynikos 18:13, 19 April 2012 (EDT)
For 1. Sure. It is already done.
For 2. Yes
For 3. Automation can save me a lot of time.
Done. Some left over category will be discussed case by case. -- Fengchao 23:27, 23 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)