Topic on Talk:Flow Portal/Archive2

Also mentioned at mailarchive:wikimedia-l/2014-September/074206.html.

And what about maths? Are we going to be able to discuss how to format a particular mathematical equation and give examples of its use? The problems here is that VE maths editor project bug 43058 has only just started. A bigger problem is that there is a WONTFIX on the rollout of the mathjax renderer bug 36496, without that anysort of interactive mathematical editing is imposible.

+1

There is a functional <math> VisualEditor plug-in that lets you edit the LaTeX directly already in master (it's currently marked as "experimental" and so isn't available on the wiki unless the wiki is set to use that setting). Longer-term this will indeed be a graphical editor, almost certainly using MathJax, yes.

You can play with the code on this test page; we're evaluating what more it needs (beyond an icon!) before it's stable enough to switch on in production. Expect things soon. :-)

Nice, but the input box needs to be much bigger. We sometimes have very large multi-line equations say

$\operatorname{atan2}(y, x) = \begin{cases} \arctan(\frac{y}{x}) & \mbox{if } x > 0\\ \arctan(\frac{y}{x}) + \pi & \mbox{if } x < 0 \mbox{ and } y \ge 0\\ \arctan(\frac{y}{x}) - \pi & \mbox{if } x < 0 \mbox{ and } y < 0\\ \frac{\pi}{2} & \mbox{if } x = 0 \mbox{ and } y > 0\\ -\frac{\pi}{2} & \mbox{if } x = 0 \mbox{ and } y < 0\\ \text{undefined} & \mbox{if } x = 0 \mbox{ and } y = 0 \end{cases}$

I also get wierd interface errors if I have my preference set to math_png and try to edit the large equations.

Is this related to Jiabao Wu work or something different?

Yes, this is Jiabao Wu's work. I agree that there are some improvements for this before it's really ready, but I think it's close.

I understand that it is proposed, if not decided, that the Flow database will contain HTML5+RDFa only, and in that case it would not be able to store mathematics markup. The workaround proposed for that would be to put mathematics markup into some kind of scratchpad.

This seems less than optimal. There is an obvious necessity for transferring mathematics between articles and boards for discussion and back. We shall almost certainly need source-level editing of the raw markup in both article space and discussion space.

Please can we have some kind of confirmation that this is going to be possible and preferably no less convenient than the current system.

I don't think that anyone has said that HTML5+RDF storage precludes storage for mathematics work; that's something that the Parsoid team is working on.

I cannot promise that there will be mathematics markeup in normal discussion comments. I can promise that there will be collaborative authoring areas in Topics that will accept and store mathematics output.

As had been said, if you can promise wikitext authoring areas embedded in each message, it would be satisfactory. Otherwise, many articles would still be using a "conventional" talk page, although we might have to add additional namespaces.

Thanks for that update.

Thanks for that extra information. The need expressed is to be able to transfer text, including mathematics from an article to a discussion area, discuss it, possibly modify it, and transfer it back into an article. At present this is possible using cut-and-paste on wiki and LaTeX markup. Can you promise that the new system will support something equally convenient?

You will be able to cut-and-paste into the collaborative authoring areas. I feel it is reasonable to assume that this will include LaTeX markup. I expect this will be more convenient but some people are masochists and like to do things the hard way.

I'd like people to stop asking for "promises". It's very difficult to promise anything when code hasn't been written.

Thanks for that assurance. Rather than the word "promise" (which you introduced into this discussion), would you rather say that you have "clear plans" to deliver the capability we require? The precise terminology is not so important, provided that we had a good reason to believe that the need is well understood and reasonably likely to be delivered. The point is that we as editors need a certain amount of clarity about the developers' plans in order to engage effectively and constructively with them, and in particular to warn when the development process seems to us to have gone seriously astray.

That won't solve the problem. If Jorm says something like "At this point in time, I'm tentatively expecting to eat a cheese sandwich sometime next week, subject to availability of time and materials, and assuming an absence of unforeseen contraindications as well as the absence of potentially better alternatives", and he doesn't post a video of himself eating that sandwich along with testimony of people who saw him do it in person, then people come back and complain that he's broken his promise to eat a cheese sandwich.

"Clear plan" means promise to these people. "Plan" means promise. "Expect" means promise. "Hope" means promise. By the time you get through the rumor mill, even "might be possible" means promise. After months of this, I think you can imagine why Jorm is a bit wary about saying anything that could be misinterpreted by other people as meaning that any particular outcome will happen.

What we could get from the WMF (probably not Jorm) is that Flow will not be rolled out, even for beta testing, without certain features working (at least, in alpha test conditions). I would say the minimum feature would be

• Copy/paste between VE, Wikitext, and Flow messages (although, in some cases, it might have to be in Flow as an embedded Wikitext object.) This should include (in theory) anything which generates valid HTML; in practice, it should include < math>, anything tested which generates valid HTML (which includes templates with unclosed tags if they get properly closed by other templates, regardless of Parsoid), and anything you consider a valid Flow message without special workflows.

But I've already said what I expect as a minimum for a functional Flow system

I doubt you'd be able to get any promises along those lines from any employee of the Foundation, actually.

Editors wouldn't be so eager to request such promises if the dev team kept a public, updated list of all features that they're taking into account in their design, where all requests made by the community and acknowledged by the developers could be traced.

You're expected to have that with Agile methods. When you don't have an upfront design, communicating the current status of development at all times is vital, but the dev team has a serious problem of miscommunication with their final users.

If you shift focus from "I promise that final product will have X" to "I acknowledge that you need X", that could solve the problem without the need to make promises.

Even Agile methods should have a closure criterion; acknowledgement that if certain things cannot be done, then the product should be shelved. But "I acknowledge that you need X" would be helpful. So far, on VE, there are at least one "won't fix" and a number of bugs listed as low priority enhancements which fall under the minimum required for (at least, me) to consider using VE for major edits. Flow isn't yet to the point where bugs can be reported, or even feature requests be made.

The people here and there shouts: math-math-math, but nobody clarifies about what precisely do they speak. What is your “math”, indeed? The <math> tag really present a special problem. But articles on many technical (and not only) topics use tens of special templates (I mean: formatting templates, not navboxes), and mathematical articles use them as well and are not exceptional in this sense. Will wiki templates be expanded in Flow or no? Will we have a possibility to use an actual formatting code whether is it mathematical or no?

still waiting for an answer...

The discussion here is relevant.