Last modified: 2013-06-08 07:15:02 UTC
The new UserLogin shows red links everywhere. I assume this was done to compensate the removal of the wall of text on en.wiki, but it's not nice: on most wikis those help pages won't exist and are not needed (username policy), or are needed but shouldn't exist locally (logging in; bug 43591), or exist but under another title (every Wikipedia except en.wiki; it.wiki has been fixed, fr.wiki not yet, most Wikipedias will never be fixed). Simple solution: kill the links (e.g. createacct-helpusername-link) and leave them to customisations of the preceding messages (e.g. userlogin-yourname), which need to parse links and also some HTML if the grey is absolutely needed, and possibly to be copied to a new key if they're recycled from previous interface. Complex solution: identify if the page exist and don't link it if it doesn't and/or link to MediaWiki.org, e.g. https://www.mediawiki.org/wiki/Help:Logging_in .
(In reply to comment #0) > The new UserLogin shows red links everywhere. I assume this was done to > compensate the removal of the wall of text on en.wiki, but it's not nice: on > most wikis those help pages won't exist and are not needed (username policy), > or are needed but shouldn't exist locally (logging in; bug 43591), or exist > but > under another title (every Wikipedia except en.wiki; it.wiki has been fixed, > fr.wiki not yet, most Wikipedias will never be fixed). > > Simple solution: kill the links (e.g. createacct-helpusername-link) and leave > them to customisations of the preceding messages (e.g. userlogin-yourname), > which need to parse links and also some HTML if the grey is absolutely > needed, > and possibly to be copied to a new key if they're recycled from previous > interface. > > Complex solution: identify if the page exist and don't link it if it doesn't > and/or link to MediaWiki.org, e.g. > https://www.mediawiki.org/wiki/Help:Logging_in . As noted in https://www.mediawiki.org/wiki/Account_creation_user_experience/Testing#Things_to_pay_attention_to_while_testing_both_interfaces we are leaving the red links in and encouraging people to either edit the message locally or simply redirect the links to the appropriate title. This is why redirects were invented. Most of these links, like the ones to basic help pages about login and signing up, exist on most of our projects in some form. For third party users, it's one of several things they may need to customize.
(In reply to comment #1) > we are leaving the red links in and encouraging people to either edit the > message locally or simply redirect the links to the appropriate title. Annoying users to poke sysops is not the way, nor poking the sysops to fix something that is broken in most cases: please fix the interface.
This seems related to bug 47704.
(In reply to comment #3) > This seems related to bug 47704. Yes, but that would be only a partial fix of the problem. Anyway, it's clear that Steven is the only person believing such pages must be forced down the throat of all wikis.
I commented laying out options for the username link at https://bugzilla.wikimedia.org/show_bug.cgi?id=47704#c12 .
To be specific, the three URLs assumed by the new login and create account "VForm"s are * createacct-helpusername-url discussed in bug 47704 * helplogin-url * createacct-captcha-help-url (only appears if the wiki is using FancyCaptcha) https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages that a wiki already needs to create to avoid red links. (I only found this page just now, it is unfortunate that the installation instructions don't mention it.) I added the three urls introduced by the new forms there, it will change as we work through these bugs. These message URLs solve issues with the login and create account forms that some non-WMF wikis have as well. If we make them blank by default it's less apparent how those wikis can deliver the better experience. It's a tradeoff.
(In reply to comment #6) > https://www.mediawiki.org/wiki/Manual:Page_customizations lists all the pages > that a wiki already needs to create to avoid red links. (I only found this > page > just now, it is unfortunate that the installation instructions don't mention > it.) I added the three urls introduced by the new forms there, it will > change > as we work through these bugs. Thank you for the link. I hope you don't want me to make a list, but those pages 1) are not comparable to such a specific thing as a username policy or captcha help page, 2) are mostly not even shown as red links, 3) are not in the way like these red links on an important page like UserLogin. The only exception is edithelppage, which you removed on en.wiki. > > These message URLs solve issues with the login and create account forms that > some non-WMF wikis have as well. If we make them blank by default it's less > apparent how those wikis can deliver the better experience. It's a tradeoff. I don't see any tradeoff. In particular, createacct-captcha-help-url linking to a nonexisting page really means laughing at people. In general, links are where you expect links to be (sidebar, footer) and it's always "apparent" how to add more elsewhere: it's what we have MediaWiki pages for, you just find a message where you want the link and edit it. The current new interface actually makes it harder, because it adds a separate system message, instead of letting you edit the message next to which you want to add your link as normally done in MediaWiki.
Based on consultation with S Page, Matt Flaschen, and Ori, I've changed the bug title to reflect the soluton we've hit on. Here's the summary version: * Wikimedia-specific messages such as the username policy will be blank by default and migrated to Extension:WikimediaMessages for localization * There may still be some red links that need local customization, per comment 1, but they will be limited to Wikimedia communities that could conceivably make good use of such red links and have active communities to deal with them, with our help I'm going to mark a few other bugs related as duplicate of this, due to the new title which encompasses them as well.
*** Bug 47704 has been marked as a duplicate of this bug. ***
*** Bug 47705 has been marked as a duplicate of this bug. ***
Related URL: https://gerrit.wikimedia.org/r/62570 (Gerrit Change I28b0079b971e5f6cf5196d5581bbfd7a3ac405f9)
(the Gerrit bot didn't notice https://gerrit.wikimedia.org/r/#/c/61395/ , Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df ) The gist of the Gerrit changes is * createacct-helpusername (slight name change) is blank by default * createacct-imgcaptcha-help is blank by default The messages for these and the URLs they incorporate moved to the WMF-specific extension WikimediaMessages. userlogin-helplink and the helplogin-url it incorporates remain in core
Well, I am lost. I hope that someone will compile a list of the end changes, of what admins at wikis are going to need to be told (not guess or need to search), and some graphic examples sound as they would be worthwhile. Also something that global sysops and stewards can just read and understand. There are enough changes going on for stewards to comprehend and manage without extra difficulty being imposed by convolutions.
(In reply to comment #13) > Well, I am lost. I hope that someone will compile a list of the end changes, > of > what admins at wikis are going to need to be told (not guess or need to > search), and some graphic examples sound as they would be worthwhile. Also > something that global sysops and stewards can just read and understand. > There > are enough changes going on for stewards to comprehend and manage without > extra > difficulty being imposed by convolutions. I'll post instructions with screenshots that are clearer, before we turn on the new versions as defaults, and circulate them as best I can.
(In reply to comment #14) > (In reply to comment #13) > > Well, I am lost. I hope that someone will compile a list of the end changes, > > of > > what admins at wikis are going to need to be told (not guess or need to > > search), and some graphic examples sound as they would be worthwhile. Also > > something that global sysops and stewards can just read and understand. > > There > > are enough changes going on for stewards to comprehend and manage without > > extra > > difficulty being imposed by convolutions. > > I'll post instructions with screenshots that are clearer, before we turn on > the > new versions as defaults, and circulate them as best I can. To clarify (S Page asked me) I mean posting on-wiki, probably either Meta or MediaWiki.org.
That would be great. We will need something at meta, whether it be the specific WMF components, or a summary, and a direction to mw. Well, depending on my (mis)understanding of the above.
Related URL: https://gerrit.wikimedia.org/r/64204 (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df)
Merged, so I assume this is fixed.
Related URL: https://gerrit.wikimedia.org/r/64254 (Gerrit Change Ie0888cd0582dc3f63ae569097159a4d9b171a5df)
E3 requesting backport to wmf4 (only) with Gerrit change #64254 so this change to the new Create account form can accompany the wmf4 roll-out. Low-risk since the new forms are opt-in.
plus'd it (not in the G kinda way). CC'ing Reedy so it is on his radar for Monday's deployment. Setting back to REOPENED until the backport is done (just so we don't lose it between now and then). Thanks!
(In reply to comment #13) > Well, I am lost. I hope that someone will compile a list of the end changes For WMF wikis, the three links in <https://www.mediawiki.org/wiki/Account_creation_user_experience/Testing#Providing_help_links> For a regular MediaWiki install, the only help link that isn't blank by default is Help:Logging_in , mentioned in https://www.mediawiki.org/wiki/Manual:Page_customizations
Great. So that I need to go and copy/paste the messages on TranslateWiki.net just because they were moved&renamed to be prefixed with “wmf-” (and in case this wouldn’t be enough unnecessary work, http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was deleted, so that I couldn’t even copy&paste (since I cannot view deleted revisions) and had to translate it once more from scratch). Couldn’t the existing translations have been moved as well? Just saying.
(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with “wmf-” (and in case > this wouldn’t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn’t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn’t the > existing translations have been moved as well? Just saying. Well, in theory a Wikimedia-specific message doesn't have the same meaning and content as a core one, so reusing core translations would defeat the purpose (not polluting core). I don't know what the status here was exactly; cc'ing Raymond who deleted them.
(In reply to comment #23) > Great. So that I need to go and copy/paste the messages on TranslateWiki.net > just because they were moved&renamed to be prefixed with “wmf-” (and in case > this wouldn’t be enough unnecessary work, > http://translatewiki.net/wiki/MediaWiki:Createacct-imgcaptcha-help/cs was > deleted, so that I couldn’t even copy&paste (since I cannot view deleted > revisions) and had to translate it once more from scratch). Couldn’t the > existing translations have been moved as well? Just saying. First, thanks for translating! It is gratifying to see translations appear for our work. The fix for this bug required moving these messages into the special WikimediaMessages extension, and (as I understand it) in order to distinguish the WMF versions of messages on TranslateWiki they get this "wmf-" prefix. When moving messages between core and extensions the recommendation for engineers is to only move En and Qqq, but in the case of WikimediaMessages I think I could/should have copied over the other languages.
