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
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)

Sure:

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.

Yours,

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.

Reply to "Single edit tab"
Ad Huikeshoven (talkcontribs)
And many years.
Reply to "HBD"
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.

Reply to "Updating Citoid with latest translators"
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: https://lists.wikimedia.org/pipermail/wikitech-l/2015-June/081931.html 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 mediawiki.org) 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 https://www.mediawiki.org/w/api.php?action=query&list=allpages ), 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.
103.15.140.158 (talkcontribs)

Fordeleteall

Reply to "Pic"
Dvorapa (talkcontribs)

Hello,

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. en.wikipedia.org 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

3
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)

Hello!

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).

Thanks!

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"
Arystanbek (talkcontribs)

Please turn on Visual Editor as default for all user on kk.wikipedia.org. Discussion is here

Whatamidoing (WMF) (talkcontribs)

I have posted this as phab:T97315. Kazakh is a complicated language system, and our support for it is weak at the moment. It might be better to encourage more extensive testing first.

Reply to "VisualEditor on kkwiki"
Mahitgar (talkcontribs)

We received message through . ‎MediaWiki message delivery to test IME at https://wikimedia.github.io/VisualEditor/demos/ve/desktop-dist.html#!pages/simple.html. I wanted to test mr and hi devnagari script, Alas both the scripts IME could not be activated, may be still not enabled. So as of now test failed before we begin :(

Rgds

Jdforrester (WMF) (talkcontribs)

Thank you for responding! Could you tell me what browser and what IME you are using for these?

Mahitgar (talkcontribs)
https://www.mozilla.org/en-US/firefox/37.0.1/releasenotes/   

About IME , the test page only displayed language names and did not display any of usual IME options available under ULS (UniversalLanguageSelector Extension)

Or is it that it that still ULS is not enabled but we can use external IMEs . 30 % of Marathi language users use Google input tools I will ask more people to test with diferent IMEs step by step Thanks and rgds

Jdforrester (WMF) (talkcontribs)

ULS testing is going to be worked on by the Language Engineering team, but right now it's not enabled, that's right. Did you try out the Google input tools or an external IME for these?

Mahitgar (talkcontribs)

>>Did you try out the Google input tools or an external IME for these?<< I wanted to know which user types to be diverted for testing, I will start diverting the users now, thanks.

Jdforrester (WMF) (talkcontribs)

Thank you.

If you (or other community members) have an IME that is active in VisualEditor, it would be particularly great if you could use this logger to create a trace of exactly what happens when you use one or two of the IMEs 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).

Many thanks!

Reply to "mr and hi still not enabled"