User talk:Jdforrester (WMF)

Jump to: navigation, search

About this board

Pre-Flow discussion is on User talk:Jdforrester (WMF)/Archive.

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
Pamputt (talkcontribs)

Hi Jdforrester, could you explain me a bit why did you remove the translation tags on VisualEditor. You wrote it is because a bug of the Translate extension. What bug is it? Thanks in advance.

Jdforrester (WMF) (talkcontribs)

Hey there. The superb Translate extension is sadly incompatible with the visual editor. It is inappropriate to try to make such pages translatable, as it just makes the wiki terrible for everyone. Switching Translate over to not be based on strings but instead DOM is a huge piece of work. is the top-level task for this.

Whatamidoing (WMF) (talkcontribs)

I disagree that "superb" is an appropriate descriptor for Extension:Translate. "Brittle" and "strange" seem like much more appropriate words.

Pamputt (talkcontribs)

Hmmm, so if I understand correctly, it just means that since people are using Visual Editor, translation tags should not be used because there are troubles with it. Right?

Pamputt (talkcontribs)

Basically, what you described is just a problem for English version, mainly for users who use visual editor. For all others languages, it is not a problem at all since users of such languages have only access to the translation interface. So should we stop to translate pages just because there are some issue with visual editor? I guess most of people who write on mediawiki do not use VE but I can be wrong.

Jdforrester (WMF) (talkcontribs)

No, it is a problem for the "master" version whatever language it is written in. We have been manually translating pages for 16 years. Doing so is not that onerous.

Reply to "Translate extension"

Urdu Wikipedia (Latin numbers & Short URL for pages)

Hindustanilanguage (talkcontribs)

Hi James,

It was a pleasure meeting you at Wikimania 2016.

As discussed with you, please ensure that Urdu Wikipedia pages get short URL codes in English similar to what is available for Hindi Wikipedia.

Also, please make latin numbers (1,2,3) default for Urdu Wikipedia.

In case if you would like to further discuss this, please post a message on my Urdu Wikipedia talkpage.

Umpteen thanks in advance.

Jdforrester (WMF) (talkcontribs)

Hey there.

The first request was filed during the conference as T138507. I'll get it done soon.

For the second request, I'm not sure I understand. Numbers in references are already Latin, as are the ones on e.g. Special:Statistics. Am I missing something?

Hindustanilanguage (talkcontribs)

As probably you might remember during our meeting at Wikimania, for the phonetic font, when I type 1,2,3, I am getring ۱،۲،۳. We don't want this. We prefer 1,2,3 numerals.

Jdforrester (WMF) (talkcontribs)

Aha, yes, that was T138399. I will talk to the Language team about that one too.

Hindustanilanguage (talkcontribs)

Thank you. If there is anything urgent, please post the message on my Urdu Wikipedia talk page.

Reply to "Urdu Wikipedia (Latin numbers & Short URL for pages)"

Updating Citoid with latest translators

Czar (talkcontribs)

How often does the MW codebase sync with Zotero's official translator repo? I wrote a translator that was accepted today on Github but it's not working with Citoid right now.

Mvolz (WMF) (talkcontribs)

Arbitrarily. Our fork was last updated in August but I think our last upstream merge was sometime before that... definitely not ideal. I'll make sure it gets done again soon (mobrovac is another person to bug about that- he does deploy for citoid).

Also- thanks for writing a translator! That's awesome!

Elitre (WMF) (talkcontribs)

Hey @Czar, I agree with Mvolz, it's awesome that you did that.

Would you mind telling us whether you followed any guides in particular? Do you have tips, recommendations, advice that you can share with others willing to do the same? That would be so appreciated. Thank you again.

Czar (talkcontribs)

Oy, this could be a long post... I love Zotero and use it for academic articles but it needs more website translators and better citation export for Wikipedians, so I'm trying to help where I can with that. I was excited about Citoid and posted at W:WT:VG about making translators for our project's common sites but the translator coding barrier to entry is quite high—particularly its tutorial materials, which are partly what kept me from contributing for so long.

I used the "HWZT" tutorial (by Crymble and with additions on the Zotero wiki) but, frankly, it was needlessly complicated. The best route right now is to get set up with Firefox and Scaffold, learn how to get XPaths with Firebug, and use the "Framework" template (which is supported in Scaffold). But if you could screencast Sebastian's potential training, it surely would be much more efficient than the day I poured into figuring this out. I also think there are some easy fixes I can target to improve integration with Wikipedia (update embedded metadata translator, create Chrome extension like CiteGen that matches {{cite web}} standard formatting and uses Citoid? but allows for customization so editors can create citations with one click even outside VE). Have a lot more thoughts on this, if I can be useful

Elitre (WMF) (talkcontribs)

We're all ears. :) Also, let us know what you think about our suggestion about whether Sebastian could be interested in turning the "webinar" into a Tech talk in February or later. Can you get in touch with him, perhaps?

Elitre (WMF) (talkcontribs)

(I did find Topic:Su1wa035uoywpxeu after I left my message.)

Whatamidoing (WMF) (talkcontribs)

Maybe @Mvolz will know the answer.

Czar (talkcontribs)

@Mvolz (WMF) @Mobrovac-WMF Requesting another upstream merge for the translators repo (I wrote a few more translators with a few more in the pipeline. I'm also mostly done with a hideous automatic citation expander that uses the Citoid API to automate the majority of online material that I cite in my workflow.)

(1) Would it be better to request future merges on Phrabricator? (2) Is there a reason for merging manually instead of automatically?

Mvolz (WMF) (talkcontribs)

@Czar unfortunately merging automatically doesn't work :(. For some reason git has a really hard time merging files with "last updated" strings inside the translators and every time we merge we have to manually fix up a lot of the files, which is pretty error prone and time consuming.

Mobrovac-WMF (talkcontribs)

(1) Yes, it'd be easier to track progress that way.

(2) Enabling translators in the stand-alone zotero service is done by setting a flag in each translator (so as to indicate that it can be used in the service, and some are known not to work), so we have an extra patch with which we do that. Alternatively, we should try to upstream our fork and use the upstream repo directly. @Mvolz (WMF) already filed a patch for that.

When you say you're almost done, does it mean you have more work to do on the translators? Would it be worth waiting for the work to be complete before doing an upstream merge?

Mvolz (WMF) (talkcontribs)

@Mobrovac-WMF Unfortunately there's a hiccup with that change, which is that the google books fix we put in place to anonymize google books urls isn't accepted, because they only fill out the url field if the full text is available.

So we are back to having our own fork or putting that change in citoid itself specifically for google books links. Not sure which road to go down really.

Mobrovac-WMF (talkcontribs)

@Mvolz (WMF), hm, how about we just upstream the activation part of the patch? That would at least help us merge upstream changes more easily. It's not glorious, but it's a start.

Czar (talkcontribs)

@Mobrovac-WMF Everything that has been pulled upstream is good to go—I just meant that I will be making more in the future and I didn't know how often I should request a merge (since I'd like to use the translators with Citoid)

@Mvolz (WMF), if you would like a hand with the Zotero end of that pull request (so that Citoid can use the upstream repo directly), let me know and I can give it a try

Mobrovac-WMF (talkcontribs)

Awesome, @Czar, thank you on your efforts! I will do my best to bring the update to our fork ASAP (I'm on Wikimania currently, so this probably won't happen before next week).

Mobrovac-WMF (talkcontribs)

The latest changes from upstream have been merged and are now live.

Reply to "Updating Citoid with latest translators"
Alsee (talkcontribs)

The WMF's discussion of single edit tab has been, at least to me, very confusing and unclear. I've gotten a few responses that the WMF isn't going to be doing X, isn't doing Y, and isn't doing Z. But I'm having trouble finding a positive answer on how single edit tab is planned to work when someone signs up for a new account.

After ruling out all of the X Y and Z that aren't going to happen, the process of elimination seems to indicate:

  • New users will not get a menu
  • A new user will get a single edit button
  • The first time that button is clicked it will go directly into the site default editor
  • The EnWiki site default editor is currently wikitext
  • The EnWiki site default editor won't be changed to VE without asking the community first

Can you either confirm that the plan is to default new users directly into wikitext mode, or clarify how it is planned to work for new accounts? Thanx.

Jdforrester (WMF) (talkcontribs)


There will be only one edit tab. When you click on it, an editor will be loaded. Depending on user and system preferences, which editor loads will differ. For users who have no preferences beyond the default, which includes anonymous users, they will get the editor they used last; for logged-in users who've never edited, or logged-out editors who've not edited since their cookies were cleared or expired, they will get the "default" editor.

On "VE primary" wikis (like the Spanish Wikipedia, along with >200 others), the first editor that loads will be the visual editor. As always, first-time editors on opening the visual editor get some educational material welcoming them to the wiki, and about how to use links and references appropriately. Returning editors will get their most recent editor. Returning logged-in editors with a one-time welcome dialog that offers the ability to change their preferences in case they don't like the default settings (e.g. they never want to load the visual editor on clicking 'edit', or they want both tabs). This is hopefully going to go well, but as hope doesn't make a promise we're doing it gradually, starting with one smaller wiki and verifying it works for users there before proceeding.

On "VE secondary" wikis (like the English Wikipedia), the first editor that loads will still be the wikitext editor (if they have JavaScript, like now). Once this is in place, we will be able to run on the English Wikipedia our first ever A/B test with anonymous users (as before offering VE changed the read interface, which isn't permitted for performance reasons), where we will experiment with what the impact of making the wiki "VE primary" will be, and once we have data, discussing what that means for users with the existing editors.

I hope we'll be able to run the A/B test for the English Wikipedia in the next couple of months, but our first duty is to ensure these changes work well on the bigger wikis by VE edit volume.

Alsee (talkcontribs)

It has been a week. I see you have been editing on the 13th, the 18th, the 19th, and today.

Is T132806 being ignored?

Alsee (talkcontribs)

I hope this was simply a bug, but VE was just imposed as Primary editor on EnWiki.

Jdforrester (WMF) (talkcontribs)

Hi there, sorry for the delayed response; I didn't see this until just now (the perils of having dozens of notifications)…

Thanks for your remarks: it appears something is indeed not working as I had expected it to. T133304 for example seems to suggest the cookie system is not behaving in the way described in documentation. We'll address all the issues in due course: CLs will collect more specific details from users who have reported them. Apologies for the inconvenience.


Alsee (talkcontribs)

Could you triage Phab T132806 as accepted? Thanx.

Whatamidoing (WMF) (talkcontribs)

They will presumably do the paperwork for that Phab ticket at the next bug triage meeting.

At least with this team, it is not unusual for bugs to be resolved before the paperwork gets done.

Alsee (talkcontribs)

Not resolved. See Village Pump discussion.

I just saw you replied there. Thanx. Reclosing this thread.

Ad Huikeshoven (talkcontribs)
And many years.
Reply to "HBD"
MediaWiki message delivery (talkcontribs)

{{subst:#ifeq:{{subst:CONTENTLANG}}|en||I apologize for sending this message in English.}}

You are receiving this message because a technical change may affect a bot, gadget, or user script you have been using. The breaking change involves API calls. This change has been planned for two years. The WMF will start making this change on 30 June 2015. A partial list of affected bots can be seen here: This includes all bots that are using pywikibot compat. Some of these bots have already been fixed. However, if you write user scripts or operate a bot that uses the API, then you should check your code, to make sure that it will not break.

What, exactly, is breaking? The "default continuation mode" for action=query requests to api.php will be changing to be easier for new coders to use correctly. To find out whether your script or bot may be affected, then search the source code (including any frameworks or libraries) for the string "query-continue". If that is not present, then the script or bot is not affected. In a few cases, the code will be present but not used. In that case, the script or bot will continue working.

This change will be part of 1.26wmf12. It will be deployed to test wikis (including on 30 June, to non-Wikipedias (such as Wiktionary) on 1 July, and to all Wikipedias on 2 July 2015.

If your bot or script is receiving the warning about this upcoming change (as seen at ), it's time to fix your code!

Either of the above solutions may be tested immediately, you'll know it works because you stop seeing the warning.

Do you need help with your own bot or script? Ask questions in e-mail on the mediawiki-api or wikitech-l mailing lists. Volunteers at m:Tech or w:en:WP:Village pump (technical) or w:en:Wikipedia:Bot owners' noticeboard may also be able to help you.

Are you using someone else's gadgets or user scripts? Most scripts are not affected. To find out if a script you use needs to be updated, then post a note at the discussion page for the gadget or the talk page of the user who originally made the script. Whatamidoing (WMF) (talk) ~~~~~

Reply to "Bots"
Elitre (WMF) (talkcontribs)
Gummi bear saying "thank you" for the VE tables. (talkcontribs)


Reply to "Pic"
Dvorapa (talkcontribs)


I think, that portals could allure users with some topic, they could help them with navigation in that topic and they could offer them also some news and interesting facts about that topic. But so many users still don't even know, what is their purpose. Therefore I've got an idea, which would be worth realizing. Users could check (in Settings/Beta) not to see the Main Page, but to be redirected to their selected portal. I.e. if that user then clicks at Wikipedia logo, or types e.g. in their browser (logged in of course), their selected portal will be openned instead of standard Main Page. This function could help not only with portal and its article of the month (etc.) propagation but also portal topic propagation itself across users. Portal is so called main page of its topic, in which are some users interested, isn't it? Of course it would be a function just for experienced users, which check it in the Settings/Beta and select their preferred portal there. Everybody else would see standard Main Page as usual. I don't know, how to code for MediaWiki, I'm just experienced web programmer and template editor on Czech Wikipedia (cswiki). Therefore I ask for your opinion and for your help and effort to make this idea happen.

Reply to "Portal vs Main Page"
Ciencia Al Poder (talkcontribs)

I strong disagree on your edit in Template:ExtensionInstall.

Please, provide a valid reason, or else I'd have to revert, because the minority of users are actually who could use the new wfLoadExtension function. See quantity of wikis using MediaWiki 1.25 vs others

Jdforrester (WMF) (talkcontribs)

If you want to update the template properly, that's great – go ahead. That means:

  1. If registration = yes, show the MW 1.25+ documentation in one block of description and a distinct block for MW 1.24- with very clear warning signs that this is the deprecated method that should only be used if people know the previous method doesn't work.
  2. If registration = no, show the MW 1.24- documentation block with a note that it's still using the old method and will be replaced in the next few weeks (if they're using master) or in the next release (if not).

In the next couple of weeks, we're going to switch the template over to assume that registration = yes by default, so… Remember that using a mixture of wfLoadExtension and the old, slow method is inefficient for users' servers, so we need to encourage people to switch over comprehensively.

Also, please do not threaten to revert people, and in general it's expected that you discuss the merits of edits on the discussion page of the relevant page, rather than hounding the individual who made it on their talk page.

Ciencia Al Poder (talkcontribs)

You are right that my message isn't as polite as one would expect. Still, if you see the edit history of Template:ExtensionInstall, you'll notice the reason for it to be included, which was totally ignored by your edit, so I don't think opening a discussion would make any difference in this case.

Will do my best in editing that template to provide a clear idea that this new method is what needs to be used since MediaWiki 1.25, but older installations need to use the old version. The current situation is simply wrong and will generate lots of complains for users using MediaWiki 1.24 and before that will get a WSOD page.

Jdforrester (WMF) (talkcontribs)

I think you underestimate people. People using out-of-date code (like an MW 1.24.* branch) are generally aware that they shouldn't try adding or configuring anything new as the world has moved on.

Ciencia Al Poder (talkcontribs)

People can just install MediaWiki 1.24, or 1.23 (that's LTS) instead of 1.25 for whatever reason (some specific extensions still not compatible with 1.25, system requirements or just because 1.25 is still too recent) and install extensions for them. You can't negate them the right to do so by obscuring documentation for them

Jdforrester (WMF) (talkcontribs)

LTS is a laughable lie – the 'S' in 'LTS' means support, and no-one supports them except WMF staff doing security patch releases from time to time. We need to stop pretending to people that they're likely to get much or any community support when they're using anything other than the latest release or so.

Ciencia Al Poder (talkcontribs)

Talk to yourself, but thankfully, MediaWiki is not only Wikipedia and WMF staff, and there's a community -in which I'm part of it- supporting them in Project:Support desk. Pretending to drop that support is like pretending to ignore that MediaWiki is running in more than 25000 sites. And that's a disrespectful statement for a lot of developers that probably won't be contributing to MediaWiki if it were close-minded enough to only support WMF wikis

Whatamidoing (WMF) (talkcontribs)

I think you two are talking about different types of support.

You're doing "tech support" at Project:Support desk—answering questions that people have about (for example) how to install it or troubleshoot it. That awesome community provides support for all versions, regardless of how old, so long as someone there knows the answer or is interested in finding out what it is.

The "S" in "Long-term support" isn't about tech support; it's about dev support. It's about things like porting new security patches back to older versions. There are very few people doing that, and I would not be surprised at all to learn that most (or even all) of them are employed by the WMF.

Or, to give an analogy, I have an old Mac Plus (with a whole megabyte of RAM!) in the basement, and I can certainly find a community online that would cheerfully provide "tech support" on how to set it up again. But it's no longer "supported" in the sense of new software or updates to old software being created for it. It is unsupported hardware, even if it's possible to get answers to my questions about it.

Ciencia Al Poder (talkcontribs)

I don't see what's the point of your message to the whole conversation here, sorry.

There are a lot of MediaWiki installations out there that need longer terms for upgrading, because they rely on extensions that usually are broken on every new MediaWiki release and need some time for devs to fix them. Often because of problems with the release team (see phab:T66157).

Security fixes are not hard to backport, so I don't see what's the problem of maintaining LTS. If you ever remove LTS releases, I imagine the next step is to remove support for stable MediaWiki releases, only supporting current master or WMF branches. Who would put the limit, here?

Reply to ""Minority of users""

VisualEditor (Japanese) MS Office IME glitches

Kiyoweap (talkcontribs)

I tested the Visual Editor and found problems inputting while using MS Office IME 2010 (Windows 7, Internet Explorer). Acts as if it randomly accepts an "enter" key input, even whenI have not yet pressed "enter", having only manipulated arrow keys and space bar.

This either results in rendering unconverted pure-hiragana text ("ありがとう" instead of "有難う") or at other times when I try to convert the entire "ありがとう" it gets split the word up and starts converting just the "あり" part.

I think Visual Editor would be great for new users who find it overtaxing to use markup. But currently, the input is too glitchy so I can only recommend that Japanese-speakers create a draft using their own favorite editor and copy&paste the texts, footnotes, etc. --~~~~

Jdforrester (WMF) (talkcontribs)


Thank you for this information.

If you have the time, would it be possible for you to use this logger to create a trace of exactly what happens when you use the IME so that we can definitively work out what causes the issues and how we can solve them? If so, please copy the log it outputs and e-mail it to me (or post on-wiki).


Kiyoweap (talkcontribs)

I'm usually active in En and Ja Wikipedia, don't usually haunt the MediaWiki so I didn't notice this request till now.

I tried operating IME (MS Office IME 2010 (14.0.7003.100) SP2) using this logger .

When I tried "ありがとう"⇒"有難う"the conversion worked like a charm.

But this is a case where the first conversion candidate offered is the correct result.

It seems to still not work in the case where I need to scroll down to second or third candidates and select.

So it converted「げてん」⇒「ゲ店」without allowing me to scroll down to pick my choice which was「げてん」⇒「下天」. I think result will vary depending on user, because IME is memory-based, and will offer as first candidate whatever choice you used recently or repeatedly.

Hope that helps. --~~~~

Reply to "VisualEditor (Japanese) MS Office IME glitches"