Discussion Hints

Carthik 17:46, 29 Aug 2004 (UTC) Please create a horizontal rule between comments by using four dashes ---- between entries.

Carthik 07:33, 27 Aug 2004 (UTC) Adding ~~~~adds your "signature" with a time-stamp which is very useful for discussion pages. An alternative is to click on the signature icon at the top of the edit window...it's the second one from the right, which has the same effect. :)

No CamelCase

THIS DISCUSSION TOPIC IS CLOSED.

Could you explain why you don't want camel case as the format for your wiki pages? That's [camel case] one of the most basic and fundamental parts of a wiki, so my initial reaction to your variance from the norm is. . . well. . . a serious questioning of why. So maybe explaining why your wiki won't follow the standard format would help reduce the resistance to change.

---

Same here. I am too puzzled about the decision of not using CamelCase. I mean, it is the simplest more efficient way to linking and creating pages. It makes the wiki a wiki.

---

skippy: see here: http://en.wikipedia.org/wiki/Wikipedia:CamelCase_and_Wikipedia

So, in other words, because it is prone to abuse and missuse. Makes sense. WordPress Wiki is not an encyclopedia per se, but Clifford logic is well founded.

---

--NuclearMoose 08:49, 27 Aug 2004 (UTC) My personal opinion is that camel case is not good for those whose first language may not be English. I think it can be confusing, and it's messy. As far as being a wiki standard, I think that the wiki concept is still relatively knew to most people. Since more non-wiki-fluent people will visit this site, I think it should be tailored to the user experience and we should not worry so much about the "difficulty" of creating a page called New Features instead of NewFeatures.

---

--Rob Mientjes 16:39, 27 Aug 2004 (UTC) Yeah, but it should still be clear that you just can't 'just do something'. There have to be clear rules, and someone has to decide. Too bad for him.

---

--NuclearMoose 07:41, 28 Aug 2004 (UTC) "Too bad for him"? This kind of comment needs an explanation or needs to not be published.

---

--Rob Mientjes 23:45, 28 Aug 2004 (UTC) Look, I just mean that it's hard to make a choice, since we are also trying to find the best solution. So it's too bad for him to make a choice - it's a hard choice. At least it's an important choice. Please don't get me wrong on this.

---

--NuclearMoose 01:58, 29 Aug 2004 (UTC) Rob, sorry for sounding all bent out of shape. I just wasn't sure what you were getting at! :) Now that I understand, your comment makes perfect sense. LOL.

---

We're following the Wikipedia guidelines here, no CamelCase, and that's my FinalAnswer. --matt

---

Sub pages

THIS DISCUSSION TOPIC IS OPEN

Can we make an exception on the sub pages rule for template tags, and the Usermanual. I think the problem with subpages on the other wikis may not be a problem for us, and it may be an advantage, too. It will create a nice URI structure. Or maybe we could use categories, like those at http://en.wikipedia.org/w/wiki.phtml?title=Special:Categories

---

--NuclearMoose 22:24, 29 Aug 2004 (UTC) I believe that the template tags were one area that sub pages were acceptable. I would suggest that perhaps plugin pages would be the same, but this needs a quick decision.

---

--Rob Mientjes 23:42, 29 Aug 2004 (UTC) Plugins is a bit hard. It isn't a feature of WP, more of an addition, so it would be preferable to toss it into subs. Template tags should definitely be in sub pages. It could cause doubles if they aren't, and if we start ordering everything correctly, it makes up for the trouble of deciding how to do it :p

Given that we are now using subpages for things like the Function Reference, would it not make sense to turn on MediaWiki's subpage feature for the main namespace? That way we would get a breadcrumb navigation at the top of those subpages. See http://www.mediawiki.org/wiki/Manual:$wgNamespacesWithSubpages for how. Just an idea! — Sam Wilson ( Talk • Contribs ) … 02:11, 4 November 2008 (UTC)

Visual Styling

THIS DISCUSSION TOPIC IS OPEN

--NuclearMoose 02:56, 29 Aug 2004 (UTC) Playing around with visual styling for the page. Comments? Suggestions? Ideas? Drop it? Keep it? Make a template?

---

--Rob Mientjes 19:38, 29 Aug 2004 (UTC) How must I see this? It would be smart to let it be a clear variation of the WordPress homepage. Actually, simply put, it should be in the same colour scheme, the same styling, but the layout should be 100%. It's the best way to present the content.

Dead-end pages

THIS DISCUSSION TOPIC IS OPEN

--NuclearMoose 21:57, 30 Aug 2004 (UTC) Would like to see that all pages have a link out of them. Perhaps in the case of plugins, the link should be to the plugin main page, etc. This is to prevent Special:Deadendpages.

---

--Rob Mientjes 23:01, 30 Aug 2004 (UTC) Indeed. But that would require pages like categories, to display everything in that range, e.g. AudioScrobbler Plugin has a link back to the Plugins page. And that's logical. But there are pages that make this impossible. Maybe we should just try to prevent that.

---

--Carthik 03:29, 31 Aug 2004 (UTC) I would encourage the creation and use of Templates, like Template:Stub for creating navigation. Maybe create PluginNavlinks , a stub, and use it on all the Plugin Pages?

Improving the Codex Guidelines

Going over the Codex Guidelines, I have a few questions/recommendations.

1. Can/should the word "wiki" be changed to Codex since this isn't such a wiki wiki?

-- Done, wherever I could.

1. I'd like to add an item under "Creating New Pages" that links to examples of layout style and the Help:Editing pages to keep the look and feel consistent.

-- There is now a Creating New Pages page.

1. Item #7 under New Pages is kinda vague. It took me several readings to get it. I'd like to see it say something like: The WordPress Codex standard is to feature article information on one page and not use sub-pages to divide the information. This standard may not always apply to extensive and indepth information, so if you think a page needs a sub-page structure, please check with the documentation team first. Then say how to contact the documentation team.

-- Fixed.

1. I still don't know what a Stub is. I can assume that it is a reference to incomplete pages but it is a strange word. For those of us not up on wiki lingo, could a definition be listed in item 2 under Ensuring Correctness?

-- The maintenance page now explains it all.

1. Is Item 2 under Conventions necessary since it only applies to one person, I assume? Maybe have specific guidelines for sysop/admins who would need this piece of information.

-- Changed.

1. Under Discussions, I'd like to see that cleaned up to look like the rest of the page (titles - explanations) and a list of sources and the hierarchy of those sources for getting help. Like who is the admin (link to userpage), how to find the folks in charge (their userpages or a list of userpages), the documentation team, the Sandbox, the mailing list, and other bits of information to help people figure out what is going on where and with who.

-- are the changes good enough?

1. A new category that highlights where critical information is found within the Codex. Specifically, identifying Special Pages, Wanted Pages, Dead End Pages, All Pages, Pages Requiring Editing, ...not the whole list but the key ones that people need to know if they are going to "help".

-- With the newly created Maintenance page, this should not be a problem anymore, I hope.

1. I'd also like to see a step-by-step outline of how a person can register and participate. I'd like to see it include "you cannot participate until you have made your own UserPage" which shouldn't be a rule as much as a serious recommendation. This will do several things, most importantly 1) have them create a page with information about the person (email contact at the least - their website address would be nice, too) and 2) introduce them to the concept of writing and editing a page within the Codex since the conventions are different from HTML and Wikis in general.

-- the new re-org should have addressed this.

Okay, that's enough for now. When I was started out here, I went forth blindly until someone said, hey, check out the Codex Guidelines and then gave me helpful advice that I should have gotten from the Guidelines. Lorelle 17:29, 8 Mar 2005 (UTC)

Did anyone ever pay attention to the above edits and suggestions? Just curious. Lorelle 03:54, 29 Mar 2005 (UTC)

Thank, Lorelle. It took a long time for these to be fixed, please let us all know what you think of the new!

Carthik ‹ ℂ › Talk 17:42, 9 May 2005 (UTC)

On Launch

THIS DISCUSSION TOPIC IS OPEN

Tor 18:48, 28 Mar 2005 (UTC) Can we remove the bit at the top of the page about this being the "soft-launch"? WP 1.5 is out, and I thought the Codex was supposed to be prime-time now. Though, I'm not sure enough to delete it.

Tor, we appreciate the catch, but the "soft launch" is for the Codex, not for 1.5. The codex is still in "what the heck are we doing" phase, though, you're right, quickly leaving that. If WordPress is at v1.5, I'd have to say that this Codex is at v0.4 and rising quickly. So, yes, the Codex is still in soft launch phase. Hope you are feeling better, too, and thanks for at least trying to help with the Codex when you're feeling miserable. It's really appreciated! Lorelle 03:59, 29 Mar 2005 (UTC)

Point on Separate Comments

In 3. Separate Comments: of Discussions, rather than using the four (4) dashes, consider recommending use of the "+" button (between the edit and history buttons) to add new sections.

MichaelH (talk) 21:33, 12 May 2005 (UTC)

Done!

Carthik ‹ ℂ › Talk 21:38, 12 May 2005 (UTC)

Consider filtering spam

Hey all. You guys might want to consider installing a spam filter like the one on Wikitravel. I'm afraid that making the spammers log in doesn't seem to deter them. -- MarkJ 11:53, 24 Oct 2005 (GMT)

Capitalization and formatting of WordPress terms

Adam.samec 17:43, 12 March 2013 (UTC). I suggest that Guidelines state the recommended formatting and letter case for writing terms used within WordPress administration screens and Codex. Bellow are possible options which sounds acceptable to me. They can be combined as you consider will be the best choice.

1. When referring to a term for the first time, make a link to Glossary or a related article. (e.g. “A tag is a keyword for a post. A post can have many tags.”).
2. Use capitalization (e.g. “A Tag is a keyword for a post. A post can have many Tags.”).
3. Use capitalization only for the first time the term is being mentioned (e.g. “A Tag is a keyword for a post. A post can have many tags.”).
4. Use italics (e.g. “A tag is a keyword for a post. A post can have many tags.”).
5. Do not bother with case. (This is the current practice. :-])

From my perspective, bold text is not appropriate since its application is mostly a span of important text, or a way to draw attention to a correct spelling (e.g. WordPress), or highlighting a relevant part of code. It is also ugly to have an article full of bold text. I have added some recommendation to the Character Formatting section of the Help:Editing article, but it is a bit vague in the way terms should be formatted.

The combination of 1) and 4) seems the best to me. Maybe not using a link and italics at the same time, but such an exception could be confusing. Sometimes, capitalization is not enought to separate a term from an ordinary word, mostly when at the beginning of a sentence (e.g. “Post is a specific post type.” vs. “Post is meant as any piece of contribution to a site, and may be of a specific post type.”). Moreover, even the real WordPress administration screens do not use the capitalization within its descriptive texts.

I also suggest the names of Codex articles when referred from text are formatted and linked in the same fashion as terms, like I did here, on the top of the fact that they should follow Dr. Grammar. In the case of administration screens, when referring to a specific UI element, such as a screen or button, I would hold to its exact label in UI (e.g. '“Edit Post screen” or “the Publish button”.

I have demonstrated the suggested formatting on the Post Types article.