Please revert this ASAP, this was never approved by our community and has basically broke the translation tool for us. See here:

This task was never "resolved". It was declined due to prevalence of individual POV of phabricator admins over the Portuguese Wikipedia community decision, as @Teles wrote above. Changed the status accordingly.

@Seddon Was probably indexed in the last couple of days, most probably related to it appearing on this thread, since many pages created before that one are still not indexed by Google.

A single URL of a work I recently added to ws.pt, and on which I've been working in, appears to have been noticed by Google: https://pt.wikisource.org/w/index.php?title=Página:Elucidario_Madeirense,_1998,_vol._I.pdf/11&diff=471867&oldid=471865

@Dzahn a request for someone to look into this using the Search Console counts as that?

In wiki.pt, IPs can also go to the talk page and edit it, it was never restricted there. What was restricted was basically main and Wikipedia namespaces. And not all of Wikipedia, I seem to recall. They still have access to problem report and help request pages. However, with talk pages being one of the most non-functional features of mediawiki, and with recent surges of IP vandalism there, I'm not so sure they would still be allowed to edit there nowadays. Much pain and no gain.

@Reedy This task was closed as resolved, but the error is still there...

Is this related to this significant problem with categorization we started noticing at Commons? - https://commons.wikimedia.org/wiki/Commons:Village_pump#Category_autocomplete_is_now_case_sensitive

In T291018#7358134, @Ladsgroup wrote:

Using Chrome and having the same problem in Wikidata when hovering over "add statement". Closing up the "In more languages" panel seems to stop it. Making that panel visible again, makes the big start happening again.

In T265214#6588219, @Trizek-WMF wrote:

In T265214#6585703, @Trizek-WMF wrote:

In T265214#6588109, @Trizek-WMF wrote:

My sympathies to you since I already had the same unpleasant experience.

In T265214#6585703, @Trizek-WMF wrote:

Yes, the questions definitively should be analyzed, because despite the system being cool technically, there's some kind of flaw that is rendering it quite below an optimal state.

In T265214#6558835, @MMiller_WMF wrote:

@Albertoleoncio -- thanks for working with us on this feature and discussing it. @Trizek-WMF may have other thoughts and responses for you, but I have a question: you said "the feedback from the community has been great so far" about the mentoring feature. What are they saying? We are interested to know what is working well so that we can think about how to augment those good parts.

In T263943#6496565, @Aklapper wrote:

@Darwinius: Hi, which exact Wikipedia app is this about (Android? iOS?), and which app version?

Portugal total is already over 11000, but seems to be stuck at 9800 in the tool...

Now Armenia, which was around 15500, is at 12100:

In T261133#6496682, @Aklapper wrote:

Hi, while this is an interesting conversation, discussing where which languages are spoken doesn't feel directly related to the topic of this ticket.
It would be nice if you could consider taking that conversation to a better suited venue, e.g. on-wiki. Thanks for your understanding!

In T261133#6496627, @Jane023 wrote:

In T261133#6496570, @Darwinius wrote:

Why Yoruba?

Interesting! I was under the impression that it is one of the official languages of Brazil, which would indeed be very weird if no one spoke it there

In T261133#6496568, @Jane023 wrote:

In T261133#6496558, @Darwinius wrote:

what you really have there is the descendants of the actual colonizers and the ones enslaved by them, as well as a lot of other ppl that migrated there after independence of the territory was granted to the settlers (at least this is how ppl generally identify themselves there)

Perhaps an analysis of the overlap between the Yoruba and Portuguese wikis might help shed some light on the problem then? If the overwhelming majority of abusers are in the overwhelming majority of readers (which would be a logical conclusion), then perhaps some of the vandalism is shared by both?

In T261133#6452577, @Tgr wrote:

In T261133#6444658, @Darwinius wrote:

If it's me creating the accounts, they start already confirmed? Or do I still have to confirm them?

You still have to do it. (Automating that is not a bad idea; I filed T262621: Add checkbox to account creation form for making the user manually confirmed.)

In T261133#6495820, @Jane023 wrote:

In a way, it is a breeding ground for social unrest on a global scale against colonial views and antiquated notions of what we like to call "reliable sources".

I just tried again yesterday, and confirmed again that while editing what teh app wrongly calls "article description" - in fact, the Wikidata description - there is not any information anywhere stating that your IP is going to be revealed. I consider this a security problem of some severity.

In T261133#6444511, @Tgr wrote:

The captcha conditions for IP editors and non-autoconfirmed editors are identical (inserting external links). Admins can manually confirm new users, that might be a worthwhile thing to do for outreach events. (Likewise, you can ask participants for their preferred username at the start of the event, and create their accounts for them, so they don't have to deal with the captcha.)

In T261133#6444390, @Tgr wrote:

For background on captchas at registration, see T241921: Fix Wikimedia captchas. It's an unfortunate situation, but there is no easy way to improve it.

In T262320#6444369, @Reedy wrote:

In T262320#6444340, @Darwinius wrote:

I believe the warning should not be displayed before editing, but before saving, which is what really counts.

That might be an addition to be made. IMHO, I don't see anything wrong with the notification being there (as well) before actually making any changes. It saves people making the edits, then the edit being discarded when they don't want to save the changes and have their IP exposed.

In T262320#6444274, @Reedy wrote:

Edit unregistered using Visual Editor in desktop mode (in a laptop, using the Private Window feature of Firefox)

seems to be the same as

In T261133#6444121, @Dcljr wrote:

In T261133#6443731, @Darwinius wrote:

In T261133#6443939, @Majavah wrote:

In T261133#6443911, @Darwinius wrote:

In T261133#6443906, @Majavah wrote:

[...]

No, it does not. I just tested (again), and nothing of that sort appears. Not in the Wikipedia app, not on desktop mode, and not in the mobile mode (which I just tested again 1 minute ago, just to be sure).

I just tested all three myself (and took screenshots visible on my comment), and every method I tried tells it very clearly. Did you try it in a private window (where there aren't any cookies which may remember you dismissing such popups earlier)?

In T261133#6443939, @Majavah wrote:

In T261133#6443911, @Darwinius wrote:

In T261133#6443906, @Majavah wrote:

[...]

No, it does not. I just tested (again), and nothing of that sort appears. Not in the wikipedia app, not on desktop mode, and not in the mobile mode (which I just tested again 1 minute ago, just to be sure).

I just tested all three myself (and took screenshots visible on my comment), and every method I tried tells it very clearly. Did you try it in a private window (where there aren't any cookies which may remember you dismissing such popups earlier)?

In T261133#6443906, @Majavah wrote:

In T261133#6443878, @Darwinius wrote:

Another very alarming, dangerous and worrisome thing: Anyone editing unregistered at wiki.pt both through the Wikipedia app, and through Visual Editor (mobile or desktop) is not aware in the least that they are revealing their IP to the world. There is no warning, no information, nothing. The person simply saves the edition, and their IP gets revealed without any kind of warning nor consent. You can imagine the kind of (even possibly fatal) danger this kind of thing represent, even to registered editors who log out by accident and do not realize they are logged out when they edit? There have already been documented cases of people persecuted in their workplace and menaced with judicial process for doing controversial editions unregistered at wiki.pt. It's not even theoretic anymore.

The visual editor shows this popup by default:

The Android app also tells this at least in English:

In T261133#6443814, @Ladsgroup wrote:

Request of enabling CAPTCHA for IP edits in ptwiki was similarly declined on 2013 by Deputy Director of WMF at the time on similar grounds: T51860#589243 ptwiki is not first wiki to make such requests and all similar requests have been denied already

In T261133#6412345, @Tgr wrote:

Suggesting changes to founding principles, or asking that a certain project be exempted from them, is a valid discussion for global community forums like Meta or wikimedia-l. (Not one that's likely to succeed, but valid nevertheless.) Phabricator is not such a forum. (See Phabricator etiquette.) Please do not get into policy debates here, you will be wasting your time, and you will be wasting other people's time too.

De facto policies around anonymous edits have been shaped by research on the value of IP editing. If you want to have a productive discussion about whether those policies are wrong for pt.wiki, or in general, engaging with the arguments made on that page is probably a good way forward.

In T261133#6418392, @Juan90264 wrote:

In the discussion of the Lusophone community, I was in favor of banning IPs, as they are the main vandalists of Wikipedia Lusophone; but the foundation principle says that

The ability of almost anyone to be able to edit (most) articles without registering.

she says without registering, it is an easy matter to assimilate; it is not a condition, in which if the community accepts the ban of IPs; banning happens. It is a condition, which I even understand why WMF employees refuse; I sincerely think it is even better to use the abuse filters and tools against vandalism, for example: Huggle - That it is easy to detect vandalism, and reverse it. I will exchange my vote for a disagreement for the part of the possibility that an abuse filter is possible, since the filter will monitor the edits by IPs and be able to revert it if it is vandalism and would not have to ban IPs; that I violated a pillar of the foundation's principles.

In T261133#6418058, @keynote2k wrote:

In T261133#6407690, @Darwinius wrote:

I must had that I had (informally) consulted with 2 WMF employees last November, while at Wikindaba (Christel and Tony, from T&S, after an workshop related to IPs and security) about the possibility of a project community to decide to exclude edit access for IPs, and they said that we just needed to obtain visible consensus for it at our community, and present it to the developers. Now you say it can't be implemented because of what, really? What is the argument for not respecting an entire project community decision, in case consensus is obtained there?

HI, all. @Darwinius: I do not recall the conversation in question. To clarify, the Foundation's Legal department is happy to assist if needed to assess the legality of configuration changes to projects. We are not the arbiter for whether a configuration change should be made. If Christel or I said anything at Indaba that implied that a project could unilaterally approve such a change (i.e., without consensus from the developer community and/or input from the systems administrators), please attribute it to a miscommunication.

Legal is very aware that Portuguese Wikipedia has been struggling with vandalism and spam for some time, and the need for technical support. We are discussing multiple initiatives in partnership with Product that we hope will help.

In T261133#6407977, @Ladsgroup wrote:

Bypassing the protective measures implemented in abuse filter would end up getting reverted and admins of that wiki getting desysopped by the stewards. There are limits to what community can do in a wiki. It's like raising a child, you can raise your child any way you want but there are limits, if you cross those limits, custody of the child will be revoked, try to bypass those limits, there will be similar actions.
It's not dev vs. community, it's rest of Wikimedia vs. that community.

In T261133#6407876, @Krenair wrote:

Note to those I see in the ptwiki comments proposing AbuseFilters: Abuse Filter has emergency checks that will disable a filter matching 5% or more of edits.

$ curl -s 'https://pt.wikipedia.org/w/api.php?action=query&list=recentchanges&rctype=edit|new&rclimit=500&rcprop=user&format=json' | jq '[.query.recentchanges[] | select (.anon)] | length'
113

113/500 = 22.6%

In T261133#6407865, @Krenair wrote:

Yeah this should probably be added to https://meta.wikimedia.org/wiki/Limits_to_configuration_changes

In T261133#6407812, @Demian wrote:

See also https://meta.wikimedia.org/wiki/Talk:IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/Archives/08-2019#Simpler_solution_-_turn_off_IP_editing

To start with I'd be curious whether reviewing IP edits using FlaggedRevs Extension was considered.
Huwiki made a comparison about using or disabling flagged revision, which suggest me that IP edits are better quality when IP edits are reviewed.
Additionally if IP edits are overwhelming, not reviewing the flagged revisions has the practical effect of disabling IP editing.

In T261133#6406865, @Ladsgroup wrote:

This is technically possible but won't ever be implemented in production, being freely editable is one of our five pillars (w.wiki/5) and anything beside these five pillar is changeable (i.e. you can't RFC this, neither in Wiki, nor here), similar to the fact that you can't make content of Wikipedia fully copyrightable even if you have full support of the community.

That being said, it seems obvious that the wiki needs better vandalism tools, like Abusefilter, ores, etc. I recommend reaching out to a larger wiki and ask their help in implementing such tools (like a bot similar to Cluebot NG)

In T261133#6407644, @Yair_rand wrote:

No founding principle of Wikipedia would be disrespected.

I recommend reading the second Wikimedia founding principle: "The ability of almost anyone to edit (most) articles without registration."

@Chtnnh hello! Yes, I hope so. What should I do? How can I help?

Internal error:
[XYN-tApAICsAABr6nm0AAABA] 2019-09-19 13:17:36: Fatal exception of type "WMFTimeoutException"
[XYN-uwpAMFMAAJZQkSoAAACM] 2019-09-19 13:17:43: Fatal exception of type "WMFTimeoutException"

@Aklapper I tried to do that myself, but I was unable to find the other task in the list...

https://phabricator.wikimedia.org/T233269 is about the same problem (please merge)

https://phabricator.wikimedia.org/T233272 is about the same problem

@Lucas_Werkmeister_WMDE looks perfect to me - and the "long-standing idea" you mentioned is something I was also trying to figure how to do, as it would be great to place the Qids there, or to transform them into Reasonator entries, at will.

@Lucas_Werkmeister_WMDE yes, correct.
The first column is not mandatory, as the friendly value could be hardcoded in the query as something like "Official website".

Hello, I'm also trying to do the same to get a friendlier way to present the URL at the digital library I'm building at an external website over wikidata: https://adegi.pt/recursos/biblioteca.
I would really appreciate if there would be some way of hiding the URL with something like "Digital Edition".

Done, created a new task for the credits thing: https://phabricator.wikimedia.org/T231923, thanks.

Thanks!! It's now accepting uploads from Portugal, but the correct monument template is still missing (https://commons.wikimedia.org/wiki/Template:MonumentIDPortugal )

Thanks, the sparql query seems to be OK.

When trying to manually move the file using https://commons.wikimedia.org/wiki/Special:MovePage/File:Sumaúma_(Ceiba_pentandra)_in_Funchal,_Madeira.jpg, it shows: