Wikimedia Bugzilla is closed!

Here is a non-JS workaround (although I think the devs will cache even that message some day ;-)

[[pt:MediaWiki:Nstab-main]] content:
{{#ifeq:{{PAGENAME}}|Página principal|página principal|artigo}}

@devs: Please do not cache [[MediaWiki:Nstab-main]] until this bug is fixed, it's in use ;-)

Excellent, thank you! I've ported the code over to [[en:MediaWiki:Nstab-main]] and it is working superbly.

By the way, if anyone else is interested in using this, please make sure to capitalize the first letter of the text, like so: {{#ifeq:{{PAGENAME}}|Main Page|Main page|Article}}

All the nstab messages start with capital letters by default, and it turns out this makes a difference on some skins.

Actually, it turns out the P can be capitalized for consistency and it will still how up in lowercase in monobook, so it would be best to use {{#ifeq:{{PAGENAME}}|Main
Page|Main Page|Article}}

(In reply to comment #1)
> @devs: Please do not cache [[MediaWiki:Nstab-main]] until this bug is fixed,
> it's in use ;-)

Caching is fine. If these kind of things are cached with the title of the page inside of their key then it's fine.

IMHO all these system messages should be cached with the title.

@comment #5: Then [[MediaWiki:Sidebar]] and [[MediaWiki:Sitenotice]]/[[MediaWiki:Anonnotice]] are cached without title in key, for example.

Those would be exceptions. Sidebar should never have special conditional parserfunctions inside of it. It wouldn't even work out. And the sitenotice and anonnotice by definition are supposed to be global, they are never supposed to change per page. And if they did it would screw up the whole ability to dismiss them.

Wouldn't it make more sense to have a separate messages (or even use mainpage-description?).

I've fixed this in vfd.org.

A few questions:

1) Do we actually want this?

2) In core or in extensions?

3) Should it be for the main page only, or a generic parser function like {{CUSTOMTABTEXT}} that would replace nstab-main (or whatever) with the contents of MediaWiki:perpage-nstab-<pagename> or whatever, if it existed?

4) Is there any particular rationale for wanting this only for the nstab and not, say, the discussion tab, in principle?

Overall, if the main page isn't an article, maybe it should be moved to [[Wikipedia:Main Page]].  Then the tab will automatically say "project page", which seems appropriate, without need for hacks.  Don't some projects do this already?  It seems like if you put it in the namespace for articles, it should say "article", and if it's not one, it shouldn't be in that namespace.

Created attachment 5037 [details]
Patch to implement mainpage-description in the content tab for the "Main page"

(In reply to comment #10)
> A few questions:
> 
> 1) Do we actually want this?
> 

I've got a patch (attached). If someone wants it, we can do it.

> 2) In core or in extensions?
> 

If it does go in, it should be in core. Extension:ReplaceMainpageTabText
is rather silly.

> 3) Should it be for the main page only, or a generic parser function like
> {{CUSTOMTABTEXT}} that would replace nstab-main (or whatever) with the contents
> of MediaWiki:perpage-nstab-<pagename> or whatever, if it existed?
> 

I'd vote no on this. {{DISPLAYTITLE}} exists for customizing the title of the page.
The "page" tab is for describing what form of content you're looking at. 

> 4) Is there any particular rationale for wanting this only for the nstab and
> not, say, the discussion tab, in principle?
> 

Who knows? Someone probably will ask for it.

> Overall, if the main page isn't an article, maybe it should be moved to
> [[Wikipedia:Main Page]].  Then the tab will automatically say "project page",
> which seems appropriate, without need for hacks.  Don't some projects do this
> already?  It seems like if you put it in the namespace for articles, it should
> say "article", and if it's not one, it shouldn't be in that namespace.
> 

I'm really on the fence about this. On the one hand, I see your argument Simetrical about the Main page belonging in the Project: space as it is arguably not content. However, this bug isn't about the proper namespace for the main page.

I see this as similar to the "mainpage-description" for the left sidebar. Arguably useless, but allows the users to customize it. Right now, the primary motivation for this patch is keeping en.wiki from using CSS/JS/Parserfunction hacks to _force_ the tab on the main page to say "Main page."

I think really the tabs purpose is to define what kind of content you're looking at (Image/Category/Page/Special/etc). If the mainpage is considered something special and needs a description other than the default, then my patch would be appropriate. Otherwise, just leave it with the default 'page' and let's move on.

Reusing [[MediaWiki:Mainpage-description]] is definitely the wrong way to go about this.  Reusing messages is usually a bad idea.  It's perfectly plausible to want something different in the nstab and the sidebar, e.g., "Back to Main Page" might be appropriate for the sidebar but not the nstab.  Also, if the main page is in a namespace whose nstab description is appropriate, say "project page" or just "page", there's no reason to change it, so any change should be strictly optional.

Do keep in mind that with the default messages, there's no problem at all.  The default nstab for namespace 0 is "page", which is totally appropriate for the main page.  If enwiki wants to create problems for themselves by changing what namespace 0 is supposed to contain and then refusing to actually stick to their decision by leaving the main page there, that's not something we need to consider supporting in software, IMO.  If they think the extra X lines of JavaScript are superior to adjusting their other customizations, that's their decision as site admins.  Lots of people do stupid stuff with the software -- we don't have to support it just because it happens to be a big wiki.  In the software as shipped, this is a non-issue.

Suggest WONTFIX.

(In reply to comment #12)
> ...If enwiki wants to create problems for themselves by changing what
> namespace 0 is supposed to contain and then refusing to actually stick to their
> decision by leaving the main page there, that's not something we need to
> consider supporting in software, IMO...

I agree with you fully here. Like I said, this comes down to being a hack.

> Suggest WONTFIX.
> 

You've convinced me. Marking as such.

Hold on, until you devs fix the main page dilema, you let the admins at en.wikipedia use whatever parser hacks they want. It's a legitimate issue that is gaining consensuson en.wikipedia. Leaving as WONTFIX only feeds the impression that devs are incompetent when it comes to non-tech matters with the edtors at a wiki (see [http://en.wikipedia.org/wiki/Wikipedia:Don%27t_give_the_developers_ideas this].

Tim has suggested that a generic parser function could be introduced for this, akin to my (3) in comment 10.  I suppose we've introduced substantial features for even narrower use-cases than this.  I won't reclose, anyway.

(In reply to comment #14)
> Leaving as WONTFIX only feeds the
> impression that devs are incompetent when it comes to non-tech matters with the
> edtors at a wiki (see
> [http://en.wikipedia.org/wiki/Wikipedia:Don%27t_give_the_developers_ideas

the page you linked contains the following quote:

"WONTFIX is a bitch. So is life. Get used to both, and don't revert the former."

just found that amusing in the context :)

The resolution has been implemented on en.wikipedia, any other wikis wishing to to a similar thing may do so as they please.

#Status is now FIXED

Reopening because this it's not FIXED. Enwiki is still using a JS workaround. Are we going to put in a parser function like in comment 15, or is this going WONTFIX?

Until some code has been checked in and workarounds are being used, it's not FIXED :)

This is not a WikiMedia bug, but rather a misconception about page names having special meanings. 

Closing as INVALID.

*** Bug 26452 has been marked as a duplicate of this bug. ***

We'll add a message for about anything. We've already special-cased the "Main Page" with messages like "Pagetitle-view-mainpage". So I don't see the issue with adding a "nstab-mainpage" message that defaults to the value of "nstab-article" (the "Main Page" is in the article namespace by default). It doesn't particularly matter if it's silly or a minor detail, the users of Wikimedia wikis have been pretty clear that this is a feature they want and there isn't a substantial counter-argument for invalidating their request. Re-opening.

*** Bug 20987 has been marked as a duplicate of this bug. ***

Fixed in r80240.

You can optionally define a 'mainpage-nstab' message to override the tab's text for the mainpage.
I didn't like 'nstab-mainpage' because it would create an edge case where if someone created a "MainPage:" namespace then it's tab and the mainpage's tab would be shared in a conflicting way. After throwing around some names Tim suggested 'mainpage-nstab' like the 'mainpage-description' we have.

I had an interesting discussion in irc with Tim on the parser function idea too. The idea of a {{DISPLAYTITLE}} style parser function to override the tab text is an interesting idea, and someone is free to try implementing it as well, it's a much more generic and widely useful feature than the simple mainpage tab override. But after thinking about how one would implement that, I ended up settling on the fact that while DISPLAYTITLE works nicely in the parser output because you only view the page title on that page. But the main page tab is displayed on the page itself, on it's talkpage, and on all the other things like delete, and move (in 1.18 Move correctly keeps the page's tabs). So if we wanted to correctly display the tab we'd end up having to fetch the parser output (and potentially parse) the article content when we view a talkpage, the edit page, the move page, etc... just to see if the page defined some custom ui tab text (which on most wikis will only be 1 page or none at all). Tim suggested instead we just make it so you'll have to edit Talk:Main_Page to use the same parserfunction to get the same view... though that would leave edit, move, etc... with an inconsistent ui in regards to mainpage tab text.

In any case, open a new bug if you want a more generic parser function to control the text of a namespace tab. This specific bug should be fixed now.

*** Bug 27461 has been marked as a duplicate of this bug. ***