I agree that curid was a horrible horrible choice for the parameter name. However, I don't really think there's a compelling reason to rename it since we'd need to keep back-compat anyways. Its not like users are expected to really use it.

To complete the set, a magic word would be nice, such as {{PAGEID}}, as simply
a wrapper around wgPageId.

That's semi bug 23427 (see comments towards the end).

Should I infer from your comment that aliases are not possible? And even in that case, since these are not heavily used, and considering that backwards compatibility has been broken before (e.g. in the 2008 parser update), couldn't this be a possibility?

We're trying to avoid re-living the 2008 parser update when there is not a very compelling reason to do so.

Aliases are "possible" -- anything is possible -- but I think Bawolff is trying to make the point that they aren't a very good idea since, in order to avoid re-living the 2008 parser update, we would have to be saddled for a very long time with some superfluous baggage. (If that isn't the point he is making, then I'll volunteer to make it.)

I get it, but is the consistent nomenclature + extra baggage (aliases) really worse than the inconsistent, poorly-named, confusing nomenclature we currently have? We're balancing two evils here, and I personally think the first one is the less bad, especially since it allows a gradual phasing out of the old system, and eventually dropping the extra baggage altogether.

(In reply to comment #4)

I get it, but is the consistent nomenclature + extra baggage (aliases) really
worse than the inconsistent, poorly-named, confusing nomenclature we currently
have? We're balancing two evils here, and I personally think the first one is
the less bad, especially since it allows a gradual phasing out of the old
system, and eventually dropping the extra baggage altogether.

Besides, wgArticleId is too Wikipedia-main-namespace centric ( a dictionary entry, a book page, and so on, aren't "articles").

Re-opening. I can't make any sense of the rationale for marking this as "wontfix."

Rationale:

• In contrary to what Waldir said ("since these are not heavily used") both the curid paramter and the wgArticleId are very much used accross templates, archives, permalinks, bookmarks, gadgets, users scripts, site scripts and what not
• Changing them means we will have two ways of doing the same thing, which is more confusing ("what's the difference between curid and pageid ?"). This also most likely means one will have to be dropped at some point, see next point:
• Cool URI's don't change!
• Why intentionally change something that requires changing 100s if not 1000s of script pages within and outside of the Wikimedia landscape regarding to scripts and templates ? Not to mention the documentation that has been copied of the years all over the place...
• Lastly, if there would actually been an improvement (other than, "it looks better if you know the database") I could see an advantage, but right now it seems like bike-shedding over something that wil only bring more work and more argue from the community over breaking scripts and templates.

One solution I would consider as an option is adding the pageid as an alias and keeping both "for ever". (eg. wgArticleId, pageId in mw.config JS and curid/pageid parameter to index.php).

(In reply to comment #7)

One solution I would consider as an option is adding the pageid as an alias and
keeping both "for ever". (eg. wgArticleId, pageId in mw.config JS and
curid/pageid parameter to index.php).

Having both sounds good enough to me (as I mentioned in comment #0). We might then gradually convert to the more logical version (or not). I think it'd be especially worth changing instances of wgArticleId and curid in MW code itself, and mention them as obsolete in the documentation -- not that much to look neat for people who know the db schema, but mainly to improve the self-documenting nature of the code (we do want to facilitate and encourage volunteer development, don't we?) and reduce cruft inherited from bad choices in the past.

Alright, sounds good. I'll assign to myself but leave status to NEW/REOPENED as I won't be able to work on this within this week.

If someone is interested, patches are welcome and I'll review/commit quickly. Otherwise I'll likely get to this sometime next week.

(In reply to comment #1)

I agree that curid was a horrible horrible choice for the parameter name.

We had an oldid parameter for the old_id database field, so I think it made sense for me to add a curid parameter for the cur_id database field. There were good reasons to later rename the database field to page_id, but it was not possible to justify a b/c break in the public interfaces.

(In reply to comment #5)

Besides, wgArticleId is too Wikipedia-main-namespace centric ( a dictionary
entry, a book page, and so on, aren't "articles").

Dictionary entries etc. are articles, in the sense that they are represented by an object of the "Article" class. The variable is named after the class.

Dictionary entries etc. are articles, in the sense that they are represented
by an object of the "Article" class. The variable is named after the class.

Well, it sounds like we should also aim to come up with a clearer nomenclature for the Article, WikiPage and Page classes, then :)
http://svn.wikimedia.org/doc/classPage.html

(In reply to comment #11)

Dictionary entries etc. are articles, in the sense that they are represented
by an object of the "Article" class. The variable is named after the class.

Well, it sounds like we should also aim to come up with a clearer
nomenclature
for the Article, WikiPage and Page classes, then :)
http://svn.wikimedia.org/doc/classPage.html

I think Lee was relatively unconfused about the difference between articles and pages. A page is a thing that you show to the user that has a title. An article is a kind of editable page that is stored in the database; they have a nonnegative namespace ID. Hence OutputPage::setArticleFlag().

Mind you, he did introduce ImagePage, so maybe he was a little bit confused. And it went a long way downhill from there, under later authors.

(In reply to comment #12)

A page is a thing that you show to the user that has a title.
An article is a kind of editable page that is stored in the database; they have a nonnegative namespace ID. Hence OutputPage::setArticleFlag().

Mind you, he did introduce ImagePage, so maybe he was a little bit confused.
And it went a long way downhill from there, under later authors.

Fascinating stuff. But I'm a little confused.
First, "article" isn't really indicative of an editable page, so maybe a better name would make it less likely for others to misinterpret that meaning.
Second, since -2 is only an alias for a direct file link (no page is actually displayed), negative namespace numbers essentially mean special pages, i.e. read-only/auto-generated pages.
Third, I don't really understand why there's ImagePage vs. WikiFilePage and CategoryPage vs. WikiCategoryPage (I haven't tried to read the code, but the name should definitely be more descriptive)

Considering the above, would you say that the following is a good semantic representation of the current types of pages mediawiki supports?

• Page
  • WikiPage (i.e. Article)
  • SpecialPage
  • CategoryPage (CategoryPage + WikiCategoryPage?)
  • FilePage (ImagePage + WikiFilePage?)

(I'm not sure where the current WikiPage class would fit here)

Otherwise, were you to hypothetically rearrange these classes' names and relationships, what hierarchy would you pick?

Note that I'm not asking merely out of personal curiosity, or because I indent to suggest such a change to be effected (though I certainly would approve of such a move), but rather because I believe a clear overview of page types can enhance the current documentation, and I'll try to integrate the insight from your comments into manual pages at mediawiki.org.

Just recently @matmarex made some changes to the skin system (T71277) that involved changing templates, gadgets, etc., which shows this is perfectly doable. So I don't think that should be an argument for wontfixing this.

I only did that because the skins/common/ directory was actually
problematic (people complained about the situation) and because my
earlier skin work (T45658, T62453) directly led to it becoming
problematic (rather than just tech debt). I do not at all wish to ever
do something similar again. :)

I do not at all wish to ever do something similar again. :)

Sure, but if someone is willing to do that kind of work, there's no reason to stop them. I just pointed out your example because it shows that such a change is perfectly possible (albeit hard / unpleasant), so it shouldn't be used as a reason for declining this. Don't you agree?