Last modified: 2014-03-19 19:35:07 UTC
See URL for an example, but this is true for any talk page. The message displayed when watching a page is: "The page "Page title" has been added to your watchlist, which will list edits to this page and its associated talk page. The page will also be bolded in the list of recent changes." This is OK for a content page (first tab), but if the page is a talk page, the talk page and its associated talk page will apparently be added to the user's watchlist. Talk pages don't have talk pages. The watcher should distinguish the namespace of the watched page and return one of two different messages: one for content pages, and one for talk pages. This could be implemented by changing the current addedwatchtext message to accept a second parameter, the type of the associated page, so instead of enwiki's: The page "'''$1'''" has been added to your [[{{ns:Special}}:Watchlist|watchlist]], which will list edits to this page and its associated {{#ifeq:{{NAMESPACE}}|{{TALKSPACE}}|content|talk}} page. The page will also be '''bolded''' in the [[{{ns:Special}}:Recentchanges|list of recent changes]]. It would read: The page "'''$1'''" has been added to your [[{{ns:Special}}:Watchlist|watchlist]], which will list edits to this page and its associated $2 page. The page will also be '''bolded''' in the [[{{ns:Special}}:Recentchanges|list of recent changes]]. Not sure how much sense I made, but I'll be checking back regularly, so ask a question if you don't understand.
You can't use {{#ifeq: in a message, because #ifeq is handled by the ParserFunctions extension, which isn't installed by default (although we should really make it part of the core, but that's another story). Maybe two messages "addedwatchtext" and "addedwatchtext-talk"?
Having two completely separate messages would require more maintenance if they were to be changed. I would advocate keeping "addedwatchtext" and adding "addedwatchtext-content" and "addedwatchtext-talk" to be switched based upon namespace number (even NS#'s get -content, odds get -talk) in an added $2 parameter. The reason I entered this bug in the first place is because #ifeq: obviously wasn't working (otherwise the problem wouldn't exist on enwiki).
The correct change would be to pass the content page's name instead of the talk page's name into the message texts.
(In reply to comment #3) > The correct change would be to pass the content page's name instead of the talk > page's name into the message texts. > So the message's title parameter would get the value of {{CONTENTPAGENAME}}?
Changed component to "Watchlist"
There's a much easier way to fix this issue, and it's by not being so unnecessarily verbose. See a related analysis at http://usability.wikimedia.org/w/index.php?title=Opinion_Watch&oldid=4494#Watch_icon_.26_feedback_message
(In reply to comment #6) > There's a much easier way to fix this issue, and it's by not being so > unnecessarily verbose. See a related analysis at > http://usability.wikimedia.org/w/index.php?title=Opinion_Watch&oldid=4494#Watch_icon_.26_feedback_message Changed summary accordingly. Note, however, that "They know that already, they're on the page" is a wrong assumption (in the second part), for instance the "add to watchlist" link can be opened in another window/tab or it can load a confirmation page if the frame can't be loaded within the current one. The tooltip proposal should probably be another bug.
I don't know when exactly, but 1.20wmf10 has changed the message display, which is now some sort of rectangular-bubble popup on the right rather than a notice appearing below the tabs. It doesn't change the message itself though.
Kaldari's Gerrit change #38805 removed the sentence about RC altogether. This may be ok but that info needs to be displayed at least on the RC legend; copying my comment here. ---- How is one supposed to understand why it's bolded in RC now? 'recentchanges-summary' doesn't contain this piece of information and the 'recentchanges-legend' section contains only switches. You could as well have removed "Future changes to this page and its associated talk page will be listed there." ---- I liked Siebrand's proposal better: it gave all the necessary information in a single line and only 40 characters more, without need for a new message in RC.
