@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]

hi @RobH - any progress with this?

I've ascertained that as of last week, neither @Phoebe nor Simon Shek knew the admin password, and none of the moderators knew the moderator password.

I noticed that the date format has recently changed from "25 九月 1997" to "25 9 1997". Is work being done on the date formatting? And are we close to getting ISO dates or language-formatted dates?

I'll wait another week for the admins and other moderators to reply and let me know if they can get in. If not then I'll ask you for a moderator reset.

Were the moderator passwords reset in the 2015 global password reset?

In T159048#3533802, @RobH wrote:

@deryckchan: You are listed as a moderator for this mailing list, NOT a list administrator. So you wouldn't have received the password reset email.

Hi @RobH . Another Wikimania has happened and it turned out that this issue remains unresolved, because @Phoebe and I are still receiving wikimania-l bounce emails but still don't have the administrator password.

Different languages use DEFAULTSORT differently.

In T63958#3288758, @thiemowmde wrote:

• 12 of the 423 languages and language-variants MediaWiki currently supports name their default date format "ymd". These languages are namely crh (including variants), hu, kaa, and kk (including variants). We could disable the localization for these languages and display raw ISO dates instead. Users will not get better localization by doing so. But the order will be the same as the users expect. We might assume users being used to any kind of "ymd" ordering are less confused by "2017-11-10", even if it will be entirely unlocalized until we support full localization.
• About 20 more languages specify default date formats that start with the year, but are not named "ymd". Most notably gan, ko, and zh, including all their variants. We might add these to a blacklist and display raw ISO dates as well.
• We might add other languages to the same blacklist if requested and ISO is proven to be less confusing for native speakers.

In T63958#3286620, @thiemowmde wrote:

There is no reason to do the actual opposite of what this ticket asks for. No matter what the users language is, everybody can distinguish day, month and year in "10 November 2017". But we can not assume everybody understands what the month in "2017-11-10" is. This is actually the 11th of October in certain regions of the world.

In T63958#3284229, @thiemowmde wrote:

@deryckchan, The formatted date is what appears in the edit field. We do not want to show the unformated YYYY-MM-DD there as this would be even more confusing, so we show it formatted.

To clarify, this ticket is about displaying and outputting dates in the language-appropriate format.

Where?

Thanks for doing this. I'd like to suggest that the "Configure" link be anchored to https://www.wikidata.org/wiki/Help:Navigating_Wikidata/User_Options#Babel_extension to direct the user straight to relevant instructions.

This is essentially another facet of T106131. (T106131 concerns mediawikiwiki, this task concerns meta and commons.) The issue at hand is that the we want to encourage zh variant translations to be done as a single zh translation plus Chinese conversion tool.

I agree with @Bugreporter and @Liuxinyu970226 that this is disabled on purpose to reduce the number of redundant zh- translations. The solution here should be that

Thanks everyone for the help. I read from aaa839 this morning that he had recovered his account.

@Reedy "just a few minutes ago in zh wiki", said aaa839

@Dereckson I asked him to check the Yahoo email address that @Reedy
confirmed was linked to his account. He says "spam folder, main inbox
nothing was Wikipedia related"

When aaa839 read Reedy's comment that the account had a Yahoo address, he
wrote to me

Been in touch with aaa839 by video call per @Dereckson 's comment. Let me know what's next - I assume I'll need to pass his contact details to a steward privately?

Thanks for adding me to the subscribers list. I'm not sure what the problem
is - most of these babel boxes and categories can be merged without a
problem?

@Verdy_p I agree with you.

As someone without developer access, I gather from the discussion so far (over 7 years) that we're solving four different problems of various importance:

In T30441#2637078, @Liuxinyu970226 wrote:

@hashar I'm afraid your action on this task will make at least @HenryLi angry, because he said this on T21986:
This ticket opened in 2009 and now it is 2016. Why does it take 7 years without anything done? While it is not urgent and not trivial, there is a date it must be done. Please raise its priority and start a project as soon as possible to streamline the renaming process. It affects the consistence of user interface and the alignment to language code standard.

In T118000#2609356, @thiemowmde wrote:

Please provide more information if you can. For example: Did you tried different web browsers? Is the issue the same in all browsers? Does the issue only affect specific characters? Can you please provide a very simple list of steps how to reproduce the problem?

In T118000#2566359, @Liuxinyu970226 wrote:

In T118000#2504503, @deryckchan wrote:

In T118000#2504332, @Liuxinyu970226 wrote:

Works for me under Windows 7 (tried both Sogou and MS IME), maybe a bug in Windows 8 or 10?

Yes it was Win8.1 I had problems with. I haven't tried Win10 yet.

So this is an Upstream bug? i.e. probably should report to https://answers.microsoft.com/ or https://social.technet.microsoft.com/ ?

The option to apply vs not apply default sort after choosing files seems to be exactly what I want to achieve with this task.

I think the crux of this problem is that when one batch-chooses files to be added to the upload wizard, the order of files is well-behaved on most desktop browsers but unpredictable on most mobile platforms. So I'm wondering how we can find a solution that will make UploadWizard auto-numbering useful for mobile users without breaking the desktop edition.

In T118000#2504332, @Liuxinyu970226 wrote:

Works for me under Windows 7 (tried both Sogou and MS IME), maybe a bug in Windows 8 or 10?

I'm not sure *always* sort by filename is a satisfactory solution. I think some users might want to manually arrange the files in their desktop browser so they'd be numbered correctly after uploading.

Looks about right to me.

I raise you "correct horse battery staple" and all his friends. https://xkcd.com/936/