I'm not sure there is a need for this from a Wikiversity perspective. It seems more like it was suggested as a student project vs. a community request. @jayvdb may have more information.

See https://en.wikiversity.org/w/index.php?title=Wikiversity:Colloquium&oldid=2343831#Extension:WikiSEO for discussion.

@Jdlrobson Done as https://phabricator.wikimedia.org/T288270 .

Please add [[Special:LintErrors]] rules to detect pages that have this issue.

https://en.wikiversity.org/wiki/MediaWiki:Random-url now updated.

@DannyS712 , @Zoranzoki21 : Just checking to see if there's any other information you need to complete this request. Thanks!

It appears that everything has been resolved. Thanks!

I think that's a valid assumption. I'm trying to think of a use case where a wiki would want RandomRoot for their main namespace but Random for one of the other namespaces. I'm not coming up with anything.

The best way to understand why might be the explanation at en.wikipedia: https://en.wikipedia.org/wiki/Help:Special_page .

Only namespace 0 (NS_MAIN?) is a content namespace.

The mobile configuration should match the desktop configuration. The Random desktop link is already configured as:
Special:RandomRootpage

I'm not sure I have any value I can add to the project at present, but if something comes up, please let me know.

Thanks for your assistance on this. I've removed the problematic code from https://en.wikiversity.org/wiki/MediaWiki:Common.js . It did not appear to be necessary anymore.

en.wikiversity JavaScript appears to be working correctly now. Please advise as to any changes made so I / we can understand where to look for these problems in the future, and perhaps avoid them.

I commented out the offending code in https://en.wikiversity.org/wiki/MediaWiki:Common.js . That moves the JavaScript load error, but does not resolve it. I'm not an experienced JavaScript developer, and I'm having problems locating where it moved the problem to. Any additional hints would be greatly appreciated.

Demonstration page identifying multiple JavaScript-controlled user-interface elements:
https://en.wikiversity.org/wiki/Wikiversity:JavaScript

It's been broken since June. Not necessary to work on it over the weekend unless you want to. It is somewhat functional in its current state but not desirable.

The wire frames above look good. Currently missing from the web version is the percentage of plagiarism detected and the word count for the edit. These would definitely be helpful on smaller wikis where there are fewer users to do plagiarism checks.

Thanks! Would you be willing to include a short summary of how the issue was resolved? I'm trying to learn more about Linux configuration, and it would certainly be helpful for me. It might also help others later who find this on a search and wonder how to resolve similar issues.

Yes, that resolves this issue. I took the code and put it into a different template:
https://en.wikiversity.org/wiki/Template:Review_question

Would adding the old data with a different tag work? The historical / "bad" data could be loaded with a "historical" or "deprecated" tag. And if you're willing, load through June 30, 2016. That's a 13/14 month overlap, allowing full comparison of old and new measurements. After June 2016, only new data would be available.

I'll just add my own quick perspective on this. The previous method for accessing log files by having to download all data for all projects by hour was research-prohibitive. The Pageview API is a significant improvement for quickly getting individual pages or top 1000 results.

Thanks!

I'm not sure where to share this code with the community, so I'll add it here for reference. I created a Python script to generate monthly stats for en.wikiversity, and also functions to pull and tally individual page stats from a list of pages. The code is at:
https://en.wikiversity.org/wiki/MediaWiki_API/Pageview_API

Thanks for the suggestion. But there's more to it than just HTML formatting. The numbers are used as div IDs to hide and show each answer individually. The div could likely be converted to a span, but that doesn't resolve the issue of numbering them uniquely on the page so they can be triggered individually.

I don't know where this would fit in terms of priority, but something I was just looking for is what might be called "Referrer URL" in a web sever log file. I'm not looking for any external information that would be a privacy concern. What I would like to see is which internal page links are highly used to access other pages, and which ones aren't. In other words, when looking at "What links here", I'd like to be able to find out which of those links are promoting the page, and which ones aren't.

Clarifying: It was already in the proposal at https://en.wikiversity.org/wiki/Wikiversity:User_access_levels that Custodians would be able to remove Curators. I just forgot to include it here.

Sorry, I missed that detail. The intention was that Custodians would be able to both add and remove Curators. I will update our documentation accordingly.

After thorough discussion and voting on Wikiversity user access levels, available at https://en.wikiversity.org/wiki/Wikiversity_talk:User_access_levels, the community supports the creation of a new Curators group with rights listed at https://en.wikiversity.org/wiki/Wikiversity:User_access_levels. The discussion was listed with a site-wide notice, https://en.wikiversity.org/w/index.php?title=MediaWiki:Sitenotice&diff=prev&oldid=1455933, and open for two weeks. The Curators group will not have access to deleted content, addressing concerns noted above.

See https://en.wikiversity.org/wiki/IT_Fundamentals/Hardware#Review_Questions . The review questions are numbered both internally (hidden tag) and visually for the user. It would be nice to have a variable that could be used for both numbers and incremented through code rather than typed manually.

We have a number of pages where we have sequential numbers on content, but the numbers need to sent to templates to be rendered rather than numbering the content using #. Some pages may have as many as 40 or 50 of these items, and they are currently maintained manually. I was hoping to use variables to automate the counting. I tried Lua, but each #invoke is a clean state.

Thanks for the fast response. Are there any alternatives that might provide similar functionality?