Per [[m:Global bans]], I am notifying the project of this proposal. Everyone is welcome to go and voice their opinion of the proposal and about the user in general.
Project:Current issues
About this board
This page is for discussing issues related to MediaWiki.org site. To get help with MediaWiki software, ask on Project:Support desk.
 Archives
|
Previous page history was archived for backup purposes at Project:Current issues/LQT Archive 1 on 2015-07-10.
Neither has the named user (Tobias Conradi), nor has the sock puppet (Helmut_Schönberg) contributed to mediawiki.org, so there shouldn't be a need for this notification :)
See Special:Contributions/Tobias Conradi~mediawikiwiki, which is blocked here.
Sorry, haven't seen, that the username is given to another user on mediawiki.org :) Thanks for linking to the correct one!
Hi! Please, create the messages:
- MediaWiki:Mw-contribute/uk with this text:
Взяти участь - MediaWiki:Mw-wikimedia-engineering/uk with this text:
Інжиніринг Вікімедіа - MediaWiki:Mw-sandbox/uk with this text:
Пісочниця - MediaWiki:Mainpage-text/uk with this text:
Головна сторінка
And change the text in :
- MediaWiki:Mw-faq/uk to
ЧаПи - MediaWiki:Mw-discussion/uk to
Поточні питання
Done Sorry for the looong delay and thanks for the translations!
Finally :) Thank you very much!
Tuesday 2015-09-01T18:00 UTC (11am San Francisco time) we will be having an IRC office hour about
- T105133 - Organize current and new content in the API: namespace at mediawiki.org
- T101441 - Integrate the new Web APIs hub with mediawiki.org
- T98897 - Deploy SkinPerNamespace extension on mediawiki.org
If you're interested in developing with, documenting, or promoting MediaWiki/Wikimedia APIs, you should attend. I hope by having a realtime conversation we can come to a shared understanding faster.
Hi everyone,
I'm not sure that this is the right place to ask, but I figure that someone here will know: I have an idea that I'd like to run past you all. One of the things that I do (and need to do more of soon) is make screenshots for help documentation. Especially for VisualEditor, there's a lot of this, and all of it needs to be produced in a couple dozen languages. The contents of the screenshots therefore varies a lot between languages, and also through the history of the page, as different people used different pages at different times.
What I'd like is a fake "article" or page that:
- contains only public domain images and CC-0 text,
- uses most of the core wikitext markup (bold, italics, sections, images, references, lists, tables, etc.), and
- could be translated into any language.
Do we have something like this already? Does anyone foresee any problems or have any advice if I create one?
This comment was hidden by Whatamidoing (WMF) (history)
This would create an accessibility issue because it's not actual text, but text within graphics. Screen readers can't read these, so this method isn't suggested :( Also, help pages are bound to be edited, so if you want to provide up-to-date information you'd have take another screenshot for every revision (or every 5 revisions per say?) These files would be bigger too than just actual characters (letters, symbols, numbers) which are a byte each, so performance is another issue.
It is an interesting idea, but I'm not sure what advantages this could have.
I think you've misunderstood. I don't want screenshots of the help pages; I want screenshots in the help pages. "Type the data in the blank field labeled 'TYPE HERE'" is easier for most people to understand if those instructions are next to a picture of a blank field labeled 'TYPE HERE' (and maybe with circles and arrows and half of a word typed there).
Most of my screenshots need to show Wikipedia-style articles, which means that I'm always creating different bits of articles just to make a screenshot (like this one). I was thinking that if I made a whole article, that nobody would have to keep creating bits and pieces.
We already have software that automatically takes screenshots in multiple languages. The problem is not having content.
I think a fake article is a good idea. And if it was on astronomy (mentioned elsewhere), you could look at NASA topics, such as https://www.nasa.gov/topics/journeytomars/index.html or https://www.nasa.gov/topics/solarsystem/index.html .
Still, I wonder if you're overthinking this. If the article is about a fake topic, where all the words are your own, then you don't have to worry about copyright issues. I'm not suggesting you spend a lot of time creating content - rather, that you modify an existing topic. And images from the Commons shouldn't raise any copyright issues.
So, specifics - I suggest using a Simple English article, not an article from the main English Wikipedia, as your base, because the translation should be easier. And, looking at the most recent "very good articles" - https://simple.wikipedia.org/wiki/Wikipedia:Very_good_articles - one jumps out (to me) as most useful: https://simple.wikipedia.org/wiki/Hurricane_Vince_(2005) . That's because the images for an article on hurricanes can all be from NOAA, and thus public domain. (There are actually three articles about hurricanes, of the ten listed; you could also use https://simple.wikipedia.org/wiki/Tropical_Depression_Ten_(2005) for some wording.)
Or, to return to your original idea, consider https://simple.wikipedia.org/wiki/Andromeda_galaxy - you can name your own galaxy, rather than your own hurricane.
I've started this at Help:Sample page and used it for a series of new screenshots that I added to Help:VisualEditor/User guide. I'm still sorting out what content will be convenient, but so far I think this is going to be a practical solution to my screenshot problems. Also, when I'm a little further along, I think it will need a re-write with Simple English in mind, as John suggested.
I think I'm going to need to import at least simple versions of a couple of popular template styles, so that I can show template uses in a page. Maybe a simple infobox and a common citation template would be sufficient.
Also some type of template that is normally subst:ed. The VisualEditor documentation shows a barnstar, which is not ideal for that context. (VisualEditor is usually disabled on discussion pages.)
I'm not convinced that template substitution is worth including; it is vanishingly rare in articlespace. But if you're determined, you might use <nowiki>{{No more links}}</nowiki>, as mentioned at https://en.wikipedia.org/wiki/Wikipedia:Substitution#Article_namespace .
I've added an old (non-Lua) copy of {{Cite journal}} for this project. I figured that, of the common types, it was the least likely to be (mis)used in other pages on mediawiki.org. I'm still thinking about an infobox. {{infobox person}} might work, since it's common, but there should be no use for that template in the mainspace. If someone has other ideas, then feel free to let me know.
Update: I think it's nearly done. I still need to add a non-citation template (probably an infobox) and maybe some computer code. If someone wants to make a "Hello, World" section with his or her favorite (and not too complicated, please) computer code, then that would be great.
It's just amazing how many fiddly little features VisualEditor supports these days. I need a template that doesn't display on the page. Something like Template:Use British English would work fine, except that it doesn't exist at mw.org. Is there anything here? I could always import it if that were necessary, but I'm hoping to find something that's already here/useful for other purposes.
Hi
I want translate FAQ page to persian but Translate this page message in top page not found.
Please help me.
Are you looking at Manual:FAQ?
There is such a proposal, see [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org. This is the place where consensus for mediawiki.org 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?
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.
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. MediaWiki.org 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.
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.
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
- Thread:Project:Support desk/Starting conversion of LiquidThreads to Flow at mediawiki.org
- Topic:Sdoatsbslsafx6lw
So, from my side: 
Support
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.
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).
FWIW, there was such a proposal too: phabricator:T31923.
Special:PagesWithProp also works. - 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.]
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.
I wonder why LiquidThreads Test Page isn't listed. I was about to say to not convert that page to Flow, but it doesn't appear on the list.
Was it skipped on purpose, or there's a problem with the query used to gather this information? A description of what conditions were used in the query, or post the query itself would help.
@Be..anyone: Thanks. I noticed the oddity of namespace 90 (Thread) even being included, because I had to manually turn the plaintext list into a wikitable (hence my update to Project:Namespaces). But I didn't notice the disparate numbers; I'll ask. I'll also ask the devs about the redirect.
@Ciencia Al Poder: The LiquidThreads Test Page is on the list! 283 posts. (I didn't cleanup the underscores (now done) which might have caused a ctrl-F to not find it). :) But I'll ask the dev who ran the query, if he could provide a copy from his scrollback.
Whoops! How did I missed the underscore thing? Meh, maybe because I have all links underlined by default, which makes the underscore virtually indistinguishable from a space. Sorry
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).
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 ask.wikimedia.org". 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.
Thanks for speaking 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).
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.
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.
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.
Few minutes of testing were enough to discover that
- T93723: Conversion to Flow eats content
- T93721: Links to LiquidThreads threads don't work after conversion to Flow
WMF, please ensure you table such proposals only after you've thoroughly tested the conversion. Thanks.
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
I'm a translator on translatewiki.net, translation administrator on Meta-wiki and a sysop on Ukrainian wikipedia (SUL). Can anyone with an administrator flag here finally fulfill my request below?
Hi all, I've created this filter in order to detect the removal of deletion templates by new users; in this moment this filter is capable to detect only deletion templates, but any kind of template can be added to the filter, so if you want to add a template to the filter just add it or request it to me. Regards.
Hi please unprotect this Skin:Metrolook and Extension:CollapsibleVector page. Since it was blocked because I was blocked but then I was unblocked and so there is no need to keep that page blocked.
WMF is changing its repository browser from gitblit (at https://git.wikimedia.org/) to Phabricator's Diffusion (at https://phabricator.wikimedia.org/diffusion/MW/). There's a dedicated project phab:tag/gitblit-deprecate/ for it. Note this doesn't affect gerrit as our remote repository of record.
So I've changed the sidebar link Development > Code repository to link to Diffusion. I apologize to the cabal in charge of site changes like this, I don't know who you are :) . Revert if there are problems, at the moment it's not critical either way. If you have issues with switching to diffusion, file a bug against project gitblit-deprecate.
(Related, T101358 is "Update {{git file}} to link to diffusion")
Reply to "Changing "Code slide shares
