Sep 25 2023
Only the user mentioned in the description is affected, so I am speculating that it is something related to the characters Ị and ị (Ị and ị).
Jul 8 2023
Nov 8 2021
@matmarex I reproduced on iPhone using the following steps.
Oct 18 2021
This is not a place to discuss office actions. Please only leave comments related to the task, i.e. related to the future of DPL.
Oct 2 2021
In most cases it is not a good idea to use nested tables. In this case, [[w:ja:Template:Infobox medal templates]] should be changed such that the outer table is implemented with div tags instead. For example, the enwiki counterpart [[w:en:Template:Infobox medal templates]] does it that way.
I suggest closing this item as won't fix.
Aug 30 2021
Update from this, jawiki has a ShortURL gadget enabled by default since April.
Jul 26 2021
The judgment by number of articles is biased. ruwikinews has 1.13M articles but only 11M user views in the past year (per stats.wikimedia.org). This is way lower than wikis of similar size (e.g. arwiki has 1.12M articles with 3B user views in the past year) and is a common feature of wikis where many (if not most) articles are created by bots.
With a second incident, it is clear that the issue will be recurring if we simply re-enable DPL on ruwikinews now. It is not acceptable to enable DPL on ruwikinews at the cost of half an hour downtime per year (or more) on 900+ wikis. From T262391, it is pretty clear that DPL is not, and will unlikely be, actively developed in the near future. With this in mind, ruwikinews probably does not have a choice but to move their DPL uses to bots, at least in the short run.
Jul 17 2021
I wonder if we could have a version for other wikis as well (e.g. enwiki as the largest one, jawiki as a sample for wikis with more unregistered users), probably on a separate page.
The data we currently have allows a comparison of ptwiki before and after editing by IP editors was turned off; having other wikis would allow us to make sense of ptwiki data before turning off editing by IP editors, especially on how similar/different the situation was between ptwiki and other wikis, so it is easier to assess whether the ptwiki experience could be applied on other wikis.
Jul 14 2021
Other than T286362, which is a bug, I would like to mention one more potential problem in the mw-*-media tags - namely, adding/removing maintenance templates, such as Template:Unreferenced, triggers the tag.
Since the template contains an image (the book icon), this is not a bug. However, it may hamper the usefulness of the tags for the purpose of this item.
Jul 9 2021
Jul 5 2021
Note: This bug report arises from the help desk on jawiki, at w:ja:Wikipedia:利用案内#記事が大きすぎてAPIでの取得ができないページがあります.
Jan 22 2021
Jan 18 2021
Nov 16 2020
@Urbanecm, thank you for looking at this item! In that case I will consider the gadget solution for other wikis at this stage.
Separately, perhaps we could still enable the link for metawiki?
Oct 17 2020
It is 3 months since the extension was disabled. When will any news be announced?
Sep 30 2020
Users editing and viewing from mobile website only do not use desktop skins, and therefore do not have a reason to switch away from the default value. Therefore, the percentage for Vector includes many mobile-only users who do not actually use Vector skin.
With the above reason, I suggest excluding mobile-only users (defined as users with only edits tagged with "Mobile web edit" in the past year) next time. Not sure if it is doable though.
Sep 18 2020
Sep 13 2020
- Prototypical discussion page: Not sure what exactly is needed, so I created [[w:ja:Wikipedia‐ノート:井戸端/subj/返信ツールをベータ機能として導入する提案]] and stated that it is for testing purpose at the top of the page. Let me know if you need any changes.
- Configuration: Created [[w:ja:MediaWiki:Discussiontools-signature-prefix]]. Anything else?
Sep 11 2020
Sep 9 2020
From the description, it is not that clear on how the scripts should be fixed.
Is it simply the following replacements?
.menu -> nav ul .vectorTabs -> .vector-menu-tabs .vectorMenu -> .vector-menu
(By the way, I am not sure how we should fix https://ja.wikipedia.org/wiki/User:Hiroakikawa/_vector.css)
Aug 31 2020
Jun 27 2020
May 20 2020
May 8 2020
Thank you! It looks fine to me too.
May 6 2020
Jan 25 2020
@Dzahn I guess the question then becomes - why were they disabled?
Oct 21 2019
Sep 7 2019
Aug 5 2019
Thanks - the issue in jawiki appears to be fixed now.
May 22 2018
For jawiki, I just posted it at [[:ja:Wikipedia:お知らせ#2018年5月29日のメンテナンス予定]].
Also would like to second to Elitre - in the future, please allow 2 weeks between announcement and action.
Apr 12 2018
Apr 8 2018
Apr 7 2018
Is it too late to add more wikis to this item? Have fixed most high priority lint errors in jawikibooks and there should be fewer than 50 of them now.
Mar 31 2018
@Mvolz: Citoid is now enabled in Japanese Wikipedia. Do we know what is the plan for resolving issues 1 and 3?
Mar 15 2018
@Mvolz: We have not received any objections so far regarding the change in Issue 2, as well as enabling citoid before Issues 1 and 3 are implemented. Nevertheless, we still need to know when we can expect the implementation - is there any timeline currently?
Mar 12 2018
@Mvolz: Thanks! I will bring the suggestion regarding Issue 2 back to the discussion and seek for opinion. We will also confirm whether we could enable citoid first, while waiting for Issues 1 and 3 to be implemented.
@Aklapper: Please find the following.
Jun 19 2017
Hope I am not too late to chip in a reply -
Why is an explanation needed? For average users they probably only want to see them linked, and that's it.
Your argument is that nobody will care enough to make links? This seems to point to the questionable value of having the links at all, if nobody is using them or interested in supporting them.
We don't have unlimited manpower. I am from the Japanese Wikipedia, where the user base is broad but the number of people able to (let alone interested to) support is really thin. Simply being "different and inconsistent" (or other technical reasons) is not a valid argument to cut a working feature and increase the already-too-heavy workload. If it is not like MediaWiki will break down tomorrow, can you please revise this decision to drop magic links?
(Adding one footnote: using a bot increases the number of revisions and uses up some manpower so that doesn't change my argument.)