Chipping in: I agree that we should use "unlink" icon rather than "rubbish
bin" icon for removing a hyperlink.

There's a Wikimania 2019 submission about Lexemes, by @Fnielsen : https://wikimania.wikimedia.org/wiki/2019:Languages/Wikidata_lexemes

I'll be interested in participating in this small wiki toolkit hackathon. At the Cantonese Wikipedia we've been trying to build bots to generate league tables of best contributors and automate some routine maintenance, and it'll be nice to see whether other wikis have done similar things so we don't repeat ourselves.

Hi all. I think we do need a central discussion thread to make design decisions for Mobile VE, and I don't mind continuing here.

I tested these on my Samsung Galaxy S7 Edge. Android 8.0.0. Chrome and
Samsung Browser gave the same behaviour.

Yep, it works now, thank you!

Ah, I'm very sorry. No I wasn't using the beta app. I'll wait till the
proper roll-out and test again.

No this has not been fixed: e.g.
https://www.wikidata.org/w/index.php?title=Q133525&diff=prev&oldid=894115718

Thanks. I take your word for it that editing a section on the same page
will be *faster* than loading the section editor on a fresh screen. The
design intent is to reduce client load by putting as little of the page as
practical in edit mode.

@ppelberg / @Whatamidoing-WMF : Sorry for the British understatement. By "fine" and "alright" in (1) VE-Gboard interaction, (2) formatting and linking, and (3) Citoid, I meant that all features I tried behaved as expected, and to my satisfaction.

A few thoughts so far.

@Whatamidoing-WMF : Deryck here. Am up for trying it myself and inviting other Cantonese Wikipedia editors to take part. What should I do?

In T213941#4885091, @Lea_Lacroix_WMDE wrote:

Hello @deryckchan, and thanks for creating this task!
We're actually considering this for the year to come, but before starting developping anything, we need to understand better what people would like to do with the data, how they would like to display it on their wiki, what kind of Lua functions they would need.
If you already have some ideas, or use cases, feel free to share :)

Please, please, please don't ever rename yuewiktionary to zh_yuewiktionary.
It is zh_yuewiki that should be renamed yuewiki, not the other way round
(T30441)

Actually there is already a separator: a spacebar.

The spelling variant ambiguity caused a knock-on problem: a number of property proposals for phonetic transcriptions (for languages whose orthography doesn't give much information about pronunciation, e.g. Chinese) have been rejected with reasons along the lines of "they should be spelling variants". Some clarity is needed on this.

@Tgr: Can you please confirm what the latest state of affairs is? Has
unblock-self been removed from all WMF wikis? Are blocked sysops allowed to
block the sysop who blocked them, as of now?

There's a parallel discussion about this on the Wikitech-Ambassadors mailing list, where an interesting idea was raised:

In T172079#3749425, @TheDJ wrote:

@deryckchan FYI, Twitter allows for TOTP via their own app as well as via a TOTP app as we use. They don't seem to have a limit on how many devices (I wonder if all devices use the same code actually....). There are no scratch tokens either. Phone and/or email verification required for account recovery.

Depending on the specifics of "reauthentication", this may be a duplicate of T203256.

Hi. Just adding a comment to say that the geonotice maintainers on the English Wikipedia also use wp-world to produce a map of existing geonotices.

Thanks James, that sounds reasonable. I think Ryan's proposal is a fine
solution - we can allow sections to be edited while freezing references
that are reused elsewhere on the page, preventing them from being deleted.

In T50429#4558267, @kaldari wrote:

Currently the main blocker (although it may not be a hard blocker) is parsing support for managing state that is page-level (mainly for reference management). @dchan is exploring doing some of the subtree editing business on the client side as something of a stop-gap solution. The Parsing team's work on server-side ref management will probably be a better long-term solution (see T146072). They are hoping to have that work wrapped before the end of 2018. Anything to add @ssastry, @dchan, @DLynch, @Esanders?

Great. It looks like the bot hasn't edited anything since last week's tests
though? Is it supposed to start scanning mainspace pages for dead links to
fix?

WikiLove is now turned on. I'm marking this as resolved. Thanks everyone for the work.

Please change it to
報告程式錯誤

Agree - the language tag on Wikidata should be made to align with ISO 639 even where the siteID doesn't.

I've given it autopatrolled + confirmed flags for 24 hours and it managed to save the pages. I think the test worked. @shinjiman - I think this bot is good to go.

I did a small batch run with a few featured and formerly featured articles:
https://tools.wmflabs.org/iabot/index.php?page=viewjob&id=2390

In T188206#4526744, @Cyberpower678 wrote:

You're missing 1500 of the 6000 required edits to become an admin. I've gone ahead and manually added the bit to your account, as I doubt you will be irresponsible with the privileges.

https://zh-yue.wikipedia.org/wiki/Special:ListAdmins

In T188206#4526633, @Cyberpower678 wrote:

Okay :) That page currently says "Sorry, but the language you have picked is not available yet." I'll try again when the bot deployment is complete.

That's the UI language. The bot is available there. You might as well set the UI to English, not to be confused with the English Wikipedia.

In T188206#4526527, @Cyberpower678 wrote:

In T188206#4526464, @deryckchan wrote:

I've edited 3 of the translated messages in my big post above per @Roy17 's comment on https://zh-yue.wikipedia.org/wiki/Wikipedia:城市論壇 after I posted my translations here yesterday.

You can actually make the changes yourself by going to https://tools.wmflabs.org/iabot/index.php?page=wikiconfig&wiki=zh_yuewiki if you're a sysop on that wiki.

I've edited 3 of the translated messages in my big post above per @Roy17 's comment on https://zh-yue.wikipedia.org/wiki/Wikipedia:城市論壇 after I posted my translations here yesterday.

In T202548#4524200, @Framawiki wrote:

FYI the wiki code of yours is zh_yuewiki.

I agree with the comments above that until a separate machine translation engine is available for Cantonese, it can be useful to display a machine translation from a non-Sinosphere language to Modern Standard Written Chinese (MSWC) when the target language is Cantonese. This is because Cantonese and Mandarin share the vast majority of technical vocabulary; the lexical similarity rises when one considers MSWC which actually incorporates significant amounts of Cantonese vocabulary. In addition, the fact that most existing machine translation engines don't distinguish between the different kinds of Chinese languages means that the machine translations themselves are somewhat influenced by Cantonese anyway (being treated as a subset of Chinese rather than a standalone language).

I don't think it's formally approved yet, though I don't expect any
opposition.

Okay. Here are all the answers for the translations and questions earlier in this thread:

@Cyberpower678 Will you please explain how these messages get used:

In T63958#4515779, @C933103 wrote:

If there's no way to fix the internationalized format now then please change the format into ISO date format as a temporary fix. There's currently no way for me to tell which day a date value actually represent without trying to edit it and see the calendar pop up.

Most wikis have retained the built-in MediaWiki feature where trailing
brackets are stripped when a page is saved:

The issue seems to be in pywikibot class wikidatabot.create_item_for_page , which takes a page (from a pagegenerator) and auto-creates an item for it.

In T199216#4411762, @Reedy wrote:

That looks to be ~40 minutes ago, so should be fixed now

Same problem here.

@Mvolz Which templates' templatedata did you copy from enwiki? I think there are 4 (or 5?) templates and only a subset of them got copied, but I lost track...

In T194068#4191717, @Deskana wrote:

Is this only happening on specific pages, or all pages when you use both CodeMirror and 2017WTE in Firefox.

In T193360#4187379, @RHo wrote:

Not sure if this is related to T173842 ?

Thanks @Niharika and @MusikAnimal.

In T63958#4186157, @Capankajsmilyo wrote:

Is this task complete? Can someone please update this 3 year old task's status?

Please see attached screenshots - It seems that one is able to see yue
labels from Wikidata on Wikipedia Mobile app but gets an error when one
attempts to edit them.

@Roy17 has done a few tests in his userspace and saw that most websites failed to generate, including ones like BBC which usually work on en.wp. Have we missed some configurations?

Thank you @Mvolz *v*

Actually it seems that all 5 "trunk" citation templates (citation, cite news, cite web, cite journal, cite book) are used by articles on yue.wp. @William915 and @shinjiman imported the whole Module:Citation and the standard templates. So I guess the question is, what's the fastest way to get the other settings ready (I've already done Citoid-template-type-map.json and Visualeditor-cite-tool-definition.json| earlier this week) for Citoid to start working.

Hey thanks for opening a ticket for me.

@siebrand : @HenryLi raised the same question as he did back in 2011: Is it possible to localize the colon (:) that separates the namespace name from the page name, into a different character preferred by the local language? In the case of Cantonese (and CJK in general) it'll be useful to have full-width colon (：) as an alias of the colon so we don't need to switch input methods twice when typing any page name with a namespace name.

Just to give you all a heads up that there's currently a discussion at yue.wp discussing the possibility of localizing the namespace names. If there's a consensus to localize them, I'll come back with the full set of localized namespace names that we agree on.

I have done a few tests by trying to thank lots of people on a page on yue.wp where I don't mind thanking everybody. I can confirm the behaviour described above:

In T172079#3779576, @Tgr wrote:

but even if we didn't, we could still easily display the tokens if the user asks.

In T172079#3776581, @Tgr wrote:

Current common practice is that TOTP clients (notably Google Authenticator) don't store the two-factor secret key in a way that allows it to be displayed back to the user.

{{citation needed}} :) I doubt that's even technically possible.

In T172079#3770839, @Xaosflux wrote:

Something seems to be missing here - you can enroll as many devices as you want, at any time with us - provided you store your two-factor secret key. That key can be re-used in the future to initialize more authentication clients at any time. So this is already information that the users have, though hopefully if they store it they store it safely. That being said, being able to access it online after re authenticating with 2FA seems fine to me.

Please continue discussions about the merits of renaming particular
languages' / language groups' sites on their respective tasks. This thread
is about the issues blocking the actual act of renaming.

(non-native Japanese user here)

@Miya and @Takot are native speakers of Japanese and may be able to share some wisdom on this.

FYI another new editor has brought up the issue of renaming zh-yue again. The discussion again resulted in a consensus to push for the ISO-639-3 code "yue" to be made canonical. (Permalink to discussion)

A number of these requests involve renaming wikis where both the old name and the preferred name refer uniquely to one wiki, e.g. zh-yue => yue, zh-classical => lzh. Is it possible that in the meantime, searching for these in the Wikidata editing interface will return the existing database name? e.g. when I want to add a sitelink to yue.wp, I should be able to find it by typing "yue" in addition to typing "zh-".

(3) doesn't concern the vast majority of requests because the old URLs would be kept as domain name and interwiki aliases.
e.g. [[yue:頭版]] and https://yue.wikipedia.org/wiki/頭版 already work, but they redirect to https://zh-yue.wikipedia.org/wiki/頭版 and the rename request simply reverses these redirects.

It's intended as encouragement: fire for the engine, or a burning desire to
make things happen!

I can confirm that I have received the moderator password and Simon has
received the admin password. Simon has subsequently made me admin and sent me the
new admin password. So I now have both passwords most recently generated by
@RobH.

I referred to this as "trial" because, if I understood correctly, only
accounts with sysop or more advanced privileges are allowed to try OATH at
this stage.

In T172079#3577507, @Reedy wrote:

I'd be interested in getting some actual "evidence" or what other people do - Google, Facebook, Twitter et al. How they let users handle it. See what works, what doesn't work

In T172079#3577507, @Reedy wrote:

There are questions here whether we use the same seed on multiple devices (if we give the users a way to add multiple devices. Obviously, at original setup time they can share it with the world if they want (not recommended!) or install it on 1000 devices. Nothing to stop them doing that)...

lolz.

Certainly, this task has merit, Special:OATH should be some sort of "menu", with various options that will probably need an extra OTP entering, allowing things like disabling completely, changing device, regenerating scratch tokens without changing device etc etc

In T172079#3577450, @Reedy wrote:

That's not a citation.

......

In T172079#3577423, @Reedy wrote:

In T172079#3577419, @deryckchan wrote:

T150601 is a much better option than showing users the old scratch tokens again!

I agree on the principle that the best way forward is to separate the functionality for

1. disable OATH;
2. add new TOTP devices without needing to reset existing TOTP devices and scratch codes; and
3. regenerate scratch codes without needing to reset existing TOTP devices.

But that's a bigger functionality change and the quick-fix most OATH-enabled users need for now is to let an OATH-enabled user see their OATH config page again without disabling OATH first.

But, we shouldn't allow people to add extra/new devices, without having their original device, or a scratch token. Otherwise you're just creating a security hole.
What would we do if the OTP were stored in a way that it wasn't possible to get them back?

In T172079#3577422, @Reedy wrote:

In T172079#3577419, @deryckchan wrote:

A note on security: There is no additional security risk in displaying the QR code and the scratch codes again, because an existing TOTP token is required for the user to view the codes.

Where's the citation that there is no additional risk?

In T172079#3573460, @Reedy wrote:

A note on security: There is no additional security risk in displaying the QR code and the scratch codes again, because an existing TOTP token is required for the user to view the codes.

Most people would disagree.

[citation needed]