@Jdforrester (WMF) Hi, I see you've reverted some changes with endashes. I think the use of them is correct here, because spaced en dashes are sometimes used between parts of list items. Please see en:Wikipedia:Manual of Style#To_separate_parts_of_an_item_in a_list .
Use of endashes
Did you mean to link to something there? These are not being used "between parts of list items", they're serving as title/descriptor separators. Spaced endashes are inappropriate hear as they're not linking like concepts, but I might be missing something?
@Jdforrester (WMF): Yes, sorry, the link has disappeared while I was using the Flow system. It's fixed now.
These titles and descriptors are exactly parts of list items, so use of endashes is appropriate. Please see the MOS definition and examples.
It's a choice-of-style-guide thing. If you follow the American AP style guide (hereinafter "the heretical work written by typography heretics"), then em dashes can be spaced. If you follow all true and proper typography guides, then em dashes are not spaced.
@Whatamidoing (WMF): I mean we shouldn't use emdashes here at all. Endashes are appropriate for lists.
I'm surprised that enwiki's MOS makes no mention of the best way to separate such elements, which is using a colon. Well-behaved dashes go about in pairs, like old-fashioned Catholic nuns, except when temporarily over-excited (e.g., the colash in "O that's an honest fellow: —do not doubt, Cassio") or occasionally when they're worried about causing confusion (the MOS example of
"The Future" – 7:21is a good one).
But, even if we all agreed that spaced em dashes were an abomination, the fact remains that the English Wikipedia's MOS is not binding here, and that trivial changes to translated pages create a disproportionate amount of work for translators. So even if you believe that it's unfortunate, it's usually best to leave punctuation alone on translated pages such as this one.
Could avoid dashes and colons completely if you used a definition list:
Where disappeared Content Translation? I don't see it among Beta Features.
Thanks for your answer.
Why we use Flow for feedback pages about each Beta Features
Recently @Nemo bis has indirectly asked why I insist on the feedback page for each Beta Feature being a Flow page, rather than the legacy talk page system that they prefer.
Briefly, the reasons are:
- Convenience for users, especially those having to respond;
- Scalability for lots of parallel discussions;
- Software-compatible way to mark threads as resolved (and un-mark when needed);
- Ability for individuals to subscribe to one thread; and
- Mobile compatibility.
I'm willing to discuss this further, especially with those who have new data to bring.
Flow has been removed from the English Wikipedia and now Meta-Wiki. It doesn't seem to be very popular. How many wikis are using Flow? I'm struggling to believe that <https://noc.wikimedia.org/conf/highlight.php?file=flow.dblist> is accurate.
My most recent gripe with Flow is that I've found the indentation/threading behavior aggravating and unintuitive.
I believe Nemo_bis refuses to use Flow at all, so he won't be able to engage or discuss here.
From my perspective if beta features were discussed on conventional talk pages, I'd be concerned about several things:
1) non-editors joining the conversation - wikitext does put off some users hence why we are building VisualEditor. Barrier for entry should be even lower here.
2) my team's ability to keep on top of all discussions. The archiving functionality is a life saver. it ensures nothing gets missed unintentionally; things get fixed; conversations happen in a single place rather than multiple places; things get tracked on Phabricator where necessary. Doing all this with a talk page is clunky and time consuming if you're not an advanced editor.
3) Mobile (editing talk pages is near impossible on mobile)
What exactly is seen as the problem with using Flow - what problems will the legacy talk page system solve that Flow doesn't?
The issue is more systematic than just beta features, so while my comments may be completely ignored because I'm an anonymous user and most beta features don't really work for "us" aside from the a/b tests, these comments might still offer a less biased perspective.
- Search - First architecturally speaking, a severe flow flaw is the fact that it isn't indexed in site search. This should really have been part of the MVP even if it required some hacks. For beta features it is important for people not to repeat the same feedback, and read related comments before submitting theirs. Funny that wikimedia itself has a similar feature request for phabricator developers (T883), highlighting its importance.
- Violates basic principles of usability design (https://www.nngroup.com/articles/ten-usability-heuristics/)
- Recognition rather than recall - the interface shouldn't ask for things it can get automatically. When someone reports an issue, the browser has access to the wiki, mediawiki version, the user agent, the user scripts installed, default gadgets, and more. Yet none of this is automatically added in structured fields.
- Error prevention - prevents errors by not requiring users to submit information that the wiki / browser already knows about
- Grouping - Lacks ways to manually group similar or near identical discussions, without leaving the interface (e.g category) .
- Ability to filter resolved discussions (with wikitext these can easily be collapsed).
Wikitext talk pages have even more severe flaws, yet their flexibility means that one can easily make use of headers to discuss similar topics, merge them, or even split them and move them elsewhere. It is very useful when discussing a problem to see different perspectives. Aside from user agent and ip, many user scripts aren't even private due to being added to common.js rather than being gadgets.
Finally, compare this to Wikia, who for example, is very consistent (community managers religiously ask people to submit bug reports to special:contact), and as an anonymous user I can submit feedback about any feature to them by using Special:Contact after testing the beta features activated in their testwiki. This is sent along with the browser and other info (added by a issue specific user-filled form) to wikia staff, who may eventually reply. According to them, registered users can even see progress of their report in a private issue tracker.
Wikimedia is very inconsistent about how it handles feedback, the contact interface in english wikipedia is different from ptwiki and probably many others. One way to improve this may be to improve the feedback interface, deploy the Extension:Contact and Extension:EnhanceContactForm to all wikis, and add a checkbox to submit potentially private information to either phabricator (for bugs) or flow (for other random feedback).
That being said, flow is by far more user friendly to newbies than wikitext-based talk pages (aside from the crippling lack of search functionality) that use even more arbitrary rules for indenting and posting.
Spread this page
I started to wikilink this page with other pages in order to make beta features central more popular. I add links to this page in beta features pages, every support on it would be great :)
I use English Wikipedia. Is there any calendar logging when features are added or removed to the "beat features" user menu?
I would like to have access to a record of when features are added, when they are removed, and the circumstances under which they are removed. I was wondering how many beta features become standard offerings, and how many are ended without being integrated.
https://www.mediawiki.org/w/index.php?title=Topic:Ss54yq1w3twctqsj looks like a better place for such a proposal ATM. Do you need me to copy/move your comment there? Thank you!
Hi there! I recently created a gallery featuring all of present and past features in MediaWiki. @Jdforrester (WMF), you asked in the comment why we listing these. It's kept for historical reasons and also to the this nice artwork in a one place. I also think that this gallery can suppress the Current Beta Features section, because it depicts every item in a better image way. Cheers! --~~~~
Though the pictures are indeed pretty, I'm not sure the gallery model works great for helping people scan the list of features quickly. Maybe. What do others think?
I think the gallery would be the good and simple way to distinguish every item easily.
As a visually oriented person, I really like this idea and implementation. +1. It's also similar to the idea I've been proposing for the Gadgets page, in Talk:Requests for comment/Redesign user preferences#Gadgets and elsewhere.
Please some example of beta features
Please some example of beta features