Project:Current issues

Jump to: navigation, search
This page is for discussing issues related to site. To get help with MediaWiki software, ask on Project:Support desk.
An archive box Archives 

Current issues archive overview

Start a new discussion
First page
First page
Previous page
Previous page
Last page
Last page

Adding a dev namespace for "Data and developer hub" articles

(Please read for some background on this project.) The articles for the new API:Data and developer hub are currently in the API: namespace. I would like the pages to be in a new dev: namespace. Here's why:

  • They will render by default using a different skin, "Blueprint" (see it on the prototype). The easiest way to show articles with a different skin is using Extension:SkinPerNamespace.
  • I want to use Flow on all the talk pages of these articles. The easiest way for this to happen is by setting $wgFlowOccupyNamespaces to this dev namespace.
  • It's mildly useful to be able to search only these pages.
  • The existing namespaces don't fit articles "to encourage third-party developers to use our data and APIs".
    Different audience: "a technical manual for the MediaWiki software. It contains information for developers and system administrators on installing, managing and developing for the MediaWiki software."
    Close, and it's what I'm using for articles to start, but an article like API:Recent changes stream is not about the MediaWiki API.
    Main (default) namespace
    proliferation of articles, hard to search.

Note the motivation to use a different skin and an easier discussion system (Flow) is that the Data and developer hub focuses on third-party developers who are not MediaWiki hackers or wiki editors. (Of course we hope some will align with our cause and contribute to our projects.)

None of these are definitive, but they lean towards creating a dedicated dev: namespace. I'm interested in technical alternatives for the first (e.g. use Extension:SkinPerPage instead, or use SkinPerCategory logic to set a different default skin). You can comment here or in phab:T369.

SPage (WMF) (talk)02:35, 25 June 2015

I agree, seems the best option.

Ciencia Al Poder (talk)09:23, 25 June 2015

If this is for documentation/discussion relating to the API, then why not stick with 'API' as the namespace? I think 'dev' is going to be a very confusing name, as the vast majority of this wiki (across all namespaces) could come under the category 'development'. Or 'developer'. Or whatever 'dev' stands for. And what would happen to the existing content in the API namespace?

Also, I am not sure what the purpose of an alternative skin is. Isn't that confusing, to have different parts of the site look completely different? If I'm browsing the site in Monobook, say, and then click a link to this new namespace, then I would assume I was on a different site. Doesn't seem very user-friendly to me.

HappyDog (talk)10:03, 25 June 2015

Yes, I don't know why change the skin. That would be rather unexpected and shocking to a user from that reaches one of those pages from RecentChanges or a link from another page.

Ciencia Al Poder (talk)14:56, 26 June 2015

The dicussion about the namespace is still open and we can evaluate the implications of using "API" instead of "Dev".

About the different skin, the starting point was to create an own site with own look&feel, following the example of most API/developer sites versus their products. The intention was to avoid Vector's outdated look & feel and's fully charged sidebar wiith links that could be definitely confusing to third party developers not interested in MediaWiki itself or in contributing patches.

While I was among the very determined advocates of improving instead of creating a separate site, I agree with the original problem. While using "a different skin in a same site" might confuse to some, I think the confusion and loss will be higher and more expensive if we stick to the current interface.

In fact, I think this exercise might be useful to sanitize and improve's UI. For us regular users it is easy to become blind to the problems it has, but this project is all about reaching out to new developers and engage them in the use of our APIs (which can lead to other type of contributions over time).

Qgil-WMF (talk)13:48, 27 June 2015

Here's how I think this should work:

  • Use the existing API namespace for this.
    1. The name is clear and unambiguous, unlike 'dev'
    2. A new namespace leaves the question about what to do with existing API pages - move them (in which case the API namespace will end up empty, aside from redirects) or leave them (in which case we will end up with pairs of similar articles in different namespaces). Neither of these seem like a good outcome.
  • Create an appropriate hub page (if it doesn't already exist) which is the focal point for this new sub-site.
  • Use this as an opportunity to improve the content of that namespace as well as adding whatever other API-consumer-related documentation is appropriate. I am comfortable for the API documentation to be written with a focus on third-party use, rather than an MW developer focus.
  • If there are pages in the API namespace that are not appropriate to be there, then they can be moved.
  • I can sort of see why you want a separate skin, but I don't really agree with it, and I'm not sure how well it would work in practice. Unless you plan to ban internal links to other namespaces (including links to user pages), there will be plenty of places where users will 'break out' of the skin, which will be confusing for the third-party users, as much as it will be for the MW regulars who suddenly find their skin changing as they navigate the site. Perhaps a useful compromise would be to use the separate skin for anonymous (non-logged-in) visitors only. Would that work?
HappyDog (talk)14:54, 27 June 2015

I've just been having a play with the proposed skin, and to be honest it leaves me a bit lost.

  • I couldn't find any way to get to a discussion page.
  • I eventually managed to find the edit/view history links, which are hidden away. Not sure I like the fact that editing/involvement is being discouraged in this way.
  • A lot of the features I am used to (edit section, add to watchlist, save as PDF, etc.) I couldn't find at all - I assume they have simply been removed to make things 'cleaner'.

Having had a play with the skin, my feeling is that there is possibly a third approach, which might satisfy the two different camps (the people who basically want a static website that is easy to use and navigate, aimed at third-party consumers of the API vs. the people who want editable online documentation, and for it all to be in one place).

My revised suggestion is the same as what I wrote in my previous post, except that the whole skin business is abandoned - the pages are part of, and remain in the site skin in the same manner as all other pages on the site. Then, in addition to this, a separate site is set up, using a variant of the new skin, which pulls it data from the API namespace of MediaWiki and presents it in a static format that is very friendly to third-party consumers. The new skin would be broadly like the prototype, with a couple of changes:

  • There is no functionality related to editing, logging in, etc. except insomuch as is appropriate in relation to the next point
  • There is a clear notice (possibly as part of the header, or possibly as part of the slide-out menu) saying this content comes from - "to edit, discuss or otherwise contribute to it click here".

Obviously, there are details to be worked-out, but what do you think of this approach?

HappyDog (talk)15:12, 27 June 2015

I'm not convinced (at all) about the idea of a separate site that will bring extra work and extra maintenance. Still, do you have any idea of how this would work and how much effort should be put to build it? My instinct says that I'd rather put that effort improving Blueprint skin.

Qgil-WMF (talk)17:07, 27 June 2015

Hi HappyDog, thanks for engaging with us about this.

  • a separate site is set up, using a variant of the new skin, which pulls it data from the API namespace of MediaWiki and presents it in a static format that is very friendly to third-party consumers
    That sounds like! It's read-only and limited functionality, and I Special:Import content to it. The idea of configuring a separate site in production so that a single set of content can live a second lifestyle at a different host is intriguing and might have wider applicability for special sites like Wikimania, annual reports, etc., but I have no idea what the engineering challenges are. Maybe it's been done, before my time. :)
  • I don't think it's a problem for new developers to encounter different skins. They'll already switch skins when they follow a link to or out of the API (or dev) namespace.
  • We could develop logic to not show existing users the Blueprint skin. Obviously "if user's skin is not default, then no Blueprint", maybe "if user is logged in, then no Blueprint" (this sounds like SkinPerNamespace's $wgSkinPerNamespaceOverrideLoggedIn = false), maybe a hidden preference or session variable to identify new visitors, or a definitive "Never screw with my skin choice!!" preference. But it's complex logic that will never catch all circumstances (e.g. long-time user browsing MediaWiki anonymously). I don't think it's the end of the world if a long-time MediaWiki user is exposed to a new skin on a few dozen pages targeted to a different audience.
  • Perhaps SkinPerNamespace is the wrong idea. I would like to see the OOUI living style guide moved to (phab:T93610) for similar reasons, but then we would want two different Blueprint sidebars, so two different namespaces, ... it doesn't scale. I will investigate extension:SkinPerPage and explore an explicit <skin sidebar="ooui-lsg">Blueprint</skin> in pages.
SPage (WMF) (talk)04:43, 2 July 2015

I can see the benefits and consistency of using the API: namespace as you propose, combined with and a central focus on web API documentation. The more precise but also narrower "API" meme leaves aside datasets, websockets, and what not, but as you say we could always highlight related technologies in the main page and wherever it is appropriate. It's not that the "Dev" meme doesn't bring its own inconveniences, so we will need to evaluate both.

About the skin, I would like to ask for a chance to try it, with a plan for a quick revert if needed. The risk of user confusion is theoretical. Users deal with changes of UI by clicking links all the time. They might be confused or satisfied depending on many factors. The deployment of this extension in as an optional skin has its own benefits, and would get us more feedback from users willing to give it a try.

Blueprint skin has some virtues and some problems. The possibility of being deployed in a production server contributes to highlight the serious problems and work on them. The lack of Discussion link is a known bug that I just set as blocker of the deployment of this extension in If we (and that includes you) find more blockers, we will add them. Just find/create specific Phabricator tasks to discuss them.

Qgil-WMF (talk)17:05, 27 June 2015

I have no objection to the new skin being enabled as an optional skin on, for those who want to try it out.

I think there would be a lot of objections (from me and many others) if it were made the default skin, even if only for anons and/or new users.

I don't know what other people think about it being the default skin for a single namespace, but I've already made my feelings known on this.

For me, the biggest risk of confusion is the skin changing randomly as you navigate within the site. As you say, confusion within the skin itself is something that can (hopefully) be resolved by further user-testing and development. You also need to balance the ease of use for new users against the disorientation and confusion for existing users, but in most cases this can be mitigated by the fact that users can pick their own skin.

HappyDog (talk)19:02, 27 June 2015

As commented here, it might make sense to have separate discussions to simplify this complex discussion:

  1. Literally Deploy Blueprint on as optional and experimental skin, which is useful to find technical blockers before the deployment and more testers after the deployment.
  2. Implement a namespace in to host the developer hub, leaving aside the skin discussion, focusing on which namespace (renovating Api:, creating Dev:, or else).
  3. IF Blueprint is heading to AND the namespace plan is clear, THEN discuss the combination of skin and namespace.
Qgil-WMF (talk)09:30, 3 July 2015
  • I don't like the name "dev" for the namespace. I don't have any better suggestions, but dev is super confusing.
  • I think this could maybe conceivably fit in the API namespace, but a separate namespace also sounds fine to me provided there is some clear criteria what does and does not belong there.
  • I'm not really all that much of a fan of the Blueprint skin. More importantly I don't like the idea of half the site looking different.
    • I don't really understand the reasoning behind wanting a different skin. "Note the motivation to use a different skin and an easier discussion system (Flow) is that the Data and developer hub focuses on third-party developers who are not MediaWiki hackers or wiki editors" is not very convincing. How does having a different skin make it any easier for these users.
Bawolff (talk)10:01, 3 July 2015

API:Showing_nearby_wiki_information vs might look basically equivalent to regular users of because we are used to Vector skin and the dozens of extra links in the header and sidebar (to which we are effectively blind by now). However, for new users interested only in the Wikimedia API and landing directly in one of these pages... most of those 36 links (I counted) will contribute between noise and confusion, on top of the outdated look of Vector.

Considering that most users don't land lightly in Api: namespace, and those who land there probably also land in (which has a completely different UI), I think that offering a good experience to these new developers is better than risking a bit of confusion to some users. And I still claim that such confusion is more theoretical than practical, which is why I'm proposing to run a test with a big button to revert.

Qgil-WMF (talk)11:07, 3 July 2015

Add user page speedy deletion reasons

Hi all, I inform you that I've started a discussion in order to add some additional speedy deletion reasons for user pages. Discussion is here: Project talk:Deletion#More speedy deletion reasons. Regards.

Syum90 (talk)07:10, 1 July 2015

Error on 'mwlib' server

A thread, Thread:Project:Current issues/Error on 'mwlib' server, was moved from here to Project:Support desk. This move was made by Ciencia Al Poder (talk | contribs) on 1 July 2015 at 12:16.


A thread, Thread:Project:Current issues/mediawiki最新版1.24.2在windows下无法上传带有中文的目录文件名, was moved from here to Project:Support desk. This move was made by Ciencia Al Poder (talk | contribs) on 30 June 2015 at 15:28.

Collection 1_25 download link not working

This link does not work. The file is missing from that location. Other extensions at the same location have a version 1_25, but Collection 1_25 does not., 12 June 2015

I just checked the link and it now works., 24 June 2015

MobileFrontend and Mantle problem

A thread, Thread:Project:Current issues/MobileFrontend and Mantle problem, was moved from here to Project:Support desk. This move was made by Ciencia Al Poder (talk | contribs) on 11 June 2015 at 09:47.

Proposal to convert LiquidThreads discussions to Flow

There is such a proposal, see [Wikitech-l] Starting conversion of LiquidThreads to Flow at This is the place where consensus for changes is checked, hence I'm opening the discussion here.

Also, some users have already started disabling LiquidThreads on some talk pages to use wikitext instead: what to do? Should that be done on more or less pages?

Nemo09:37, 18 March 2015

LiquidThreads was an unmitigated disaster, in my view, and has made the site worse for being here. History before it was enabled was lost (or, at least, very hard to find) the links in e-mails never take you to the thread they're supposed to, the UI is horrible and it is difficult to find things you are looking for. It actually makes the site harder to use for anyone at all experienced in wikis, not easier, and so should never have been enabled.

I haven't used Flow, so I don't know how it compares, but I would certainly vote for removing LiquidThreads! If Flow actually works in a wiki-like way (i.e. you can view history, see the state of the page before it was enabled, edit comments where necessary, etc.) then I might be persuaded that it is a good replacement, but given our experience with LiquidThreads I am fairly sceptical. For it to work it would have to be something that works inside existing wiki pages, rather than fighting against them. It would also be a requirement that all LT content can be 'migrated' to Flow so that it is not lost or broken. It is not acceptable for it to simply be shunted off to an 'old threads' namespace and abandoned - it needs to appear where it was originally posted.

The issue is as much about how the extension works behind-the-scenes and how well it integrates with the rest of the wiki, as about the interface it provides.

For example, I don't want to lose my current talk page, nor its history. If what is there can be converted seamlessly to Flow, without losing my ability to view old revisions of the page (pre-flow and post-flow), archive things in the way I have done in the past, include some non-thread-like content (e.g. introduction section) and link to specific items without the links breaking as items change (e.g. if they move to 'page 2' of the listings) then it might be viable. Otherwise, please just remove LiquidThreads and don't mess up the wiki with further incompatible plugins.

HappyDog (talk)10:09, 18 March 2015

PS - From reading the wikitech-l post, it looks like once again this is a decision being forced upon us without any kind of local consensus. should not be treated as a test site, without community buy-in. If you want people to be antagonistic towards Flow, and to resent its presence on the wiki, then that is a pretty good way of going about it.

HappyDog (talk)10:11, 18 March 2015

Also, I didn't realise quite how experimental/incomplete Flow currently is. Therefore, my vote is (for now at least) a firm no!

The comment from Risker/Anne sums things up pretty well, as far as I'm concerned.

Please just remove LiquidThreads and come back to us with a proposal for Flow when it is out of beta and feature-complete.

HappyDog (talk)10:15, 18 March 2015

Please no back to plain wikitext talk pages, at least for talk pages with hundreds of posts (like Current_issues and Support_desk). Wikitext talk pages are terrible to follow and archiving is as bad as the wikitext discussion format itself. I prefer LQT (in it's fairly bad state) before wikitext, but i welcome a move to Flow, after it is in a workable state (see, e.g., this mail).

See also[edit | edit source]

So, from my side: Support Support

Florianschmidtwelzow (talk)11:42, 18 March 2015

Is it possible to have a complete list of LQT pages on this wiki? That would help the discussion.

Certainly it makes sense to use modern discussion software on Project:Support desk, as that is a high-traffic forum-style page which is aimed at IT professionals and server administrators more than wiki users.

This, that and the other (talk)00:14, 19 March 2015

I agree that for the support desk, and maybe a couple of other support-related pages, a more forum-like approach is sensible.

However, one does have to question why we use the wiki for these purposes at all. We don't use the wiki for internal issue tracking, so I'm not sure why we are using it for support. I am not aware of any other company or open source project that would consider using a wiki for handling support issues - it is clearly the wrong tool for the job.

Perhaps a more sensible solution would be to use support desk software for handling the support desk, rather than trying to shoe-horn non-wiki-like tools into the wiki, which will inevitably bring unsatisfactory results (as has been shown with LQT).

HappyDog (talk)12:05, 19 March 2015

FWIW, there was such a proposal too: phabricator:T31923.

Search is pretty good at finding LQT talk pages: [1].

Nemo14:02, 19 March 2015

Special:PagesWithProp also works. [1] - currently LQT is on 1,639 pages - (I'm not sure why that number differs (1,567) from the search that Nemo linked?)

Re: existing posts - currently 52,526 individual posts. Of those: 24,897 of those are in Project:Support_desk; 1,269 in VisualEditor/Feedback.

I'm asking devs for help getting a more detailed listing of All pages ordered by size (number of posts).

[Update: A list of all pages with more than 10 posts, is now at phab:P417, and converted into an onwiki page with links at Flow/LQT pages.]

Quiddity (WMF) (talk)21:15, 19 March 2015

The Flow/LQT_pages are interesting, thanks. Just for fun I looked at the even (non-talk) namespace numbers: One entry in 90 might be odd (3 contributions counted as 12), and for the Project:Forum redirect I didn't get why it's counted as 94.

Be..anyone (talk)12:24, 20 March 2015

So far, after HappyDog has questioned the existence of Project:Support Desk, I didn't see a single person defending it. It looks like we're ready to wrap it up?

Once the page is converted to Flow, AFAIK we can just fully protect it (the board) and add two big buttons to the header, linking existing support venues (i.e. StackExchange and mediawiki-l).

Nemo10:54, 3 June 2015

Well, I'd defend it, but I'm not sure how to bring that in a task that aims to "Install Q&A system at". I'm still expectant to see what would be the resolution. What I'd say for now is that I don't have an account in stackexchange and I don't plan to help there.

Ciencia Al Poder (talk)19:53, 3 June 2015

Thanks for speaking up.

Nemo07:23, 10 June 2015
Once the page is converted to Flow, AFAIK we can just fully protect it (the board) and add two big buttons to the header, linking existing support venues (i.e. StackExchange and mediawiki-l).

Surely making a decision is dependent on the resolution of phab:T31923? No point doing any of that (freezing, redirecting, etc.) until a decision has been made about what those support venues are? Doesn't really affect me as I neither use nor curate it, but it feels a bit like you're putting the cart before the horse.

HappyDog (talk)20:56, 3 June 2015

Well, as far as I can understand, having the support desk converted would break the currently expected workflows (e.g. the moves described in its header?). The path of least resistance seems to be the consolidation of existing venues rather than the creation of a on-wiki support desk with a new discussion system.

Nemo07:27, 10 June 2015
Edited by another user.
Last edit: 07:14, 24 March 2015

Note: We'll be holding an IRC office hour for Flow, this Monday at 19:30 UTC / 12:30 PDT. You can find information on how to get online, including a link to a webchat option if you don't have an IRC client, on the meta office hours page. The intended focus is for questions about the LQT -> Flow conversion here. Everyone is welcome for discussions and question answering. Logs will be posted on the meta office hour page afterwards. Thanks.

Quiddity (WMF) (talk)02:29, 21 March 2015

Few minutes of testing were enough to discover that

WMF, please ensure you table such proposals only after you've thoroughly tested the conversion. Thanks.

Nemo07:11, 24 March 2015

I don't know if it's just an unfortunate coincidence, or what, but since this announcement, the usability of LQT has degraded a lot...

First I reported that submitting a reply doesn't display the reply unless you refresh the page (task T93374).

Today hitting "show preview" displays a confirmation dialog about leaving the page, and if you proceed, you end up submitting an edit to the underlying page and not on the message you was editing!

PD: Reported as task T94089

Ciencia Al Poder (talk)10:57, 26 March 2015

Where to discuss broaders template issues? A Phabricator tag ?

Note phab:T101362 A #Templates tag for tasks related with creating/fixing MediaWiki templates?

When I'm making changes to templates in API docs, or deciding how to move source code links from to diffusion, I'm not sure how to broaden the discussion beyond a particular template's talk page. Is this a good forum for it? Would a phabricator task help or make it worse?

(I'm a technical writer at the WMF, hi!)

SPage (WMF) (talk)20:01, 5 June 2015

A forum on the wiki where those templates are would be a good option, since it's a change that affects the wiki. For me, raising such issues here (Project:Current issues) would be fine. But that's just my personal opinion :)

Ciencia Al Poder (talk)11:12, 6 June 2015

Long term support release #2

There it is again. Since the release of the 1.25.0-version the 1.24.2-version is marked as LTS version again on the download page. This has happend already in September 2014 when 1.24.0 was launched. Someone stated, that 1.27.0 is going to become a LTS version and not 1.24.0. (

Wgkderdicke (talk)19:04, 25 May 2015

I've edited Template:DownloadMediaWiki to fix that. I hope it's now correct. Someone needs to mark that version for translation, though

Ciencia Al Poder (talk)19:37, 25 May 2015

YesYDone Marked for translation.

Florianschmidtwelzow (talk)05:28, 26 May 2015

error: rendering process died with non zero code: 1


Has anyone had seen this error before while converting/rendering

an assembled book in to pdf ?


Tim.claessens (talk)07:17, 15 April 2015

Yes, it's rather common. It can have several reasons, so it's best if you mention the specific page which is giving you the error.

Nemo07:18, 15 April 2015

I have tried at least ten times and it is giving same message. Page address: Book: Optical illusions - Wikipedia, the free encyclopedia

Tejasvi Singh Tomar (talk)10:49, 14 May 2015

That's covered in phab:T94308

AKlapper (WMF) (talk)13:15, 25 May 2015

Gitblit replication of gerrit has stopped.

Hi please see about gitblit replication of gerrit not working. Please fix it., 24 May 2015

i can't install mediawiki on my webserver please help me

A thread, Thread:Project:Current issues/i can't install mediawiki on my webserver please help me, was moved from here to Project:Support desk. This move was made by Ciencia Al Poder (talk | contribs) on 20 May 2015 at 09:25.

[RESOLVED] Delete user page on MediaWiki

I came across the page User:Lil Jay Rap Legend when cleaning up images on Commons. This user page is clearly for promotional purposes only and entirely inappropriate to the purpose of this wiki. I couldn't find any deletion process here on MediaWiki, so I'm requesting here to have the page User:Lil Jay Rap Legend deleted. --

P199 (talk)13:02, 13 May 2015

Already deleted by @Stemoc:, but for the future: We have {{speedy}} and {{delete}}, too :)

Florianschmidtwelzow (talk)13:16, 13 May 2015

Thank you.

P199 (talk)15:13, 13 May 2015

Link to list open tasks from the extension's page displays both open and closed tasks

The link to list open tasks from the extension's page, displays both open and closed tasks. See for example Extension:UserMerge, which links to [1].

That's because now in phabricator, the project page goes to the workboard (see task T89865).

Is there any other viable URL that we could use to link to all open tasks of a project? All searches give ugly URLs without a project name on them, just numeric codes or similar.

Ciencia Al Poder (talk)18:39, 27 March 2015

FriedhelmW (talk)12:12, 28 March 2015

That doesn't work. It lists open tasks, but doesn't filter for that extension.

Ciencia Al Poder (talk)10:51, 29 March 2015

I think there is no such feature any longer: the only option would be the advanced maniphest search, but the projects selectors don't accept strings, only PHID* variables.

Maybe there is a way to get all the PHID numbers or the project description URLs for all projects, we could then store them in a switch.

Nemo13:01, 29 March 2015

As Nemo says. If you want to get a PHID of a project (e.g. Flow): Go to , enter ["Flow"] in names, get PHID-PROJ-ntg6sf6mfl2qm2e4qgxc.

AKlapper (WMF) (talk)10:13, 1 April 2015

The workboard view is not the problem itself. Showing also closed tasks by default is the problem and will get fixed by the next update: phab:T90661.

AKlapper (WMF) (talk)10:12, 1 April 2015

The current situation has become even worse. Now those links lead to a 404 ERROR page!

Ciencia Al Poder (talk)09:20, 12 May 2015

I've just discovered that to make those URLs to work, the tag name must be lowercase (!)

I've edited {{Extension}} and {{Ptag}} accordingly, which should fix those links. Still, the links go to the workboard instead of the project page.

Ciencia Al Poder (talk)09:28, 12 May 2015

Problem in html2wiki

A thread, Thread:Project:Current issues/Problem in html2wiki, was moved from here to Project:Support desk. This move was made by Ciencia Al Poder (talk | contribs) on 8 May 2015 at 01:45.

Cannot edit talk pages

Something claiming to be an "IPA phonetic alphabet" popup intercepts my keyboard input (skin Monobook, browser Chrome, visual editor off, template data on, no other tricks). It also happens here, I cannot add the colons required for indentation, it appears as some gibberish. I cannot add < (more gibberish).

Be..anyone (talk)11:20, 4 May 2015

This is the stupid Universal Language Selector IME, the little keyboard icon that appears next to the textarea (when the textarea is focused), that has a shortcut-key for switching keyboards.

Click on that keyboard and change the input method to native.

Ciencia Al Poder (talk)01:56, 5 May 2015

Thanks, presumably I somehow managed to input a key combination switching it in an undesired position, and surviving a "restart browser" in that position. I certainly didn't open it, until I figured out that this helps to reset "native keyboard". Is there a way to get rid of it completely? I can barely guess what IPA tries to express in very simple cases, I'll never need to input it.

Be..anyone (talk)06:46, 5 May 2015

Pressing Ctrl+M toggles on/off.

FriedhelmW (talk)17:29, 5 May 2015

Thanks, I think I found a more permanent solution on Disabling the tool for your user account hopefully good for all browsers and all Wikimedia projects:

  • Skip the "from the sidebar" blurb (I failed to grok it, maybe it is for Vector)
  • Interpret "from the Keyboard menu" as…
    • click edit on any page that can be edited
    • click on the input method icon directly below the input area at the end of the row (right side for LTR)
    • click on the last entry in the popup with a tool icon
    • click disable IME everywhere, click on apply, ready.

No idea how I ended up to opt-in to this feature, presumably I was curious as always and forgot it.:-(

Be..anyone (talk)08:59, 7 May 2015

Special:SupportedLanguages restored

Nikerabbit just put an end to the painful wait! Now the special page works again; you have to open a specific subpage to see usernames. Example: Special:SupportedLanguages/it.

Nemo15:14, 23 April 2015

Great ! Kiitos Nikerabbit :)

~ Seb35 [^_^]10:07, 26 April 2015

Topic talk:Sewfq489tp3iic43

Hi, I've no idea what Topic talk:Sewfq489tp3iic43 is, either a weird name in the main name space, or a weird talk page for a namespace not needing any talk pages at all, but it's definitely unrelated to Topic:Sewfq489tp3iic43, please move it without leaving a redirect.

Be..anyone (talk)03:16, 11 April 2015

Move to what place? You're the author of the talk page: Is it really needed, or maybe it can be deleted? How you created these talk page? :/

Florianschmidtwelzow (talk)10:14, 13 April 2015

It's an experiment, I tried to figure out why an existing Topic:Sewfq489tp3iic43 contains a red link to itself, and is actually always shown as red link. Additional test:

Quick namespace test
Namespace Talkspace
  90 Thread pages   91 Thread talk pages
 100 Manual pages  101 Manual talk pages
2600 Topic pages 2601 pages

Apparently there is no "Topic talk", the experiment ended up as article. JFTR this bogus article could be moved to Thread_talk:Project:Current_issues/Topic_talk:Sewfq489tp3iic43, as entertainment for the folks migrating Liquid threads to Flow, apparently namespace 91 is empty at the moment. But the red Topic:Sewfq489tp3iic43 is really wrong, it exists.

Be..anyone (talk)15:10, 13 April 2015


Florianschmidtwelzow (talk)11:21, 15 April 2015

Manual thanks, I miss the tnx-button whenever it doesn't show up—IPs, bots, liquid threads, … smile

Be..anyone (talk)23:47, 16 April 2015

np :) Yeah, Flow would be better, just because you can thank another user for a post :D

Florianschmidtwelzow (talk)13:17, 17 April 2015

Is down? I tried to look in the irc logs for mediawiki/mediawiki tech and search here, but could not find anything about it...?

Christian75 (talk)18:36, 14 April 2015

Cannot start a new discussion in support desk

I've been trying to start a new discussion in the support desk but when I click on 'Save Page', my browser keeps reloading the Support desk page in editing mode with my post still inside the editor and not yet posted in the discussion.

(and apparently I can post here without a problem)

Using OS X Yosemite10.10.2. Tried Google Chrome 41.0.2272.118, and Safari 8.0.4.

Genesishana (talk)11:28, 14 April 2015

It's completely broken script hell, Chrome never knows what the URL is, what the state is (crying "don't leave unsaved page" long after it was saved), wild guess, was your attempt over a slow/shaky connection? Maybe test a Thread:Project:Support desk/Cannot starting a new discussion in support desk/reply to figure out what's wrong.

Be..anyone (talk)12:04, 14 April 2015

It wasn't over a slow or unstable connection. It seemed to be related to the inclusion of external URLs, you can see my various experiments in the edit history found in Thread:Project:Support desk/Cannot starting a new discussion in support desk/reply

I was able to modify my original MediaWiki issue by eliminating the http:// part of the URL to my wiki and I was able to post successfully.

But yes, totally broken script. I've been getting those "don't leave unsaved page" prompts more often now.

Genesishana (talk)14:44, 14 April 2015
First page
First page
Previous page
Previous page
Last page
Last page