Could someone knowledgeable please mark that template for translation so my changes will show up? Thanks in advance :)
New permission required to hide flow topics?
I used to be able to hide spam topics for flow. I realized last week that I am no longer able to do so. Is there some new permission required and if yes, to which usergroup is it connected?
Answering self. It appears to be "flow-hide" which supposedly may be performed by everybody. So this is a bug. Never mind. I'll wait for the fix.
No, since this happened quite a while back I figured that this has probably already been reported. Done now with task T181765
That's why I usually do not report flow issues. This is utterly painful.
Installation guide consolidation
Manual:Installation guide has one section with a 400 words summary, but then links to a "Main installation guide" composed of 4+4 more pages. None of these pages is translatable. Can we consolidate truly important information and make it translatable? Currently one is supposed to find the following logical steps.
- Download is the page
- Template:DownloadMediaWiki duplicates most info
- Download from Git is sometimes linked instead from docs
- Manual:Installing_MediaWiki#Download_MediaWiki_software duplicates it again
- Manual:Upgrading#Unpack_the_new_files again
- Manual:Installation requirements
- Manual:Installation guide has a largely duplicative summary (which I've now transcluded in the former). Does the complete page really offer any additional value to users (as opposed to devs)?
- Repeated in Manual:Upgrading#Check_requirements
- Actual preparation of requirements: Manual:Installing_MediaWiki#Create_a_database takes most of the space in the guide.
- The actual installation
- Misc troubleshooting and alternatives if something went wrong
- Manual:Configuring MediaWiki
or Manual:Configuration#Configuring MediaWiki (merge proposed)
- A handful of pages linked from there for specific config issues like Manual:Short URL and Manual:Page customizations
- More supposedly MediaWiki-specific server setup information, like Apache configuration, robots.txt, texvc, Comparison of extensions in distributions, ...
- Manual:Performance tuning
- Other stuff indexed in Manual:System administration and Manual:LocalSettings.php
- Manual:Configuring MediaWiki
- Informative material
The pages in bold are part of the official Template:InstallationNav (which complements Template:MediaWiki Introduction): they are supposed to be the official path and need special care and coordination.
Given Chad's comment, I'm also going to tag all "platform-specific" manual pages for merge to the main ones. Common parts can be merged and transcluded on the specific pages, while really platform-specific additional information can be left there. P.s.: for a start, I removed 5 guides on obsoleted systems and marked the others for merge.
Thank you for this!
- Manual:System administration could be useful if it becomes a reasonable index/step by step guide/tutoring of the really important pages in Category:MediaWiki for site admins (allowing to remove respective information from the general installation manual), but I'm not sure of its current role.
- Manual:LocalSettings.php is very visited, but it's quite a mess. I doubt it kept anywhere close up to date, is it currently making a good service to users?
I wonder what's the purpose of making Manual:LocalSettings.php translatable if you doubt about the usefulness of that page or if you plan/propose to improve/restructure it.
The page is vastly correct and the strings contained in it look rather stable, so it's ok to translate it. It is my impression that some consolidation will be needed for that page (reducing total amount of text around), but not a rewriting.
IMHO the direction is rather clear:
- always defer to other sites for guides on how to set up PHP etc.;
- keep all the steps internal to MediaWiki (like installer, config script, LocalSettings.php) in their own, shared manual pages;
- in all the setup-specific pages, just transclude the former and maintain only:
- information on packages available and how to use them (debatable, should be on their sites whenever possibles),
- OS-specific instructions which can't be found anywhere else, like specific paths to put in MediaWiki config or RAM/suhosin requirements and the like.
Backlog at Category:Candidates for deletion
Hello. Noob admin here. I saw that a lot of pages are listed for deletion (NOT speedy deletion) at Category:Candidates_for_deletion. Since they've been proposed for deletion and I'm not sure if there's any historical need to keep them, I'd appreciate if a more experienced admin could have a look at those. Thanks.
This was discussed in Manual talk:Interface#Document_all_messages_here?. Nobody opposed, so I guess it should be fine to delete them.
Translatable pages, however, can only be deleted by a translation admin :(
Surprisingly, a translation admin marked those pages for translation after the delete template was put at them...
I see you managed to delete the first (I tried for all three and it didn't delete the top page). Kick it again?
Reapplied deletion, sorry for doing it prematurely three days ago. It also appeared I didn't undelete it properly...
I just wanted to say thank you for whoever was trying to help me earlier I’m not very good at the computer obviously although I was able to gather up the information this time I just wasn’t able to interpret it. So whoever was trying to help me I really appreciate it I’m just gonna give up I guess. I was trying to check my accounts because my ex-boyfriend has been hijacking my email account for the past year and a half it’s being investigated it has been being investigated for about a year now. I don’t know he watches everything I do not that I do anything that interesting to start with. I guess it’s just a little scary for me. But I really appreciate you taking the time to try to help me whoever it was thanks
PS I’m sure I put this note in the wrong place I’m sorry . Yeah seems to be extremely serious about what you do and I just don’t want to mess anything up. And FYI I didn’t tear up any pages are whatever I guess that’s why I was I’m restricted you so whatever that was probably my ex-boyfriend I don’t even have it I’m in email account with that name but it probably came through my Wi-Fi
Hi could someone please update Extension:ConfirmAccount because it last was updated with some new features when 1.20 was released and in 1.21 the longin and create account button was seperated and in ConfirmAccount it isent it is still together please update it with a new look. I have also ask on the mainteners talk page and they still have not replayed.
Well, this reflects the actual situation of that extension: nobody seems to be maintaining it at the moment.
The Newsletter extension is now enabled in MediaWiki.org
Hi, after a long long journey... Special:Newsletters!
Any newsletters within the scope of MediaWiki.org can be created. In previous discussions it was agreed to only allow administrators to create newsletters. Once a newsletter is created, their publishers can announce new issues at will without requiring administrators anymore.
If you want to create a newsletter and you need an administrator to do it, just reply here specifying:
- the name of the newsletter
- a short description, allowing this newsletter to be recognized in a list with all the newsletters
- a wiki page for its home
- at least one publisher (MediaWiki.org username)
If you want to report problems, request features, or get involved in the project, please check MediaWiki-extensions-Newsletter in Phabricator.
Hello. Congratulations, great job! As always, hewiki can help in finding rtl errors. And there always are rtl errors. So, we'd like to create a newsletter, meanwhile in mediawiki, and one day it will move to hewiki, when available. The notifications will be redirections to upcoming sections in he:project:news. So all notificatons will come from mediawiki to hewiki using Echo interwiki system, and will appear on rtl to subscribers. I created this news project, and publish about 80% of messages there for users, every time there is some interesting new mediawiki engine feature, for example. So naturally, I'll write the notifications. So, could you please create a new newsletter: 1. הפומפיה (the grater in hebrew) 2. עדכונים שוטפים על ידיעות חדשות בדף ויקיפדיה:חדשות (ongoing updates about new issues on wikipedia:news) 3. Sorry, what do you mean in home page? I should create something here in mediawiki? In which namespace? 4. User:IKhitron Thank you very much.
Hi @IKhitron, thank you for your interest. There is one problem: interwiki prefixes like he:project:news are not supported yet (see phab:T174664). I recommend you to wait until that is solved. Also, the idea of "migrating later to Hebrew Wikipedia" is not clear either (phab:T110645 is where we discuss interwiki / multiwiki support). Would it be an option for you to start testing in https://test.wikipedia.org/wiki/Special:Newsletters? I'm sorry for not having better answers currently.
Hello, Qgil-WMF. I think I did not explain myself well. I do not talk about an hewiki newsletter, but a mediawiki one. Local. It's issues will be wikilinks to hewiki in regular wikicode, that's all. There isn't something that doesn't allow to create it just now. And I did not talk about technical migration. One day when the extension will be deployed on other wikis, we'll ask the subscribers to subscribe once more, locally. So, could you do this now, please? Thank you very much.
N3 Thanks for phab link, I don't need it, because I don't need interwiki service, as I said.
> It's issues will be wikilinks to hewiki in regular wikicode
This is not supported now. The extension will not accept a syntax like "he:project:news". This is exactly what phab:T174664 is about.
Maybe I did not understand, Qgil-WMF. But I still think we are talking about different things. I'm not talking about interwiki link in notification - there will be regular mw:homepageofnewsletter#something link there. If somebody clicks and comes to this page, they'll find the interwikilink there, in the text (of the issue), on regular wikitext content model page. Thank you.
Alright, sorry, now I understand. The main page is required. It is where you explain what the newsletter is about so users can decide whether they are interested in subscribing, and any other details you want to add. Newsletter issues point to pages, and they don't take into account #sections. In wikitext pages sections are pure representational, and things are prone to go wrong if someone edits the sections (as opposed to renaming pages, which by default leaves redirects). A simple option would be to use Flow topics for new announcements, from the discussion page of the newsletter main page. Each Flow topic is a page indeed.
Thank you. Very well, Qgil-WMF. Looks good for me. So the main page could be the flow border, and subscribe button will be added to the description, or I need a wikitext page as the main one and flow page for issues?
You need a main wikitext page, otherwise you will not have a discussion page to refer to. :)
Great. So, I'll create a page and ask to convert its talk page to flow. So, it's the same question I asked at the beginning: In which namespace should I create the main page? I don't know this wiki structure. And "User" is not a good idea. Thank you very much.
A page in the main namespace is ok. You will get the Flow page automatically. There is no need to request anything.
Thank you for your kind recomendations. Done.
Could you, please, create a new newsletter:
- (the grater in hebrew)
- עדכונים שוטפים על ידיעות חדשות בדף ויקיפדיה:חדשות
- (ongoing updates about new issues on wikipedia:news)
Thank you very much.
Thank you very much.
Sorry for the time I spent you.
- I think you can make a summary of our conversation (flow, main namespace and much more) and put it on the project page, so these questions will not be asked every time.
- You thought I'm talking about interwiki newsletter at the beginning. I didn't. I didn't even think it's possible, otherwise you would not deploy this extension on any wiki, even here on mediawiki. Just once on meta, and it could be enough for all wikis.
- But all this made me find a bug in Flow: it does not work well on Timeless. So it's an adventage. :-)
Thank you again.
Congratulations to all those who made Newsletter possible. Looking forward testing and trying to better the extension. Regards.
Extensions that were hosted in SVN
Links to the old SVN repo are broken and just redirect to Phabricator in a rather unhelpful way. And apparently some extensions were never migrated out of there in the first place (example). List of things that probably need to be updated:
I suppose there is not much chance for the mapping from SVN to git project names to be deterministic?
Broken list at Manual:Hooks/UploadVerifyUpload
Can anyone check why the list at Manual:Hooks/UploadVerifyUpload#Details is broken? The $props element is where the list becomes broken
Should be fixed. Looks like there were zero-width characters immediately before the last four asterisks.
Proposal for a developer support channel
The Technical Collaboration team proposes the creation of a developer support channel focusing on newcomers, as part of our Onboarding New Developer program. We are proposing to create a site based on Discourse (starting with a pilot in discourse-mediawiki.wmflabs.org) and to point the many existing scattered channels there.
This is an initial proposal for a pilot. If the pilot is successful, we will move it production. For that to happen we still need to sync well with Wikimedia Cloud Services, Operations and the Wikimedia technical community.
Please check the plan and share your feedback.