aklapper wrote on 2014-04-17 12:40:57 (UTC)

Haven't checked Phab's code, but as it autolinks numbers followed by a certain letter I'd assume somebody could patch the code and reuse the regexes we have in https://git.wikimedia.org/blob/wikimedia%2Fbugzilla%2Fmodifications.git/HEAD/extensions%2FWikimedia%2FExtension.pm

aklapper wrote on 2014-04-17 12:45:09 (UTC)

Also see T88

aklapper wrote on 2014-04-18 10:15:09 (UTC)

For the records, https://secure.phabricator.com/book/phabricator/article/remarkup/ covers the auto-linking stuff.

aklapper wrote on 2014-04-18 10:31:46 (UTC)

...and that page says:

[[wiki page]] # Link to Phriction
[[wiki page | name]] # Named link to Phriction

so with a small (?) code change we could hopefully link to mediawiki.org or whatever instead. Maybe.

gpaumier wrote on 2014-04-18 10:47:45 (UTC)

@Aklapper The problem is that Remarkup uses the same syntax for external links as well, e.g.:

[[https://fr.wikipedia.org | Wikipédia]]

There is an alternate Markdown-like syntax for external links:

[Wikipédia](https://fr.wikipedia.org)

but the one with double brackets is the one inserted by default by the toolbar.

I don't know how customizable / fixable this is, but I just wanted to raise the issue for completeness :)

Krenair wrote on 2014-04-20 11:40:29 (UTC)

Can we please not implement wikitext again?

Rillke wrote on 2014-04-20 11:57:05 (UTC)

Can we please not implement wikitext again?

@Krenair Yeah but then we should have some guide how to achieve the same, although phabricator has some nice toolbars and instant preview. I will not miss this feature very much because I mostly linked to :commons: and :de: (thus not a lot shorter or faster) but the :en:-guys may complain.

qgil wrote on 2014-04-20 15:24:50 (UTC)

In general, I would be reluctant to any local patches, except when they provide functionality that we would not get with the stock software.

In any case, I don't think lack of wikitext parsing would stop us from migrating. Setting priority as Wishlist for now. My opinion is Wontfix.

No guideline would be needed. Plain MediaWiki and VisualEditor also have a chain icon to define external links. When users click this icon, the rest is also obvious.

Krenair wrote on 2014-04-20 16:06:21 (UTC)

@Rillke If we implemented it again the default wiki obviously wouldn't be enwiki (probably mediawiki.org or maybe wikitech), so it wouldn't change much for them.

jdforrester wrote on 2014-05-10 20:35:20 (UTC)

◀ Merged tasks: T165.

robla wrote on 2014-05-14 19:10:18 (UTC)

The Phabricator folks explain their rationale for yet another markup language in https://secure.phabricator.com/T2849

In a nutshell, they've packed a bunch of functionality into a syntax that is very efficient to parse. One of the things that makes Phabricator a pleasure to use is the performance, so I would be hesitant to implement a (likely) less efficient, feature poor parser in the name of making something that we hope is vaguely headspace compatible with Mediawiki markup. If we're concerned about usability, I would rather we push the Phabricator folks to implement visual editing like we ourselves are doing.

qgil wrote on 2014-05-15 18:13:55 (UTC)

We shouldn't maintain a local patch just because. If there is a very good reason to add some functionality, then it could be proposed upstream.

We definitely don't need to patch the parser to set links between bugs, with Gerrit, RT, or with Wikimedia wiki pages. The existing Bugzilla links can be converted during the migration.

aklapper wrote on 2014-05-23 03:40:42 (UTC)

I was missing a rationale for "we'd really like to switch it to something else if possible" in the task summary but I guess it translates to "I'm used to wikitext markup and don't see good enough reasons to learn something else".

In any case I don't think that this should block Day 1 of Phabricator in production so I've changed the project of this task and added Maintenance (after day 1) instead.

Reasons:
You can actually see in the preview how your text will look like (compared to Bugzilla commenting) so you can realize beforehand that wikitext parsing might not work as expected. In the worst case people will realize that they need to paste full URLs - slightly more inconvenient, but not a dealbreaker IMHO. Furthermore, see RobLa's comment 33 above.

We definitely don't need to patch the parser to set links between bugs, with Gerrit, RT, or with Wikimedia wiki pages. The existing Bugzilla links can be converted during the migration.

Good point; Added a comment to T39.

Nemo_bis wrote on 2014-06-15 10:15:27 (UTC)

In T100#39, @Aklapper wrote:

I was missing a rationale for "we'd really like to switch it to something else if possible" in the task summary but I guess it translates to "I'm used to wikitext markup and don't see good enough reasons to learn something else".

Given it was set by James, it probably rather means "what's wrong with HTML after all". :P

Performance, really? Ok, but at least not double brackets for external links, as Guillaume says in T100#14... And yes, I think such a decision must be before day 1.

aklapper wrote on 2014-06-16 11:07:45 (UTC)

In T100#40, @Nemo_bis wrote:

Ok, but at least not double brackets for external links, as Guillaume says in T100#14... And yes, I think such a decision must be before day 1.

The comment preview would tell that markup parsing expectations from MediaWiki do not work out in Phabricator.
I expect a frustration level similar to Bugzilla and our custom regexes over there. Neither better nor worse. Which makes this not block day 1 for me currently.
--~~~~ (Y signature no work on tis Phabicreator wiki?!?!)

Svetlana wrote on 2014-08-26 09:14:29 (UTC)

There is the routine work of having to click through or type through many times to link to common things like [[:mw:Extension:Flow]]. There is another task of having to "learn a new markup". The latter appears to be discussed extensively in this task and a visual editor could indeed help (or we could kick and scream a little and have Parsoid service break into this site).

The former (routinely linking to mw and other sites) needs more attention. Implementing this would indeed be a repetition of the parser that Wiki uses which could probably be inefficient - some more insight is needed here; I wouldn't like to assume anything. If it is slower then how slower is it? Such feature would probably not be needed for other companies using Phabricator: they typically don't have a wiki farm, and may as-well do everything right in Phabricator itself. Phabricator is free software. Surely it's within its philosophy to be extensible and script-able to suit such specific needs?

I'd suggest to split this task and move over some interwiki-related comments over to a new task.

aklapper wrote on 2014-08-26 09:59:47 (UTC)

For comparison, Bugzilla's half-working ability to turn [[:mw:Extension:Flow]] into a link is a custom patch on our side. Whether something similar is doable and feasible in Phabricator remains to be investigated by anybody willing to dive into the codebase (and upstream is very responsive in helping).

If you are strongly interested in performance differences I recommend to contact upstream development for more information.

scfc wrote on 2014-08-31 19:26:56 (UTC)

FWIW, as @Aklapper said, the preview function (dearly missed in Bugzilla) makes this a not-so-big problem.

Personally, I strongly favour full-fledged URLs over [[wikilinks]] because:

1. They prevent users from messing with "evidence" relevant to a bug; if they just have to copy & paste something, the chances are much higher that what they report is what they actually experienced.
2. They work everywhere, i. e. if you read a bug report in your mailbox, you don't have to set up a local filter and keep that in sync with the tracker, but you can just click on a link.

qgil wrote on 2014-09-01 07:26:21 (UTC)

In fact, it takes less work to copy a Wikimedia URL from your browser and paste it here than typing the mw:etc custom strings manually.

After months of daily Phabricator use and after reading this discussion again, I think we can Decline this request.

Nemo_bis wrote on 2014-09-03 14:15:50 (UTC)

In fact, it takes less work to copy a Wikimedia URL from your browser and paste it here than typing the mw:etc custom strings manually.

Then just disable the phabricator-specific markup, no? Is there any reason we need a markup?

aklapper wrote on 2014-09-03 14:23:49 (UTC)

In T100#48, @Nemo_bis wrote:

Then just disable the phabricator-specific markup, no? Is there any reason we need a markup?

Same reasons phab-specific markup exists as any other markup: It's convenient.

Svetlana wrote on 2014-09-03 23:46:32 (UTC)

Can we force it to go plaintext? That could be nice, to avoid confusion of people who see an 'italic' button which adds //.

aklapper wrote on 2014-09-04 11:06:07 (UTC)

I do not see a reason to switch off markup (and I don't think it's possible). I don't see much "confusion" because there is a preview of your comment. Plus functionality like @Aklapper is nothing I want to switch off.

importing issue status