As the scopes are still undocumented yet (I checked the link now) I am going to remove myself from this task for the time.

@Legoktm those benchmark results are a bit old, while fluidsynth might got an update, I can update them if required :)

Here are some thoughts from my side as a GCI participant:

In T185447#3917132, @Aklapper wrote:

Is this about some local change specific to Wikimedia's instance of Phabricator, or does this apply to any Phabricator in general (which would make this an upstream issue)?

Looking at the current source of Phabricator on GitHub, the "required" scope for user.whoami is referring to self::SCOPE_ALWAYS, therefore the docs for https://github.com/ofbeaton/oauth2-phabricator should be updated to list that scope.

Added missing documentation to the extension wiki page:
https://www.mediawiki.org/w/index.php?title=Extension:Score&oldid=2697225

In T185317#3913844, @Dalba wrote:

In T185317#3913727, @divadsn wrote:

@Dalba ok, that's a point, but now why the revert?

That patch could be fixed with a follow-up, which would be simply adding a |Invalid ISBN found to the regex, why not instead?

IMO, https://gerrit.wikimedia.org/r/#/c/399348/ was more deserved to be merged. It was submitted before your patch and it did not have this issue.

But it had other issue and the author wasn't doing anything for a month since that day, that's why I took it up and made mine when working on the task with @jayvdb as mentor.

@Dalba ok, that's a point, but now why the revert?

Afaik it's usually supposed to install all needed requirements from the requirements.txt, but I may be wrong here.

Running on Windows, make sure you don't have python-stdnum installed.

In T168716#3913425, @ABorbaWMF wrote:

@Jdlrobson, do we have a target article for this test on Staging? I have been looking for an article using the template in question, but I have not found one.

I wrote my blog post in English, it lacks a bit at the end, but ready for the public :)
https://www.codebucket.de/blog/contest/2018/01/17/google-code-in-2017-and-the-future.html

I made my suggestion over at the discussion page, hope it will be fixed soon :)
https://www.mediawiki.org/wiki/MediaWiki_talk:Titleblacklist#Google_misspelling_pattern_matching_wrong_for_Talk:_pages

11:06:35 <RexxS> divadsn: the blacklisting of a title is via the Extension:TitleBlacklist - https://www.mediawiki.org/wiki/Extension:TitleBlacklist

This filter might be present here: https://www.wikidata.org/wiki/Special:AbuseFilter

I'm sorry that I've overlooked the basic styling of those elements, now I re-done the patch and kept those styles in tact, only changed the scaling behavior.

Closing as the original PR got merged a week ago.

@Stemby MP3 files are better for mobile users from my experience when it comes to loading time and file size.

Now it's possible to slowly migrate from TiMidity++ to Fluidsynth and then after a period of time drop support for TiMidity++ :)

Will work tomorrow, I had some school exams to pass today :)

@Ebe123 I don't exactly know if there is a difference between, but I also see only the stock audio player.

Here are some testing results.

I ended up generating a temporary wav file and then converting the wav to mp3, the rendering time shouldn't be much affected by that "workaround", I can run later a benchmark same as I did with the comparison before.

Migration to Fluidsynth is in progress, see T181897 :)

This happens when no soundfont and midi is provided, I had that issue when I was testing it too.

Piping should be possible regardless of the other patch I think.

@TheDJ sure, I am aware of that too. Until then I will work on T181875.

@Legoktm great, so should we deprecate TiMidity++ soon as fallback when the patch gets merged?

One comment regarding some sound distortions made by TiMidity, they are present in my files above. At the beginning of the track you can hear a "crack", while Fluidsynth doesn't have that issue.

@Ebe123 sure, here you go: https://drive.google.com/open?id=1G4fjTAy7yF280kfAHMeEe7VIvVyPrMpx

Ok, here are my benchmark results: https://docs.google.com/spreadsheets/d/15JEu2IeCM_zJyS3RXDdMHNHoZbxFbKdgJRsEP5LkM3Y/edit?usp=sharing

@Legoktm alright!

In my opinion we should wait until T181897 hasn't been solved, just to avoid double work.

Gonna do some benchmarking then :P

@Jdlrobson sure, I could try looking into that by the end of this week, is it high priority?

@Jdlrobson, oh great to know, thank you! :)

@Ebe123: However, seeing that MP3-conversion is only supported on Windows, I'll put the GCI task on hold.

We could still do a pipe out to lame and convert that way on Linux, at least it's worth a try IMO.

@Florian as far as I understand the task is to add an option to convert midi files into MP3 files, but this needs some clarification about the used tool, as Timidity doesn't have a native option for MP3 conversion. This can be done by checking the filename extension in my opinion, should be the easiest way.

Done! Wish best of luck for future migration to other sound formats, maybe I will also contribute myself to mp3 format :)

What should be used instead of vorbis to have it generalized? I was thinking of audio but maybe just convert?

Sounds like a good task to work on, I will do it :)

Will do that :)

@jayvdb but isn't it how it's supposed to be done on GitHub where you squash those commits during merge? I mean, people are always telling you not to force push, right? :/

In T179202#3861385, @jayvdb wrote:

But as I mentioned above, it looks like the scope scope.always exists, and I wouldnt be surprised if the myriad other scopes in phabricator also work via OAuth.

A bit more investigation needed (however the GCI task criteria have been met, and so it is approved).

Will do that now, patch coming soon :)

In T183667#3860742, @Framawiki wrote:

In T183667#3860140, @eflyjason wrote:

Would timezone settings on bot user's computer be a problem to this?

It's more user-friendly to keep using a local timezone instead of UTC.

Sure! Will do that in about 1 hour :)

I pushed my changes on my fork to GitHub: https://github.com/divadsn/social-core/commit/06ab0675c3c9f79fd3cb17133fda2e0793367be0

Alright, I finally could get my local Docker instance running and added a testapp in OAuth Server which will then return the data I want to my dummy script.

Oh, thanks for the tip, I was going to use Docker to create a local Phabricator instance :)

I will do it :)

Importing symlink from os should do the fix, right? :)

So after looking up the code I noticed that EducationProgram pages are not extending OutputPage, but implementing the Page interface in order to use a WikiPage instance, which does also not extend the OutputPage.
Looking further I noticed also that those JS vars are only applied for OutputPage instances in ParserOutput, so the only dirty way would be by adding that to includes/DefaultSettings.php.

Thanks @Daimona, I took your suggestion and adjusted the font-size to match the one from tt, also behaves the same with different screen sizes.

I will fix that issue :)

@Jdlrobson as you are my second mentor of the task on GCI and @D3r1ck01 isn't able to see any images here, could you please help me to recreate the example article fully for my local devwiki? :)

Should be easy to fix, as far as I've read the Flexbox propose seems to be good, although the good news is that it's was only compatible with Chrome before.

According to this page (https://www.w3schools.com/tags/tag_tt.asp) the tt tag can be replaced with samp for computer output, so I think that should be a good solution.

In T182968#3847552, @Aklapper wrote:

the student will have to thoroughly test the output!

The question here is how are you supposed to manually remove the subscriber, by executing it in MySQL?

Thanks to @santhosh for his help in reviewing the task :)

Working on that right now :)

If it comes to the gap between, the cause isn't the fieldset anymore, it's a wrong CSS rule here:

Sorry, but sadly I can't reproduce the bug on the Wikipedia ContentTranslation page and my local vagrant had problems running the contenttranslation role.

I think it's better to remove the element completely in my opinion :)

I've got an even better idea, as I noticed that tipsy.js is replacing title with original-title, I just renamed original-title to aria-label, so we've got it fixed for every tooltip :)

So we need an additional attribute in HTMLCheckMatrix for aria-labelledby so the Echo extension can make a use of those for accessibility?

Gonna look later on my PC at home if my changes work, after that I will upload my patchset :)

This should do the trick, patch is coming in 15 min.

Expanding the regex with an alternative variant should fix it for now, until the older Python support won't be dropped.

Thank you @matmarex for your review :)