Last modified: 2014-11-17 10:36:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1450 - Enable Extension:ShortUrl on or.wikipedia, ta.wikipedia...
Enable Extension:ShortUrl on or.wikipedia, ta.wikipedia...
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Extension setup (Other open bugs)
unspecified
All All
: Normal enhancement with 3 votes (vote)
: ---
Assigned To: Ben Hartshorne
: ops, shell
Depends on: 33551
Blocks: 31235 32578 29827 36164
  Show dependency treegraph
 
Reported: 2005-02-02 06:18 UTC by DIG
Modified: 2014-11-17 10:36 UTC (History)
21 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description DIG 2005-02-02 06:18:26 UTC
(It could be that something like this was already proposed, I just haven't fount
it).

It is nice to see what the URL is pointing to in English (or any ASCII-7 based
alphabet).  Unfortunately, it is not the case for most other languages.  For
most of them, especially for the languages which are not based on Latin
alphabet, URL-escaping makes URL unreadable and very very long.  So, it would be
nice to have some kind of short URLs for wikipedia pages.  This will make it
easier for the user to copy and paste the short URL into e-mail or on the web
page.  (I saw the reference to the wikipedia article in Russian in e-mail -- it
is horrible: 3 lines of 80 chars each, absolutely unreadable).

The short URL itself could be something like this:

  http://www.wiki???????.org/u/xyzuv

where

  ????? is a project name ({m,p}edia, etc)
  u     is a special prefix (may be empty);
  xyzuv is an "encoded" form of longer URL
        (very much like tinyurl.com's one).

It also would be nice to have this short URL on the printed page (as text, as
well as a link).

As a side-effect, the bots on #XXrc-channel will be less verbose.  We, at
#ru.wikipedia, are using such short URLs, they seem more practical, and overall
impression is better, than while using wprc-bots directly.  

Shorter URLs, happier users.


Best regards,

-- 
DIG (Dmitri I GOULIAEV)
1024D/63A6C649: 26A0 E4D5 AB3F C2D4 0112  66CD 4343 C0AF 63A6 C649
Comment 1 Tietew 2005-02-03 03:58:34 UTC
index.php?title=ANYTHING&curid=12345 shows an article curid=12345.

You can use mod_rewrite:
RewriteEngine on
RewriteRule ^/u/([0-9]+) /w/index.php?title=-&curid=$1 [QSA]
Comment 2 Antoine "hashar" Musso (WMF) 2006-07-11 17:08:14 UTC
Redirecting to WikiMedia.
We probably want to add an entry about that in the manual.
Comment 3 MZMcBride 2008-10-09 08:40:53 UTC
What about using the page's oldid to create something like http://xx.wikixedia.org/o/####### ?
Comment 4 Roan Kattouw 2008-10-09 12:42:09 UTC
(In reply to comment #3)
> What about using the page's oldid to create something like
> http://xx.wikixedia.org/o/####### ?
> 

Revisions have oldids, pages have curids. You probably want to be able to link to the curid too.
Comment 5 Arjuna Rao Chavala 2011-04-25 03:26:55 UTC
The additional problem appears when you want to make wiki book and opt for printer friendly version of the article. At the end of the article, a really long URL in US ASCII appears. I think it need not be in US ASCII, as international domain names have been approved.  Please correct the print version to a unicode  url, so that the page can be accessed easily as well as understood in the human readable language.

Appreciate higher priority to fix this bug, as we are ready to publish e-books in Telugu
Example Ubuntu user guide page url as it appears in printer friendly version.
http://te.wikibooks.org/wiki/%E0%B0%89%E0%B0%AC%E0%B1%81%E0%B0%82%E0%B0%9F%E0%B1%81_%E0%B0%B5%E0%B0%BE%E0%B0%A1%E0%B1%81%E0%B0%95%E0%B0%B0%E0%B0%BF_%E0%B0%AE%E0%B0%BE%E0%B0%B0%E0%B1%8D%E0%B0%97%E0%B0%A6%E0%B0%B0%E0%B1%8D%E0%B0%B6%E0%B0%A8%E0%B0%BF
 and a shorturl if it were to be used.
http://te.wikibooks.org/wiki/ఉబుంటు వాడుకరి మార్గదర్శని
Comment 6 Roan Kattouw 2011-04-25 10:04:47 UTC
(In reply to comment #5)
> I think it need not be in US ASCII, as
> international domain names have been approved.
Domain names are not the same as paths, they're unrelated.
Comment 7 Srikanth Logic 2011-05-29 02:48:16 UTC
(In reply to comment #3)
> What about using the page's oldid to create something like
> http://xx.wikixedia.org/o/####### ?

http://www.mediawiki.org/wiki/Extension:ShortUrl might help.
Comment 8 Arjuna Rao Chavala 2011-05-29 04:10:39 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > I think it need not be in US ASCII, as
> > international domain names have been approved.
> Domain names are not the same as paths, they're unrelated.
I think they are related. If not,  I would like to understand why the international text part of the URL is represented in US ASCII.
Comment 9 p858snake 2011-05-29 04:16:47 UTC
(In reply to comment #7)
> (In reply to comment #3)
> > What about using the page's oldid to create something like
> > http://xx.wikixedia.org/o/####### ?
> 
> http://www.mediawiki.org/wiki/Extension:ShortUrl might help.

I'm pretty sure that has been deployed on some projects.
Comment 10 Srikanth Logic 2011-05-29 04:20:03 UTC
(In reply to comment #8)
> I think they are related. If not,  I would like to understand why the
> international text part of the URL is represented in US ASCII.
brion's comment on this blogpost explains it i suppose 
http://ultimategerardm.blogspot.com/2011/04/sharing-tamil-wikipedia-url.html


(In reply to comment #9)
> (In reply to comment #7)
> > http://www.mediawiki.org/wiki/Extension:ShortUrl might help.
> 
> I'm pretty sure that has been deployed on some projects.

Nope, its fresh out of the oven, we are planning to deploy on tamil wikipedia. Review request needs to be raised
Comment 11 Yuvi Panda 2011-05-30 13:30:27 UTC
Review request sent in.

http://www.mediawiki.org/wiki/Review_queue#Extensions
Comment 12 Srikanth Logic 2011-05-30 14:15:42 UTC
Please enable this extension it in tamil wiki projects (Wikipedia, Wiktionary,Wikinews). Would like short urls of form ta.wiki*****.org/r/abcdef on each of pages. Find the link to community consensus on the same http://ta.wikipedia.org/wiki/விக்கிப்பீடியா:குறுந்தொடுப்பு#Support_to_install_mw:Extension:ShortUrl_on_tamil_wiki_projects
Comment 13 Srikanth Logic 2011-07-09 02:28:55 UTC
Changing the priority to normal. Currently Tamil wikipedia uses external domain tawp.in for shortlinks which are being used. Atleast  500 spread across web. Delay in having in house shortner exposes to a risk of large dead links to Wikipedia when the tawp.in server goes down. We already had amazon outages and few corp firewalls block tawp.in since its hosted in EC2.
Comment 14 Roan Kattouw 2011-08-23 14:14:10 UTC
I've reviewed Extension:ShortUrl , see https://secure.wikimedia.org/wikipedia/mediawiki/wiki/User:Catrope/Extension_review/ShortUrl
Comment 15 Yuvi Panda 2011-11-19 11:56:57 UTC
I know it's been a while - but the issues pointed to have been fixed in r103665 and r103035. Can this be reviewed again?
Comment 16 Yuvi Panda 2011-11-27 14:58:44 UTC
Roan pointed out more issues, have been fixed in r104219.
Comment 18 Srikanth Logic 2011-12-05 17:15:07 UTC
Is there anything else that prevents progress on this. A lot of non-latin wikis are really looking forward to this for ages, can some priority given to this to close and deploy them?
Comment 19 Sam Reed (reedy) 2011-12-12 17:52:06 UTC
Ticket for apache rewrites logged at http://rt.wikimedia.org/Ticket/Display.html?id=2121
Comment 20 Srikanth Logic 2011-12-19 20:21:48 UTC
Sam/others, Can you please check the status of the above RT. Thanks!
Comment 21 Mark A. Hershberger 2011-12-19 22:32:00 UTC
We've decided that this can be deployed without any mod_rewrite changes right now.  As Reedy notes there, /wiki/Special:ShortUrl/12345 is better than some of the alternatives.  Roan has said he will look at the code again tomorrow.
Comment 22 Sumana Harihareswara 2012-02-06 21:19:07 UTC
<Reedy> ShortUrl has 1 outstanding protocol relative issue
<Reedy> And getting the apache rule correct and setup
<Reedy> that's the only blockers to its deployment

from IRC today
Comment 23 Sumana Harihareswara 2012-02-06 21:21:35 UTC
<hexmode> Reedy: so what do we need to do re: shorturl? the actual code?
<hexmode> just have better doc for the rewriterule?
<Reedy> Works fine locally
<Reedy> well, the protocol relativity issue needs fixing first
<hexmode> that and then the rewriterule?
<Reedy> Getting someone from ops (though, I'm supposed to be able to do it) to actually implement the rules
<Reedy> Yup, few database tables to create on target wikis, but it'll be fine
<Reedy> http://wiki/r/v takes me to http://wiki/wiki/Wikia_code/includes/api locally :)
Comment 24 Sam Reed (reedy) 2012-02-06 21:29:13 UTC
So, bug 33551 needs fixing so we get correct https:// or http:// on each wiki, then we need a list of all wikis that will be wanting to enable ShortUrl

From there, we can use that list to create all the relevant database tables, and only add the rewrite rules to those wikis

Someone actually needs to write the rewrite rules.. I had some comments from Roan somewhere...

Locally I've got


        RewriteEngine On
        RewriteRule ^/r/(.*)$ /w/index.php?title=Special:ShortUrl/$1
#       RewriteRule ^/r/(.*)$ /wiki/Special:ShortUrl/$1


Not sure why I've got the 2nd one commented out, bug it'd make sense to use that format.

After that's setup, the simple part is just enabling it on the target wikis


It's been reviewed, and isn't actually ready for deployment, hence -shell, -need-review and added bug 33551 as a blocking bug
Comment 25 MZMcBride 2012-02-06 23:22:41 UTC
(In reply to comment #24)
> Locally I've got
> 
>         RewriteEngine On
>         RewriteRule ^/r/(.*)$ /w/index.php?title=Special:ShortUrl/$1
> #       RewriteRule ^/r/(.*)$ /wiki/Special:ShortUrl/$1

This seems to overlap with bug 16659 a bit and bug 17981 a bit. Basically, ops should be exceedingly cautious in adding new URL structures/schemes that will have to be supported indefinitely. I'd like Brion to weigh in, if possible.
Comment 26 Brion Vibber 2012-02-09 00:44:01 UTC
I do have some concerns about this extension:

* it creates a new numeric identifier to describe pages, which is very similar to existing page_id
* but it isn't page_id -- it refers to a page title, and thus if a page is renamed ends up referring to the old redirect

Since it's just a number with only internal meaning, I'd be more inclined to recommend using the page_id rather than creating a new id just for short links. This also saves the trouble of installing a new database table on every wiki, and would make it trivial to enable it for *all* wikis instead of just some.



As for the proposed prefix of "/r/", I'm not sure I like it; I'd prefer "/page/" or something myself, meanwhile using something like "/rev/" or "/revision/" would make sense for shortened version permalinks (with oldid).
Comment 27 Bawolff (Brian Wolff) 2012-02-09 00:49:40 UTC
(In reply to comment #26)
> I do have some concerns about this extension:
> 
> * it creates a new numeric identifier to describe pages, which is very similar
> to existing page_id
> * but it isn't page_id -- it refers to a page title, and thus if a page is
> renamed ends up referring to the old redirect
> 
> Since it's just a number with only internal meaning, I'd be more inclined to
> recommend using the page_id rather than creating a new id just for short links.
> This also saves the trouble of installing a new database table on every wiki,
> and would make it trivial to enable it for *all* wikis instead of just some.
> 

I think some people didn't want the short urls changing where they pointed to on page move, and wanted them to still work after a page delete/undelete cycle. (If I remember correctly)
Comment 28 Brion Vibber 2012-02-09 00:54:12 UTC
(In reply to comment #27)
> I think some people didn't want the short urls changing where they pointed to
> on page move, and wanted them to still work after a page delete/undelete cycle.
> (If I remember correctly)

That's a reasonable concern... I kinda want to be able to have hex or alphanumeric short codes here just to make sure they don't get confused with page ids though. *hmmmmm*
Comment 29 MZMcBride 2012-02-09 00:59:23 UTC
(In reply to comment #26)
> As for the proposed prefix of "/r/", I'm not sure I like it; I'd prefer
> "/page/" or something myself, meanwhile using something like "/rev/" or
> "/revision/" would make sense for shortened version permalinks (with oldid).

As mentioned in some of the other bugs, a lot of people are pushing for URLs to be more localized, and this would be a step away from that. That is, "r" or "rev" only work in English, really.

I don't think this is a deal-breaker, but I do think it's something to keep in mind.
Comment 30 Bawolff (Brian Wolff) 2012-02-09 01:48:58 UTC
Could make it something like /h/ so that everyone is confused equally (although personally i like /page/). I also agree that /r/ might not be the best due to the association with revision (Especially given how things like svn use r1234 for revision references).
Comment 31 Sam Reed (reedy) 2012-02-09 01:51:58 UTC
(In reply to comment #26)
> I do have some concerns about this extension:
> 
> * it creates a new numeric identifier to describe pages, which is very similar
> to existing page_id
> * but it isn't page_id -- it refers to a page title, and thus if a page is
> renamed ends up referring to the old redirect
> 

It's not numeric, it's alpha numeric

(In reply to comment #30)
> Could make it something like /h/ so that everyone is confused equally (although
> personally i like /page/). I also agree that /r/ might not be the best due to
> the association with revision (Especially given how things like svn use r1234
> for revision references).

People will think we're turning into Reddit
Comment 32 Yuvi Panda 2012-02-09 05:10:26 UTC
(In reply to comment #31)
> 
> It's not numeric, it's alpha numeric

base36 to be exact.

Is there anything else blocking this extension from deployment?
Comment 33 Mark A. Hershberger 2012-02-13 21:20:14 UTC
(In reply to comment #32)
> Is there anything else blocking this extension from deployment?

Right now we're mostly working on 1.19 deployment so I think this'll be another week *at least* before it can be deployed.  I'll try to get Sam's opinion on this, though.
Comment 34 Sumana Harihareswara 2012-02-13 22:47:52 UTC
I don't know whether there are any other TODOs blocking this extension from deployment.  But just to comment on the deployment schedule: as Mark mentioned, this is competing with the MediaWiki 1.19 deployment schedule:

https://www.mediawiki.org/wiki/MediaWiki_1.19/Roadmap

which will probably start this week and finish up on March 1st.
Comment 35 Platonides 2012-02-19 18:07:14 UTC
(In reply to comment #27)
> I think some people didn't want the short urls changing where they pointed to
> on page move, and wanted them to still work after a page delete/undelete cycle.
> (If I remember correctly)

Seems easier to keep the page_id on undelete (didn't we fix it?), on the simple cases at least (no conflicting ids).
Comment 36 MZMcBride 2012-02-19 18:39:25 UTC
(In reply to comment #35)
> (In reply to comment #27)
>> I think some people didn't want the short urls changing where they pointed to
>> on page move, and wanted them to still work after a page delete/undelete cycle.
>> (If I remember correctly)
> 
> Seems easier to keep the page_id on undelete (didn't we fix it?), on the simple
> cases at least (no conflicting ids).

That would be bug 26123.
Comment 37 Sumana Harihareswara 2012-03-29 18:40:29 UTC
(In reply to comment #26)
> I do have some concerns about this extension:

Brion, are your concerns dealbreakers, or are you ok with deploying it anyway?

(In reply to comment #24)
> So, bug 33551 needs fixing so we get correct https:// or http:// on each wiki,

This is now done.

> then we need a list of all wikis that will be wanting to enable ShortUrl
> 
> From there, we can use that list to create all the relevant database tables,
> and only add the rewrite rules to those wikis

Yuvi, can you collate that list?
Comment 38 Brion Vibber 2012-04-02 18:46:52 UTC
I think my concerns are all dealt with or minor enough I don't mind at this point.
Comment 39 Srikanth Logic 2012-04-02 19:01:22 UTC
orwiki,hiwiki,tawiki have got community consensus. 

'orwiki' => true,
'hiwiki' => true,
'tawiki' => true,
'tawikibooks' => true,
'tawikinews' => true,
'tawikiquote' => true,
'tawikisource' => true,
'tawiktionary' => true,

can be treated as first list, others will request in seperate bugs.
Comment 40 MZMcBride 2012-04-02 19:08:03 UTC
I think the only real outstanding question was whether just the extension would be enabled or if there would be accompanying Apache changes (changing link structure). Simply enabling the extension isn't a big deal; adding a link structure (such as /r/) that has to be supported indefinitely is a big deal.
Comment 41 Srikanth Logic 2012-04-02 19:22:10 UTC
(In reply to comment #40)
> I think the only real outstanding question was whether just the extension would
> be enabled or if there would be accompanying Apache changes (changing link
> structure). Simply enabling the extension isn't a big deal; adding a link
> structure (such as /r/) that has to be supported indefinitely is a big deal.

Not trying to sidetrack the issue here, but I really need "atleast just the extension deployed" sooner for 'tawiki' even if redirect rules take time. Tamil Wikipedia already has tawp.in for a year now and has been using a similar code on a private server which redirects tawp.in/r/* . The whole point of making an extension in favor of @mountain's standalone code was point of stability, so that I dont need to check my server every time someone pokes my server is not redirecting.
Comment 42 Sam Reed (reedy) 2012-04-02 19:28:03 UTC
(In reply to comment #41)
> (In reply to comment #40)
> > I think the only real outstanding question was whether just the extension would
> > be enabled or if there would be accompanying Apache changes (changing link
> > structure). Simply enabling the extension isn't a big deal; adding a link
> > structure (such as /r/) that has to be supported indefinitely is a big deal.
> 
> Not trying to sidetrack the issue here, but I really need "atleast just the
> extension deployed" sooner for 'tawiki' even if redirect rules take time. Tamil
> Wikipedia already has tawp.in for a year now and has been using a similar code
> on a private server which redirects tawp.in/r/* . The whole point of making an
> extension in favor of @mountain's standalone code was point of stability, so
> that I dont need to check my server every time someone pokes my server is not
> redirecting.

Without the redirect rules being setup, there is little point having shorturl enabled (imho). You're going to end up with https://ta.wikipedia.org/wiki/Special:ShortUrl/abcd123 which is better than what would be there already, but I'm not sure

Ignoring that, setup on the various wikis is a simple task and would only take a few minutes to do
Comment 43 Mark A. Hershberger 2012-04-20 14:44:21 UTC
ShortURL rewrite rules are in Gerrit change #5433.  If those are in production, then Sam should be able to deploy this.
Comment 44 Asher Feldman 2012-04-20 20:27:17 UTC
Regarding the apache rewrite rule, should it apply to all wmf projects?  If not, which ones should include or exclude it?
Comment 45 MZMcBride 2012-04-20 22:56:48 UTC
(In reply to comment #43)
> ShortURL rewrite rules are in Gerrit change #5433.  If those are in production, then
> Sam should be able to deploy this.

Did you take into consideration the comments above regarding link syntax and translations? There were a number of comments explaining why "/r/" was less-than-ideal and this commit seems to have ignored all of them.
Comment 46 Srikanth Logic 2012-04-22 14:46:58 UTC
(In reply to comment #29)
> As mentioned in some of the other bugs, a lot of people are pushing for URLs to
> be more localized, and this would be a step away from that. That is, "r" or
> "rev" only work in English, really.
> 
> I don't think this is a deal-breaker, but I do think it's something to keep in
> mind.

Well, the extension itself is requested since URLs of non latin wikis get converted into percentage encoding like this :- http://ta.wikipedia.org/wiki/%E0%AE%B5%E0%AE%BF%E0%AE%95%E0%AF%8D%E0%AE%95%E0%AE%BF%E0%AE%AA%E0%AF%8D%E0%AE%AA%E0%AF%80%E0%AE%9F%E0%AE%BF%E0%AE%AF%E0%AE%BE:%E0%AE%86%E0%AE%B2%E0%AE%AE%E0%AE%B0%E0%AE%A4%E0%AF%8D%E0%AE%A4%E0%AE%9F%E0%AE%BF

So I dont really see a case why people would want to localize this which would mean URLs get percentage encoded again.


(In reply to comment #30)
> Could make it something like /h/ so that everyone is confused equally (although
> personally i like /page/). I also agree that /r/ might not be the best due to
> the association with revision (Especially given how things like svn use r1234
> for revision references).

I dont mind /h/ or /m/ /l/ or whatever.  Even /page/ is fine, but just that /<singlechar>/ would mean the url is also short (and hence faster to type on say mobiles)

@MZMcBride, am sorry I couldnt find other comments why /r/ is less-than-ideal to stop this bug from moving? Can you please point them out? 

Can you also please point out what would be more ideal since few hundred communities are waiting for a way in which 'sane' URLs of their language wikis which are not percent-encoded, can be shared freely without annoying other people.
Comment 47 MZMcBride 2012-04-22 22:27:49 UTC
(In reply to comment #46)
> Can you also please point out what would be more ideal since few hundred
> communities are waiting for a way in which 'sane' URLs of their language wikis
> which are not percent-encoded, can be shared freely without annoying other
> people.

Sorry, this bug got a bit hijacked by tangential issues. This bug is about enabling the ShortUrl extension on specified wikis. I've filed bug 36164 to track the rewrite rule issue.

As far as I know, there's nothing blocking the immediate deployment of this extension to specified Wikimedia wikis. The rewrite rules can and should be discussed separately at bug 36164.
Comment 48 Asher Feldman 2012-04-24 22:49:47 UTC
I agree with Srikanth re: the undesirability of internationalization in this case. Using [a-zA-Z0-9] is also in line with most other link shortening services, which have become ubiquitous. I think we can deploy as-is and revisit the issue later if a specific project forms consensus around wanting an internationalized redirector.

Brion far above voiced concern that shortlinks could be confused for revision-ids. I don't think it's current issue but makes me wonder if we should use /l/ instead of /r/.  

I also suppose we'll want to use a rewrite condition so the redirect only applies to the wikis mentioned in comment 39?
Comment 49 Daniel Friesen 2012-04-24 23:59:35 UTC
(In reply to comment #48)
> I agree with Srikanth re: the undesirability of internationalization in this
> case. Using [a-zA-Z0-9] is also in line with most other link shortening
> services, which have become ubiquitous. I think we can deploy as-is and revisit
> the issue later if a specific project forms consensus around wanting an
> internationalized redirector.
> 
> Brion far above voiced concern that shortlinks could be confused for
> revision-ids. I don't think it's current issue but makes me wonder if we should
> use /l/ instead of /r/.  
> 
> I also suppose we'll want to use a rewrite condition so the redirect only
> applies to the wikis mentioned in comment 39?

How about /s/?
Comment 50 Asher Feldman 2012-04-25 18:43:23 UTC
+1 to /s/, I think we just need to get the router code added as you outlined in https://bugzilla.wikimedia.org/show_bug.cgi?id=36164#c6 and we should be able to plan deployment.
Comment 51 Yuvi Panda 2012-05-13 19:28:58 UTC
The router code has been merged in. What next for deployment? 

+1 to /r/, +0 to /s/
Comment 52 Daniel Friesen 2012-05-13 19:45:30 UTC
(In reply to comment #51)
> The router code has been merged in. What next for deployment? 
> 
> +1 to /r/, +0 to /s/

Can someone tell me why /r/ is even considered a valid path for this purpose? What word is it that makes it so that '/r/' makes sense? Cause to me /r/ speaks 'Revision', ie: &oldid, and short url does NOT use that.

Frankly I'd reject the use of that path on the grounds that it would preclude the ability to use /r/ to point to &oldid in the future if we found a reason to do that.
Comment 53 Yuvi Panda 2012-05-13 20:01:25 UTC
I think /r/ was considered simply because that's what is being currently used by the wikis. See http://tawp.in/r/rtd for an example.
Comment 54 Yuvi Panda 2012-05-13 20:02:14 UTC
So that's a 'legacy' reason, and it looks like there is now consensus on /s/ (at least among the comments so far on this bug)
Comment 55 Krinkle 2012-05-14 08:47:15 UTC
(In reply to comment #53)
> I think /r/ was considered simply because that's what is being currently used
> by the wikis. See http://tawp.in/r/rtd for an example.

Assuming the registry of this extension will not match all entries on the private server at http://tawp.in/r, there is no reason to use same character. It could even be confusing.

When ta.wikipedia.org/s/<shorturl id> is set up, the maintainer of http://tawp.in/ could set up http://tawp.in/s/* to redirect to http://ta.wikipedia.org/s/*
Comment 56 Yuvi Panda 2012-05-14 10:22:43 UTC
@Krinkle: Was merely providing historical context :)

(Also: I run tawp.in)
Comment 57 Sumana Harihareswara 2012-07-25 17:47:44 UTC
Just talked to CT Woo.  Ben Hartshorne will be working on this, but is currently refining the Apache rewrite rules as part of his Swift work.  The Apache rewrite rule work will also help with ShortURL.
Comment 58 Sam Reed (reedy) 2012-07-30 16:35:18 UTC
Redirects are in place.

Enabled on tawiki and orwiki, hiwiki (another bug) and the other tawikis

Open new bugs for other wikis etc.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links