Flow: Prettify thread permalink URLs/Titles (they are not human readable!)
Open, NormalPublic

Details

Reference
bz57154

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

(In reply to comment #4)

There are *some* patches to improve this, but it looks like kind of a big
deal - it'll probably be handled in multiple stages.

  • &action=view is gone
  • A JavaScript front-end that recognizes fragments is possible, but the link and wikitext [[Sandbox#topic-rnfimx8dabsyhl2v]] would not work in no-JavaScript browsers.

Replacing the UUID altogether with "name-of-topic" would require a cross-wiki UUID shortener table.

ypnypn9 wrote:

Can we do something like [[Special:Flow/Thread Name/123/8]], for the 8th comment to the 123rd thread with the name "Thread Name"?

(In reply to comment #6)

Can we do something like [[Special:Flow/Thread Name/123/8]], for the 8th
comment to the 123rd thread with the name "Thread Name"?

In that case, please do not put the page name in the "Thread Name" (again, since LQT does that =/).

Quiddity updated the task description. (Show Details)Mar 17 2015, 8:43 PM
Quiddity set Security to None.
Quiddity removed a project: Patch-For-Review.

Now that we are using content handler and it is enabled on prod wikis, we should be able to revisit and solve this.

Qgil added a subscriber: Qgil.Mar 18 2015, 12:17 PM
He7d3r renamed this task from Flow: Prettify thread permalink URLs to Flow: Prettify thread permalink URLs (they are not human readable!).May 10 2015, 4:01 PM
He7d3r updated the task description. (Show Details)
Ltrlg added a subscriber: Ltrlg.May 15 2015, 11:15 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 17 2015, 9:37 PM
He7d3r renamed this task from Flow: Prettify thread permalink URLs (they are not human readable!) to Flow: Prettify thread permalink URLs/Titles (they are not human readable!).Aug 29 2015, 4:03 PM
He7d3r updated the task description. (Show Details)

I had to delete ALL Topic pages from my watchlist by using Special:Watchlist/raw, because there were too many to select manually using Special:EditWatchlist#editwatchlist-ns2600, and the lack of a meaningful title made it impossible for me to choose the specific ones I wanted (Special:EditWatchlist at least displayed the topic titles, although it didn't show the page names).

A possibility would be [[Flow:<some-id>/original-title]] would be the canonical link to a flow discussion, which if the discussion is renamed, would become a permanent redirect to [[Flow:<some-id>/new-title]] it is what http://stackoverflow.com does for questions and I found it handy (modulo the fact here is a lot of more Flow-id than stackoverflow questions)

Qgil added a comment.Sep 15 2015, 8:40 AM

Would this task be suitable for Possible-Tech-Projects and Outreachy-Round-11?

ori added subscribers: Catrope, ori.Nov 25 2015, 8:18 AM

@Catrope, is this on your radar? The current URLs are pretty horrendous, IMO.

Qgil updated the task description. (Show Details)Nov 25 2015, 9:23 AM
In T59154#1830589, @ori wrote:

@Catrope, is this on your radar?

I'm aware of this issue, but there are no plans to work on this in the short term.

The current URLs are pretty horrendous, IMO.

Yes they are. So are things like T114550: Flow talk page on mediawiki.org takes 4 seconds to load and T78671: Beta Cluster Special:Contributions lags by a long time and notes slow Flow queries ;)

Tgr added a subscriber: Tgr.Nov 26 2015, 12:24 AM

Change 290365 had a related patch set uploaded (by Matthias Mullie):
[WIP] Pretty topic urls

https://gerrit.wikimedia.org/r/290365

We can have a simple implementation where the pretty url contains the topic title and/or the board name (for context).
It'll still include the UUID (because we don't want a lookup table).
The "pretty" part of the url would simply be ignored (similar to StackOverflow, I believe)

We should be able to link to said pretty url from most places, but there may be some places that still link to the current URL (because we don't have the topic title at hand and don't want additional DB lookups just for this)

Here's some suggestions of what those urls could look like:

  • Topic:UUID/Board/Pretty_title (e.g. Topic:T490mfdufwaacxk7/Talk:Sandbox/Subpage/This_is_my_post)
  • Topic:UUID/Pretty_title@Board (e.g. Topic:T490mfdufwaacxk7/This_is_my_post@Talk:Sandbox/Subpage)
  • Topic:UUID/Pretty_title (e.g. Topic:T490mfdufwaacxk7/Talk:Sandbox/This_is_my_post)
  • Topic:Pretty_title/Board/UUID (e.g. Topic:This_is_my_post/Talk:Sandbox/Subpage/T490mfdufwaacxk7)
  • ...

The possibilities are endless! Just keep in mind that:

  • we need to have the UUID in there somewhere, in a predictable place
  • it shouldn't be confusing for cases where we don't have the topic title at hand and can't generate a better link than Topic:T490mfdufwaacxk7
  • keep in mind that board names may have a hierarchy (parent/subpage) already, which could be confusing

So... What do we want them to look like?

EBernhardson added a comment.EditedMay 23 2016, 10:59 PM

Perhaps it's unviable, been awhile since i thought about this, but could it be possible to do this by creating pages in mediawiki for each topic name?

Page created with topic 'hi there':

  • Create Topic:hi_there with flow-board content type, the content would contain the uuid that backs the topic. Could store the current page name as a new field in the flow_workflow table?

Topic changed to 'other':

  • Create Topic:other with flow-board content type, again contain contains the uuid that backs the topic
  • Topic:hi_there changed to wikitext page with content #REDIRECT [[Topic:other]]
  • flow_workflow table updated with other as current topic page

Topic changed to 'yet again':

  • Create Topic:yet_again with flow-board content type, again contain contains the uuid that backs the topic
  • Topic:other changed to wikitext page with content #REDIRECT [[Topic:yet again]]
  • flow_workflow table updated with yet again as current topic page
  • Job enqueued to pull redirects from the redirect table pointing to Topic:other and perform an edit to point them at Topic:yet_again

This does create the difficulty of needing some sort of way to handle multiple topics of the same name. Easiest solution might just be a random string attachment, so Topic:yet_again/a8fq, and trying a couple times (perhaps expanding the # of generated characters each time) in the case of collision.
Might need to put page protection on the wikitext pages to keep them from being edited and broken. Alternatively instead of using wikitext redirects could recognize when loading a workflow that the requested page doesn't match the canonical page, and issue a redirect then.

Please do not make the same LQT did with user names (T23612), hardcoding them into titles which cannot be changed if a user is renamed (e.g. Topic:T490mfdufwaacxk7/User_talk:OLD_USERNAME_FOREVER/Something ok).

@EBernhardson: It's probably viable (and a lot easier now than it used to be), but it'll cost more time & risk (backfill pages, deal with collisions, ...).
This task is 2.5y old already and not a huge priority, so I think a simple improvement is more likely to actually get done :)

@He7d3r: The "pretty" parts of the url would simply be ignored & could be anything, only the UUID would be used internally.
So if a page name or topic title changes, new links would include the new data, but links with the old data would still work (and probably redirect to the current accurate url)

As long as those page do not get indexed by search engines with titles which can't be changed...

matthiasmullie added a comment.EditedMay 24 2016, 7:18 PM

IIRC, talk pages aren't indexed (wrong: T122119). But as long as we include a rel="canonical" and/or redirect to the new url once it changes, indexed pages would get updated as they're crawled again.

What is the rational behind using UUID ? some kind of counter could not work ?

Flow was designed to support multiple wikis and be sharded across multiple databases. With default auto-increment IDs, we'd have risked ID collisions, whereas UUIDs are guaranteed to be unique.

Trizek-WMF changed the task status from Open to Stalled.Jan 23 2017, 2:12 PM
geraki added a subscriber: geraki.EditedJan 24 2017, 8:44 AM

Please check https://www.mediawiki.org/wiki/Topic:Tjpkjvsopstw586w
In non latin script wikis this would create even more horrible urls without solving any problem.

For the url https://el.wikipedia.org/wiki/Topic:Tizm73nml0pv0ff0 a Topic:UUID/Pagename/Topic solution would result to https://el.wikipedia.org/wiki/Topic:Ti11vwprij2he4mg/%CE%A3%CF%85%CE%B6%CE%AE%CF%84%CE%B7%CF%83%CE%B7_%CF%87%CF%81%CE%AE%CF%83%CF%84%CE%B7:Geraki/%CE%A0%CF%81%CF%8C%CF%84%CF%85%CF%80%CE%BF:%CE%9A%CE%BF%CF%85%CF%84%CE%AF_%CF%80%CE%BB%CE%B7%CF%81%CE%BF%CF%86%CE%BF%CF%81%CE%B9%CF%8E%CE%BD_%CF%80%CE%BF%CE%B4%CE%BF%CF%83%CF%86%CE%B1%CE%B9%CF%81%CE%B9%CE%BA%CE%BF%CF%8D_%CF%83%CF%85%CE%BB%CE%BB%CF%8C%CE%B3%CE%BF%CF%85

If the plan is to change the current url "to have something more descriptive that will give more context to users", the question should be "where/when it will give this more context?":

  • When the user is already on the topic page, the topic title and page title are displayed on the top of the page itself
  • When the url is copy&pasted in another page it is not human readable in any way.

Keep the url as it is.

Trizek-WMF added a comment.EditedJan 24 2017, 3:07 PM

For practical reasons, please do not comment twice, both on the proposal page and here.

@geraki, I've replied to your feedback concerning URLs encoding here.

Tgr added a comment.Jan 24 2017, 4:56 PM

All modern browsers percent-decode URLs before display; you never see the %s unless you use IE8 or something (in which case this is not going to be your biggest problem).

In T59154#2965748, @Tgr wrote:

All modern browsers percent-decode URLs before display; you never see the %s unless you use IE8 or something (in which case this is not going to be your biggest problem).

I use Chromium, last version, and I have a nice collection of % in my address bar! :)

In T59154#2965748, @Tgr wrote:

All modern browsers percent-decode URLs before display; you never see the %s unless you use IE8 or something (in which case this is not going to be your biggest problem).

Indeed, but when you copy the nice url from the address bar it is copied (and then pasted) decoded.
The example above is displayed nice in the address bar but in this way when you paste it anywhere else.

Qgil removed a subscriber: Qgil.Jan 27 2017, 1:41 PM
Stryn added a subscriber: Stryn.Sep 18 2017, 5:41 PM

I have a request to have anchors readable as well.

Restricted Application added a subscriber: jhsoby-WMNO. · View Herald TranscriptJan 10 2018, 5:16 PM
Framawiki changed the task status from Stalled to Open.Jan 11 2018, 8:51 PM
Framawiki added a subscriber: Framawiki.
Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 18 2018, 6:58 PM
SBisson moved this task from Inbox to Triaged but Future on the Growth-Team board.Jul 20 2018, 6:11 PM