| • dpatrick | |
| Jun 22 2016, 4:16 PM |
| F36578549: E157EA4F-905F-47A1-8DF3-3DFB7A432E77.png | |
| Feb 2 2023, 10:01 AM |
| F36578189: Screenshot 2023-02-02 at 00.37.56.png | |
| Feb 2 2023, 12:39 AM |
| F4572885: Screen Shot 2016-10-07 at 19.31.33.png | |
| Oct 7 2016, 6:32 PM |
| F4572886: Screen Shot 2016-10-07 at 19.31.50.png | |
| Oct 7 2016, 6:32 PM |
| F4572877: Screenshot_20161007-192450.png | |
| Oct 7 2016, 6:30 PM |
| F4192209: image.png | |
| Jun 22 2016, 4:22 PM |
When scanning the QR code on a right-to-left script wiki, the label is incorrect.
Here we see the proper label for enwiki, but incorrect labels for hewiki, fawiki, and arwiki. This screen shot is from Google Authenticator on iOS. Could someone with Google Authenticator installed on an Android device test this for the aforementioned wikis?
I just did it on fawiki, but didn't see much point trying ar and he (but can if deemed necessary)
It looks broken, but not quite as much as it is on iOS
fawiki, fa lang
fawiki, en lang
Both of these seem to result in the same format on Google Authenticator (I think.. will confirm)
Is the problem the atypical thing that happens when we have ltr and rtl in the same string? I guess we should try with a fully RTL "username" and checking if MW/Google Authenticator handles it correctly.. Might need to ask someone that speaks with those languages and is used to dealing with it.. Just for ease of caret placement and alike
I guess, partially MW is to "blame" and there's probably some blame to pass onto Google... We can file issue(s) at the repo for the app at least at https://github.com/google/google-authenticator
So LastPass and authy won't let you take screenshots...
LastPass it splits the farsi to the top of block, and displays the username correctly with brackets. So I guess it gets around it by using the key seperate....
Authy displays it the same as it does on wiki...
So, I don't think Android is actually broken, but iOS is more so?
Dropped priority right down for this.. Still interested in trying to fix it, if someone i18n minded can help, but for WMF purposes, setting a global site prefix alleviates this issue as is
Since we are using "wikimedia" as prefix, It really doesn't matter but if you want to solve it at any time, check if the wiki is rtl and then add ‏ before and add ‎ after the prefix name and don't escape it. Then we are good to go.
Does it happen in the Google Authenticator app? Can we try reporting it Upstream? It should be fairly easy to set automatic direction on usernames.
And if it can't be fixed upstream, can we send a different string to it? Perhaps we could add some Unicode control characters to fix it. It would be hacky.
In any case, we are far from showing it totally correctly in MediaWiki itself, which is why I always suggest not to use parentheses in names.
(Also, a good modern implementation of the Unicode bidirectional algorithm is supposed to fix the parentheses problem. It is already done well in Gecko, but not in Webkit.)
There should probably be a space after the colon, that's optional but allowed, and it's both more stylistically correct and probably helps the bidi algorithm figure out where the word boundaries are.
I created a really simple test repo at https://github.com/reedy/qrtest to generate the QR code on a page that can be easily manipulated, and displayed onscreen
<div class="mw-display-qrcode" data-mw-qrcode-url="otpauth://totp/Wikimedia:USERNAME?secret=K5UWW2LNMVSGSYI&issuer=Wikimedia" style='width: 256px; height: 256px;' / >
(zomg, the secret is Wikimedia)
The Wikimedia:USERNAME is the part to play about with as to what the app decides to display in it
So if we care this, we could change the url to be otpauth://totp/Wikimedia:%E2%81%A8USERNAME%E2%81%A9?secret=K5UWW2LNMVSGSYI&issuer=Wikimedia I imagine
%E2%81%A8 is FIRST STRONG ISOLATE
%E2%81%A9 is POP DIRECTIONAL ISOLATE
https://github.com/reedy/qrtest/commit/4503d5931c0033528e1d3a9d7c851b0f37587eda as a test...
Images are identical...
Should try them with some RTL text in it... And also, tbh, 6.5 years later, see how good/bad/indifferent the apps actually handle it now...
There was a bug in your test script https://github.com/reedy/qrtest/pull/1
It should be noted that FSI/PDI are relatively newer unicode characters, so I don't actually know how well supported they are in practise, but they are definitely the easiest of the BIDI control characters to use properly.
Using Authy (25.0.1) on iOS 16.3 both show as identical
Probably need to start trying with an RTL sitename
It's quite likely that by now, this is no longer relevant. Parentheses in usernames (and in lots of other places) had been troublesome for a long time in RTL contexts. Because of that, their handling in the Unicode algorithm was changed a few years ago, and most operating systems and web rendering engines have caught with the new standard. Can anyone with a username that includes parentheses test it and see if still happens?
We can just add another example to https://github.com/reedy/qrtest (though, it uses the old QR library, but that shouldn't matter)