Hi @QuiFitKiwi. thanks for taking the time to report this!
When you click on the first link directly, can you access the image and is the image displayed in your web browser? If it is not displayed, what is displayed / which exact error message is shown?
Does this problem also happen with another browser (which browser)?
Have you tried to bypass your browser cache?

All items in the list are checked - is there a reason to keep the task status as open (instead of e.g. resolved)?

Is this still a problem?

To everybody who proposed a logo here: It would be awesome if you could add a comment to explicitly license your logo under Creative Commons Attribution-ShareAlike (CC-BY-SA) version 3 or version 4.
(Unfortunately in the Google-Code-in-2017 task we did not ask students/contributors to explicitly define a license for their proposal. That was our mentors' fault.)
Also note that by default, content in Wikimedia Phabricator is "licensed under Creative Commons Attribution-ShareAlike 3.0 (CC-BY-SA) unless otherwise noted" as per its footer.

@Xephyr826: Why was this task declined?

@Mrjohncummings: Could you update this task, as per last comment? Thanks!

@EBernhardson: That makes sense - thanks a lot for your fast comment here (was thinking about CC'ing you on this task but first wanted to try digging myself)!

Hi @DonTrung, welcome and thanks a lot for taking the time to report this!
Unfortunately this report lacks some information. If you have time and can still reproduce the problem: Please add a more complete description to this report (a list of steps to reproduce which leave no room for interpretation what to do, describing actual results and expected results after performing the steps to reproduce, attaching or linking to a public testcase with a complete URL, etc). You can edit the task description by clicking Edit Task.
Ideally, exact and clear steps to reproduce should allow any other person to follow these steps (without having to interpret those steps) and see the same results. Problems that others can reliably reproduce can get fixed faster. Thanks!

• Does this also happen when you are not logged in? You could use a "private window" in your web browser to find out.
• Does this also happen when you are logged in and in [[ https://www.mediawiki.org/wiki/Help:Locating_broken_scripts | safemode ]]?
• Which web browser do you use? Does this also happen when you use another web browser (which one)?
• Which operating system is being used?

@Alsee: No, see https://commons.wikimedia.org/w/index.php?title=Commons%3AVillage_pump%2FProposals&type=revision&diff=292513613&oldid=292508061

Let's put this on hold for the time being while some internal discussions in the team are ongoing.

We don't know where you type. Please see and follow https://mediawiki.org/wiki/How_to_report_a_bug and provide a list of steps, step by step. Thanks.

In T187729#4057648, @Amire80 wrote:

In T187729#4057595, @IKhitron wrote:

Enwiki does not allow anonyms to create new articles, as far as I know. I do not trying to change this, because it's not of my business.

There's ongoing research, which is trying to check whether it's good that this is restricted or not. I don't know what will be the result of this research.

This seems to have been fixed in the meantime. Somehow.

I posted a longer related comment in T188244#4053930

Hi @Awewewe, thanks for taking the time to report this!
Unfortunately this report lacks some information. If you have time and can still reproduce the problem: Please add a more complete description to this report (a list of steps to reproduce which leave no room for interpretation what to do, describing actual results and expected results after performing the steps to reproduce, attaching or linking to a public testcase, browser information, MediaWiki version information, etc). You can edit the task description by clicking Edit Task.
Ideally, exact and clear steps to reproduce should allow any other person to follow these steps (without having to interpret those steps) and see the same results. Problems that others can reliably reproduce can get fixed faster. Thanks!

@Tiven2240: Do not set the Priority if you do not plan to work on this task. We want the Priority field to reflect reality. Thanks for your understanding.

The "Create Task" drop down should exist (like it does on this issue page).

Anyone can add such a link in the side bar by editing the sidebar - see T91829#2037969

I assume this is about Google-Summer-of-Code (2018) ?

Tentative plan for this to go live is April, according to https://gitlab.com/Bitergia/c/Wikimedia/support/issues/18

In T161609#4056088, @Tamgue wrote:

Please for the Gsoc, am I required to use one of wikimedia's outreach projects?

@alanajjar: In general, after someone has reviewed and merged a patch (which has not happened yet), the change will usually get deployed within the next seven days.

@Stryn: How is that anecdote related to this task? I can also type a 255 characters long vandal summary that only contains the letter "m" and the very same problem happens. Feel free to file a separate task about layout breakage as this feels unrelated to the topic of this very task.

Filed https://gitlab.com/Bitergia/c/Wikimedia/support/issues/26 to update data on https://wikimedia.biterg.io/app/kibana#/dashboard/C_Gerrit_Demo (until T151161 is fixed).

Hi @.avgas, thanks for taking the time to report this!
Unfortunately this report lacks some information. It describes a solution but no problem to solve.
If you have time and can still reproduce the problem: Please add a more complete description to this report (a list of steps to reproduce which leave no room for interpretation what to do, describing actual results and expected results after performing the steps to reproduce, attaching or linking to a public testcase, etc). You can edit the task description by clicking Edit Task.
Thanks!

Hi @Niridya, thanks for taking the time to report this and welcome!

@srishakatux and I discussed potential approaches / ideas. The following comment touches both T186721 (to merge into this task?) and T188244, I'm afraid.

• Using https://www.mediawiki.org/wiki/Gerrit/Reports/Open_changesets_by_newbie_owner
  • I don't have knowledge of that tool so I cannot comment.
• Using https://wikimedia.biterg.io/app/kibana#/dashboard/C_Gerrit_Demo to have one list of all patches contributed by new developers.
  • This will require fixing T151161 = https://gitlab.com/Bitergia/c/Wikimedia/support/issues/16
  • Currently cumbersome because you can only see patches for one new author. @Aklapper to find out whether I can have a query ("show me all patches in Gerrit...") based on results of another query ("...written by authors who registered within the last X days") in T189903, turns out this could get fixed by potentially merging DB indices as part of fixing T151161
  • Limitation: Does not display CR-2/-1/0/+1 status as that is not supported by the backend (and likely will not get supported any time soon). (Upstream task)
• Using some dashboard in Gerrit itself.
  • Unclear if Gerrit allows some "show all open changesets by author who registered in the last X days" query criteria. I'm afraid not, looking at docs and tickets.
  • Unclear if Gerrit allows setting up a dashboard at all based on that criteria.
  • Advantage: Would display CR-2/-1/0/+1 status.
  • (Initial poor man's thought was using a user account in Gerrit and https://gerrit.wikimedia.org/r/#/dashboard/self to have such a list of patches under "Incoming reviews" but that would mean it's a single person's account and still does not solve the problem how to get/create that list of patches itself.)

General thoughts:

• I'd currently not investigate creating (and maintaining!) a separate tool (querying Gerrit API) from scratch. Maybe in the long run. Let's start with what's in place.
• Obviously, any workflow should be "public" and not depend on a single person's account's access rights ("my Gerrit accounts 'My Review' dashboard") or mail inbox ("my notifications from Gerrit for those patches by new contributors which I subscribed to") etc.

What's left to do in this task?

@MuhammadShuaib: I don't understand the question. Did you test? If yes, where? If yes, did it work? If not, can you provide steps?

It looks like part of the problem is created by gadgets (which would be out of scope for this task and Phabricator). See mw:Help:Locating_broken_scripts for more info.

That is expected behavior; you need to HTML encode.

In T189767#4052867, @alex-mashin wrote:

The first three bugs that you have mentioned were created by myself (I intend to close them in favour of this one).

That does not sound like a good idea. Ideally, a task should have a clear scope and not be a bundle of several aspects to perform.

CC'ing its maintainers (I assume, as not listed on https://www.mediawiki.org/wiki/Developers/Maintainers ).

In T188149#4052000, @JAufrecht wrote:

Data error for transaction PHID-XACT-TASK-j4goxjs7ynylrym: no keys. Skipping.

Grep'ing for no keys I cannot find any match in https://phabricator.wikimedia.org/diffusion/PHTO/browse/master/public_task_dump.py or https://phabricator.wikimedia.org/diffusion/PHTO/browse/master/wmfphablib/phabdb.py or the Phlogiston code base (phlogiston.py only offers print("Data error for transaction {0}: project {1} doesn't exist.).
Any idea where that error string is triggered / comes from?

-> Packaging

@srishakatux: This happened in March, hence adjusting workboard column.

@TmY_e12: See https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes about community consensus.
Also see https://wikimediafoundation.org/wiki/Resolution:Licensing_policy (for more info) and https://en.wikiversity.org/wiki/Wikiversity:Uploading_files#Exemption_Doctrine_Policy (as one example implementation) for required policies.

The number of such accounts is pretty low nowadays (200) and as we concentrate on development stats this issue does not deserve its own task.

Unfortunately closing this report as no further information has been provided.

The solution depends on someone to analyze, understand, and fix the underlying problem. :)

Has the affected user tried [[ https://www.mediawiki.org/wiki/Help:Locating_broken_scripts | safemode=1 ]]?

@Alsee: Support questions are handled on https://www.mediawiki.org/wiki/VisualEditor/Feedback , not here.

I don't know if "inserting a new tab" is the best solution. I'd recommend to discuss the actual underlying problem (we want a second version of an article, for a different audience) in a better suited and broader venue, like a mailing list.

Why would a re-upload fix some problem?
If for example the thumbnailer indexer ran out of memory (the thumbnails are HTTP 500 errors) as the PDF file is huge, re-uploading won't help with anything.

See T188149#4010091 - clear steps that allow someone else to see the problem, to start with.

Thanks for reporting this. Can you please always include version information for the extension and MediaWiki? Thanks in advance!
(Also, I assume Yaron agreed to be the task assignee?)

See also related T150576, T117819

Please attach a test case that someone else could import: A complete email including its headers.
Please replace any private information (like IPs or email addresses) as Phabricator is a public place.

that would point to the article with a slash

Where would that article for younger people be located? On a Basque Wikipedia sub page, if I get it right?
The whole idea to me sounds a bit similar to Simple English Wikipedia (but of course not in English)?

I have done my research, and it seems that there is an extension for this

The Header Tabs extension is not deployed yet on any Wikimedia sites, so that code would have to go through the review process.

If current workflows welcome improvements I'd recommend to discuss your impressions and ideas with the Design and/or Design Research team: See https://www.mediawiki.org/wiki/Wikimedia_Research/Design_Research for mailing list information (as I do not consider this task in itself 'actionable' currently).

@BamLifa: Where to see that this task has been completed already? Links/references are welcome for any such statements. I don't see any dedicated test file in MediaWiki core's /tests/phpunit/includes/api directory for those two items, and git log includes/api/ApiQueryDisabled.php and git log includes/api/ApiDisabled.php does not show any recent related changes either, but maybe I'm looking in the wrong places?