I mean for external access (beyond Lua). Of course, we can access translations via meta=messagetranslations, but an endpoint that provides the already translated JSON would be convenient.

Em T386307#10548993, @Nikerabbit escreveu:

Access to translations (with fallback language handling) will be provided by APIs.

Is there any prospect of when this could be implemented?

The main problem for me is that all posts not in English are completely inaccessible via the API, unless queried directly by their IDs. Since I'm working on a project and this issue is kind of a dealbreaker, I built a small tool on Toolforge to work around it.

Sorry about that. I hadn't received a notification regarding this issue and only found out about it now.

Log: https://phabricator.wikimedia.org/P74490

Regarding the task for the logo itself, its done.

Well... almost three years later, this problem has apparently resolved itself.
¯\_(ツ)_/¯

I've add the translatewiki bot to bypass the branch protection. It should solve the problem.

Em T385291#10512674, @aborrero escreveu:

is the error happening every time you visit that URL endpoint? https://alberobot.toolforge.org/blockrollback.php in other words, is this reproducible?

Or is that error message being cached somehow?

It's a simple script, made just to control a bot to do maintenance edits on ptwiki, so there is no cache system.

@abi_ Done!

The bug apparently disappeared. I'm marking it as invalid, which seems to be more appropriate for this case.

Em T366062#9837991, @Dreamy_Jazz escreveu:

Considering this isn't a bug per-se (because this was specifically intended in the patch that added the sorting), I am marking this as a feature request.

In other words, we have a classic case of "it's not a bug, it's a feature". hahaha.

Em T365482#9817914, @Umherirrender escreveu:

Try the history view on special:undelete to find the revision

Doesn't work for me. When I try https://fa.wiktionary.org/w/index.php?title=Special:Undelete&target=TimedText%3ANational+Anthem+of+Islamic+Republic+of+Iran.ogg, it shows what looks like another page with the same title, but this revision is not there.

Em T362068#9799568, @Slst2020 escreveu:

@Albertoleoncio I know you managed to get this working and wrote some docs about it, would you mind adding a link in this task?

Em T361622#9779696, @Dsvyas escreveu:

Thank you for this, however magic word EXPECTWITHOUTSCANS doesn't seem to be active on gu.ws yet as the main page{F50929864} displays this as text when added.

I miss some documentation about executing commands in non-interactive mode and deployment integration with, say, GitHub Actions. I found a use here, but it's not very clear how it works and how to reuse it in other tools. This could be useful for, for example, automatic database migrations via Django, building applications using NodeJS frameworks, etc...

FYI: We noticed a small bug in the pt.wiki MediaWiki:Deletereason-dropdown as {{ns:2300}}/{{ns:2301}}/{{ns:2302}}/{{ns:2303}} was no longer valid. It may be worth doing a scan to identify whether those is still used in other wikis.

@Slst2020 I'm having a problem with credentials. I don't know if I'm running it incorrectly, or if I'm missing some permission.

@abi_ @Nikerabbit Hello! I submitted this patch after reading a complaint via Telegram, but it is still awaiting review. Are there any blockers or concerns against approving this request?

Em T357227#9531879, @taavi escreveu:

Hi. How is this tool different from the Cloud VPS project of the same name?

Em T349452#9271561, @taavi escreveu:

Fixed with https://gitlab.wikimedia.org/toolforge-repos/fourohfour/-/commit/c9b6facdcdc6c302c1d1510603b84fea255d2993.

Em T347244#9246146, @abi_ escreveu:

In T347244#9236236, @abi_ wrote:

In T347244#9231090, @Albertoleoncio wrote:

Well... It didn't. Is there any way I can activate it manually? Or can I just download the JSONs?

This happened there were some changes made to source strings (English) that need to be manually reviewed by administrators. The system blocks exports until these have been reviewed. I've now reviewed them, and translations should be exported out on Thursday.

We again had changes pending for review from the project due to changes to the source language so exports were skipped again. I'll try to review changes before the exports next Monday.

Em T347244#9219851, @abi_ escreveu:

I'd still like to monitor to see if the automatic push works. We should be pushing out translations again on Thursday.

Well... It didn't. Is there any way I can activate it manually? Or can I just download the JSONs?
Another thing: I had published the Brazilian Portuguese translations as "pt", but I noticed that they had started translating as "pt-br". To avoid duplication, I renamed the file on GitHub but the change was not replicated on TranslateWiki.

@abi_ I saw that the translations were already published today on GitHub, but not to WikiScore. Something went wrong?

1. The project is missing the message documentation (qqq.json file). You can read more about it here: https://translatewiki.net/wiki/Translating:Localisation_for_developers#Message_documentation and you can see an example of how this file looks here: https://github.com/toolforge/video2commons/blob/master/video2commons/frontend/i18n/qqq.json

I never did documentation for each variable. Would it be possible to do it directly on TranslateWiki?

Em T261133#8995742, @Xaosflux escreveu:

Last I checked ptwiki is preventing this "server side" (via https://pt.wikipedia.org/wiki/Especial:Filtro_de_abusos/180) not client-side, such as by javascript.

This too. We have:

• Two scripts that directs the logged out user to the login screen when he clicks on the edit link.
• The filter that prevents logged-out users from editing and
• Several IP range blocks that block the busiest ranges, "alleviating" the abusefilter.

Allied to these measures, we modified some messages in the MediaWiki (example) so that it does not appear that our future editor is "blocked" or that he is "prevented from editing", just that he needs to create an account first.
It sounds confusing, but works like a charm.

Em T261133#8994615, @stjn escreveu:

Coming back to this 3 years later: if ptWP was allowed to proceed with their IP edit ban, it should still be done on the server side, not on the frontend.

I've been thinking about this for a while now, but today I'm not sure it's a good idea. Everyone is happy with the way it's working and moving to a server-side configuration could break some part of the current workflow (special attention to T287228).

Also, Farsi Wikipedia was allowed a configuration change in T291018: Temporarily disable article editing by anonymous users on fawiki

And we had different results, where part of that could be attributed to the way it was implemented.

Done!

Done!

Em T338946#8927738, @Lucas_Werkmeister_WMDE escreveu:

It doesn’t prevent linking pages. Removing them from the Special:UnconnectedPages listing is all it does.

Oh, OK. It does less than I thought.

Personally, I’m skeptical of changing the interpretation from “it’s fine if there’s no connected item” to “it’s mandatory that there’s no connected item” – but that’s for Product to decide.

I've modified the description a bit to make the issue clearer. It's not that I want to be mandatory, but that at least the pages that have this magic word don't have that "appearance of incompleteness" because they don't have a connection to Wikidata.

Em T337127#8926254, @Xqt escreveu:

@Albertoleonico: I don’t see that this is about Pywikibot currently. Is adding the tag meant to continue this project under the coat of Pywikibot to continue this task and integrate it to their scripts collection somehow? Or what is the reason for the Pywikibot-Scripts tag?

Just to contribute some post-deployment ideas, I recently made an accessory tool to ptwiki's SBL that provides some relevant information about the inclusion of an URL, mainly the timestamp, the author of the inclusion and a link to their edits on that day (sometimes the author's explanation is a bit hollow, while their before/after edits helps providing some context about that URL).

@SCherukuwada I have an interesting one: [[:s:pt:O Movimento Modernista]]

Em T336255#8872340, @KFrancis escreveu:

Can you also please give me a little more information about what type of access the volunteer will need? I usually process for things like access to the LDAP Group. Is this similar?

Example:

What was initially requested has already been done, so...

1. Editor is FlaggedRevs' user group, once we remove it from wiki, it will disappear. Patrolling edits is better and easier mechanism than FlaggedRevs for small and not really active wikis.

@Kizule

1. Do you want patrolling option (like on Wikipedia) to be enabled back? With autopatrol, patroller and rollbacker rights.

I myself don't believe it's necessary, as we don't even have users to patrol edits. However, I think it's useful to keep the editor group and associate it with an intermediate level of protection for pages (between autoconfirmed and sysop). I imagine this requires another ticket, but the group could be maintained without any special privileges until then.

2. If extension won't be enabled again, do you want FlaggedRevs tables from database to be removed?

Could we do the same thing as T209761#4812733, but keep the tables for like... 6 months? The extension would be unlikely to be reactivated again, but there wasn't exactly a big discussion and the tables are small in terms of storage, so I think keeping them for a reasonable amount of time would be convenient, just in case.

In T331163#8672274, @Aklapper wrote:

Hi, I am afraid I cannot fully follow. :( Could you please provide a list (!) of steps, provide the exact names of templates in those steps, and directly link to page revisions in those steps, plus provide the exact and full error message after these steps (and maybe a screenshot)? Thanks.