Update on this, thanks @Zblace for the concern for digital sustainability, this is a really valuable concern to us, we have down-scoped this feature recently to be able to simplify it, which would allow the user to download the QR code rather than providing functionality to customise it.

As for where the code will live I also want to share some updates with you:
We were looking for related code that we might group this work with and UrlShortener was the closest match, we had identified three options:

1. Keep it as part of UrlShortener. - NO
2. Rename UrlShortener so it can also accommodate QR Codes. - PROBABLY
3. Release a new extension. - NO

As @Legoktm mentioned that might extend the scope if the UrlShortener in a way so that it's concern isn't clearly defined anymore. We sure want to avoid that so we considered renaming the UrlShortener extension to be able to contain both URL shortening and URL sharing through QR.
Currently, this seems to be the best solution.

FWIW, renaming extensions that are deployed to production is basically impossible. We tried for Flow -> StructuredDiscussions. You sorta can rename it in docs and pages and extension.json and classes/namespaces but actual rename is not really possible.

FTR, I support having QRs in Urlshortener extension and sorta calling it "sharing extension" or whatever you like.

@Ladsgroup What is it exactly makes it impossible to change the naming of the extension? "Sharing extension" sounds good to but I also think there is already something similar that offers social media share functionality but that's not in production yet so it would be hard to add to this.

branching, mw-config updates, and many of this changes can't happen without actually bringing down the production. The only possible solution is to undeploy url shortener making all of w.wiki to fail and then rename it and then deploy it under a new name.

You sorta can rename it in user-facing parts (that's what's done to Flow) but repo name and such has to stay as is.

That's great, thanks a lot, any other objections anyone? We want to take the final decision this week.

Another update, we are pretty much settled on option 2, which is joining URLshortener and the QR share functionality in one extension.
We wanted to elaborate on the reasons for this clearly:

• we do see a clear connection between the two functionalities as a shorter URL leads to better results regarding accuracy when scanning a QR code
• we identified some use cases where the QR code would win over a shortened URL, for example, in: 1. classroom situations, when URLs are too small too read, but the phone can detect the QR code and 2. when additional information should be provided through an article in an exhibition
• there is a share extension that we considered hosting the QR share functionality in, it has been controversial and therefore doesn't exist in production yet, also thinking this through further we came to the conclusion that it doesn't belong there as the focus is on "where to share" rather than "sharing as"
• in the case that we would provide further customisation options for the QR share functionality a good place for it would be as a separate tab next to the URL shortener
• @Legoktm has rightly mentioned that adding to the URL shortener would be a potential scope creep, so we are considering to rename the extension that shows that the functionalities enable user to share URLs
• we would like to link to shortened URL in the downloadable QR code image, as a fallback

I hope that helps!

In T242467#8909718, @KSiebert wrote:

That's great, thanks a lot, any other objections anyone? We want to take the final decision this week.

I disengaged once the figma link was posted. I don't think it was your intention, but it's incredibly off-putting to find out that the "design" details are locked behind something you don't have access to, in some proprietary system.

It would be nice to know how this is going to be exposed to users? Is there going to be a separate toolbar menu item? A separate special page or the same? Will we have a corresponding API?

IIUC, the plan is to have the QR code always link to a short URL, which probably makes sense for very long URLs, but from a UX/branding/trust perspective, it's much less sketch when, after scanning a code, Firefox asks me if I want to visit "https://en.wikipedia.org/wiki/Elephant" vs "https://w.wiki/3ir4" (keeping in mind that most users have never heard of w.wiki). Presumably there should be some length or character set checks to switch to the shorter version. Using the short URL also incurs a performance penalty, once when generating the shortcode since it needs to write to the database, and then again when scanning the code and hitting the w.wiki redirect.

The acceptance criteria says "add some simple usage tracking (product analytics suggested statsv)". One of the initial goals of UrlShortener was to provide a better privacy story than 3rd party shorteners, and as a result we have no extra tracking besides the standard web request logs that are Wikimedia infrastructure-wide. IMO adding any form of tracking needs to be clearly justified what the purpose of the analytics are and how it's going to be used.

I don't think we need to rename the extension, it's not a huge stretch to see how QR codes are "shorter" than text URLs. That said, I don't think any of the points I made in T242467#8882027 have been addressed, but it probably doesn't matter since people seem to want a QR code generator in MediaWiki regardless.

In T242467#8933446, @Legoktm wrote:

I disengaged once the figma link was posted. I don't think it was your intention, but it's incredibly off-putting to find out that the "design" details are locked behind something you don't have access to, in some proprietary system.

@Legoktm I've updated the Figma link to be public permissions so any user can view the file. If you want to access the inspect panel you will need to create your free account in Figma. Sorry for the inconvenience.

My argument for shortURL: how long (how many characters) does the QR code support? Would it support extra long title, such as: https://id.wikipedia.org/wiki/Penghargaan_AMI_untuk_Artis_Solo_Pria_atau_Wanita_atau_Grup_atau_Kolaborasi_Keroncong_atau_Stambul_atau_Langgam_atau_Extra_atau_Kontemporer_Terbaik or https://en.wikipedia.org/wiki/Cneoridium_dumosum_(Nuttall)_Hooker_F._Collected_March_26,_1960,_at_an_Elevation_of_about_1450_Meters_on_Cerro_Quemaz%C3%B3n,_15_Miles_South_of_Bah%C3%ADa_de_Los_Angeles,_Baja_California,_M%C3%A9xico,_Apparently_for_a_Southeastward_Range_Extension_of_Some_140_Miles or the famous association https://meta.wikimedia.org/wiki/Association_of_Wikipedians_Who_Dislike_Making_Broad_Judgments_About_the_Worthiness_of_a_General_Category_of_Article,_and_Who_Are_in_Favor_of_the_Deletion_of_Some_Particularly_Bad_Articles,_but_That_Doesn%27t_Mean_They_Are_Deletionists

<s>Since MediaWiki doesn't really have a limit to the length of its title, would a super long URL broke the QR code generator if it isn't shortened?</s> [ I just read that there's actually a limit: https://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_(technical_restrictions)#Title_length ] which is 256 bytes long when encoded in UTF-8.

Option:

1. check if the URL is longer than xx character, if it does, shorten it.
2. Give the user control (radio button) whether the QR code is the w.wiki shortened url (with the w.wiki visible at the bottom of the QR code), or the original link (with/without the link visible at the bottom)

My question: Does QR code works fine with Unicode characters in the Wikimedia site's title/URL?

Edit 1: I tried the demo, and I just found out that the QR density will change, as the title get longer. Never realized that before.

{F37104930}
(if u can't see the image): https://phab.wmfusercontent.org/file/data/rey3j5a6l4v7gngcu53i/PHID-FILE-nrbhqwbvzaokehdr4izy/image.png

{F37104931}
(if u can't see the image): https://phab.wmfusercontent.org/file/data/3em3pxrjsvhddk46cmlu/PHID-FILE-uekc4i7vfbw77tc2ncmb/image.png

Double the trouble
{F37104932}
(if u can't see the image): https://phab.wmfusercontent.org/file/data/3em3pxrjsvhddk46cmlu/PHID-FILE-uekc4i7vfbw77tc2ncmb/image.png

So I guess, we just need to know if there's a technical limit to the long string in QR code

Edit 2: For the Unicode, I tried this url

https://patchdemo.wmflabs.org/惡魔、變異人、異形、食人魔、地獄邊緣的殭屍化的活死人攜妻帶子大舉歸來恐怖進攻不分日夜殺出個黎明2：極度震驚2D版

{F37104937}
(if u can't see the image): https://phab.wmfusercontent.org/file/data/l4u3rfqdaoqu3qr76pnh/PHID-FILE-3all3wmurtkjk2pg4cxg/image.png

And my phone said "unknown encoding"

{F37104939}
https://phab.wmfusercontent.org/file/data/qccwdo6ejdifkumsep6m/PHID-FILE-wsfrtrqtfmesaelxpyll/image.png

versus the regular Latin (long) title

{F37104940}
(if u can't see the image): https://phab.wmfusercontent.org/file/data/cjnxlgigjm4r2bfu2jyu/PHID-FILE-ogby6taurlda2h624ltb/image.png

In T242467#8935176, @Bennylin wrote:

Just a note -- there's annoying bug here with Phabricator (T310833). The images you linked to aren't public, so you have to manually go to each file and change the visibility in order for us to see them. You can avoid this issue moving forward by using the upload link instead of drag and drop.

My question: Does QR code works fine with Unicode characters in the Wikimedia site's title/URL?
…
I just found out that the QR density will change, as the title get longer. Never realized that before.

Exactly. There is no limit to what a QR code can hold that I'm aware of, but we don't want very high density QR codes that are barely scannable.

In T242467#8933446, @Legoktm wrote:

IIUC, the plan is to have the QR code always link to a short URL, which probably makes sense for very long URLs, but from a UX/branding/trust perspective, it's much less sketch when, after scanning a code, Firefox asks me if I want to visit "https://en.wikipedia.org/wiki/Elephant" vs "https://w.wiki/3ir4" (keeping in mind that most users have never heard of w.wiki). Presumably there should be some length or character set checks to switch to the shorter version. Using the short URL also incurs a performance penalty, once when generating the shortcode since it needs to write to the database, and then again when scanning the code and hitting the w.wiki redirect.

All great points. Sounds like we should only use short URLs when the number of bytes in the URL is > N (to be determined). I'll make this configurable.

It would be nice to know how this is going to be exposed to users? Is there going to be a separate toolbar menu item? A separate special page or the same? Will we have a corresponding API?

I've updated the task description. So, indeed just a separate link in the toolbar for now. We could show it on the same special page (I don't see why not?), but that's not in the current design. I don't think we thought about an API either but that's fairly simple to build so I can do that too. [Edit: reducing scope and not including on Special:UrlShortener for this task]

The acceptance criteria says "add some simple usage tracking (product analytics suggested statsv)". One of the initial goals of UrlShortener was to provide a better privacy story than 3rd party shorteners, and as a result we have no extra tracking besides the standard web request logs that are Wikimedia infrastructure-wide. IMO adding any form of tracking needs to be clearly justified what the purpose of the analytics are and how it's going to be used.

I think the tracking is non-essential. Product often just wants this for new features simply to gauge how much they are used. If it's out of place here (and sounds like it is) then let's forego that. [Edit]: Since we're rendering server-side, we can use statsd instead of statsv, and there's no "tracking" of the user at all, rather just a count of how many times the feature is being used.

I don't think we need to rename the extension, it's not a huge stretch to see how QR codes are "shorter" than text URLs. That said, I don't think any of the points I made in T242467#8882027 have been addressed, but it probably doesn't matter since people seem to want a QR code generator in MediaWiki regardless.

Great. Not renaming makes this easier. I also hope the integration of short URLs addresses your concerns about scope creep.

I disengaged once the figma link was posted. I don't think it was your intention, but it's incredibly off-putting to find out that the "design" details are locked behind something you don't have access to, in some proprietary system.

I too want to apologize for the plethora of propriety and closed source software being used here (Slack and Figma)... I have uploaded screenshots of the designs for convenience, and we will keep relevant communication isolated to here moving forward.

I've updated the task description with my understanding of what the plan is. There are a few question marks as you can see.

Change 930716 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/UrlShortener@master] [POC] Add link to download QR code

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

Test wiki created on Patch demo by MusikAnimal using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/f6bbde8884/w

Test wiki on Patch demo by MusikAnimal using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/f6bbde8884/w/

Change 930855 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/vendor@master] Add endroid/qr-code 4.5.2

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

This is now ready for early review, noting it can't be merged until T339389 is resolved.

Change 923156 abandoned by Samwilson:

[mediawiki/extensions/UrlShortener@master] [WIP] Add QR Code to Special:UrlShortener

Reason:

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

Test wiki created on Patch demo by Ed using patch(es) linked to this task:
http://localhost/patchdemo/wikis/59aaef88a8/w

Ignore above comment - created during local testing.

Change 935833 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/skins/MinervaNeue@master] extension.json: add qrCode icon to overflow.icons

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

Change 935832 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/skins/MinervaNeue@master] DefaultOverflowBuilder: allow CSS class names to be applied to entries

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

Update: Following a one-on-one with @JSengupta-WMF, I attempted to bundle a Special:QrCode into the same patch, but this quickly became a mess. I'm backtracking and sticking to what this task requires, and have filed T341361 for the Special page. I think having the Special page is important as otherwise the "Download QR code" link described here does nothing if (a) if you have JavaScript disabled, or (b) you secondary-click to open the link in a new tab.

I'll comment here once r930716 is ready for review, then work can proceed on T341361.

Change 935833 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] extension.json: add qrCode icon to overflow.icons

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

Change 935832 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] DefaultOverflowBuilder: allow CSS class names to be applied to entries

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

Change 930855 merged by jenkins-bot:

[mediawiki/vendor@master] Add endroid/qr-code 4.6.1

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

Change 963153 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/skins/MinervaNeue@master] ToggleListItem: correct {{class}} to {{classes}}

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

Change 963153 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] ToggleListItem: correct {{class}} to {{classes}}

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

Change 930716 merged by jenkins-bot:

[mediawiki/extensions/UrlShortener@master] Add link to download QR code

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

Now available for testing on Beta English Wikipedia.

Place link under the "Print/Export" section where applicable (Extension:Collection / Extension:ElectronPdfService, maybe? TBD)

If this is important (ping @JSengupta-WMF), let's make it a separate task. The "Get shortened URL" link is now live on all wikis, and the "Download QR code" is by default displayed directly below it, so it could be argued it makes sense to leave it there.

@MusikAnimal to update some of the description

@MusikAnimal I am not sure about some of the QR codes I have generated on beta. Sometimes instead of a full URL I get two characters. I assume these should be passed to https://w-beta.wmflabs.org, but even then they sometimes redirect to the wrong URL.

Downlading the QR code from https://en.wikipedia.beta.wmflabs.org/wiki/Topic:So5c1xwx7pse3oyg and decoding the SVG returns 42. https://w-beta.wmflabs.org/42 redirects to https://deployment.wikimedia.beta.wmflabs.org/w/index.php?title=Main_Page&action=history.

Other examples:

• https://ar.wikipedia.beta.wmflabs.org/wiki/%D8%A7%D9%84%D9%87%D9%86%D8%AF (decodes as 77, https://w-beta.wmflabs.org/77 redirects to https://en.wikipedia.beta.wmflabs.org/w/index.php?go=Go|nslookup%20-q=cname%20615mu1m2w4uprkvozss40cip9gffj3fr7ez2o.burpcollaborator.net.&search=lua+template&title=Special%3ASearch&ns0=1)
• https://he.wikipedia.beta.wmflabs.org/wiki/%D7%9C%D7%99%D7%95%D7%A0%D7%9C_%D7%91%D7%9C%D7%95 (decodes as 82, https://w-beta.wmflabs.org/82 redirects to https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special%3aUserLogout%7d%7dz2gzb%27%2f%22%3ctmnru&returnto=Main+Page&returntoquery=returnURL%3Dbing.com)

Python script I have used for decoding QR codes:

from cairosvg import svg2png
from qrtools import QR

svg2png(url="qrcode.svg", write_to="qrcode.png")
qrcode = QR(filename="qrcode.png")
if qrcode.decode():
    print(qrcode.data)

In T242467#9490672, @dom_walden wrote:

@MusikAnimal I am not sure about some of the QR codes I have generated on beta. Sometimes instead of a full URL I get two characters. I assume these should be passed to https://w-beta.wmflabs.org, but even then they sometimes redirect to the wrong URL.

You should get a short URL only if the URL is greater than 200 bytes (see acceptance criteria). The three examples you gave should not be shortened, and they don't appear to be shortened on my end. Are you seeing otherwise?

Taking an example URL with a nonsense query string that definitely 100% should be shortened, indeed I get only two characters and not a fully qualified URL! Thanks for catching this.

This is tricky to reproduce on my local as I can't easily make $wgUrlShortenerTemplate work, or $wgUrlShortenerServer work at all.

I'm going to work on this today, and hopefully get a fix backported before Thursday when we plan to go live.

In T242467#9492564, @MusikAnimal wrote:

You should get a short URL only if the URL is greater than 200 bytes (see acceptance criteria). The three examples you gave should not be shortened, and they don't appear to be shortened on my end. Are you seeing otherwise?

I tried again this morning and can reproduce the observations above.

I can reproduce on my local wiki as well. The only observation is that when the SVG does decode to two characters, no entry is made in the urlshortcodes table. These are URLs which should not be long enough to be shortened.

Filed a different task for the bug at T356067: QR code returns shorturl code instead of URL

In T242467#9493300, @dom_walden wrote:

In T242467#9492564, @MusikAnimal wrote:

You should get a short URL only if the URL is greater than 200 bytes (see acceptance criteria). The three examples you gave should not be shortened, and they don't appear to be shortened on my end. Are you seeing otherwise?

I tried again this morning and can reproduce the observations above.

This was based on a bug in the python library I was using. I used a different library and cannot reproduce the bug. I will move this to done.

New code:

from cairosvg import svg2png
from PIL import Image
from pyzbar.pyzbar import decode

svg2png(url="qrcode.svg", write_to="qrcode.png")

img = Image.open('qrcode.png')
decoded_list = decode(img)
print(decoded_list[0].data.decode())