Translating talk:Localisation for developers

Note: this text was initially in Translating:Localisation for developers, but it was deleted by some admin not understanding this issue which is still there since years.

Restored here, because this bug still needs tracking on this Wiki which is affected since very long (without any change by translatewiki admin to try solving it, even if it is demonstrated here, even if it affects also many other wikis using the same SemanticWiki extension, where their admins still don't have any hint about what to do for at least paliating this problem).

Due to a bug in the "SemanticMediawiki" extension of Mediawiki, an addition/change/removal of categorisation for any created or modified page, may unexpectedly and unpredictibly lock this page permanently after the edit is saved. Anyone is seeing the message at top of the page, when trying to edit such page, and the page would then be uneditable by anyone, even by a site administrator (unless a specific admin-only but dangerous tool is used that will bypass many checks for replacing any content in "raw mode", or they use admin-only tools to directly update the SQL database, which can further break normal caching behavior of MediaWiki, or could seriously damage the data integrity of SemanticMediaWiki):

You do not have permission to edit this page, for the following reason:
⧼Smw-change-propagation-protection⧽

This is apparently caused by a race condition where a background job can be set to run later in one thread, when it has in fact already run in another thread and terminated trying to remove this temporary status, before the pending "Change propagation::+" status has been actually stored in the database. (See initial bug 2494 in GitHub, opend on 3 Jun 2017 then closed without being fixed, then bug 4344 still unsolved since 27 Oct 2019). However some other investigations found that it may be related to lack of synchronization between different caches, with a normal database cache used by the front webserver for navigation and page editing, and another optimistic fast cache used temporarily in memory only by the background CLI jobs, whose state is cleared but never reflected into the normal database cache used by the front webserver to check the editable status of these pages (these CLI jobs do not lock any normal database records, and also do not monitor concurrent changes on the datase possibly made interactively on the front server, they assume database caches are coherent, but unfortunately they are not).

Currently, these affected pages are the following (new pages may appear at any time, refresh this list by clicking the UTC clock gadget displayed at top of this page; you can activate this gadget in your preferences) to run again the SemanticMediawiki query and regenerate this report):

{{#ask:Change propagation::+

|?Modification date#-F[Y-m-d H:i:s]@en
|sort=Modification date |order=asc
|offset=0 |limit=500
|link=all
|format=table |class=wikitable sortable smwtable
|headers=show
|searchlabel=more... 
}}

---

Also, there are some additional categories showing this related message in a red banner when just visiting them:

⧼Smw-category-change-propagation-locked-error⧽

They seem to use another SemanticMediaWiki property (still not identified). May be this is not a property but a bug that occured while the background job was running then failed, causing the job to remain in unterminated state, even if the change propagation property was removed, but this has the same effect and the affected page are also locked and permanently left not editable (no pending job will remove this broken status).

This last bug seems to affect double redirected categories (with a false unchecked assumption made by the SemanticMediaWiki background job, causing it to crash prematurely): they are listed on Special:DoubleRedirects but it's not possible to fix these broken redirects to the correct target category: when editing them, the first message shown above appears. This is not caused by the same SemanticMediaWiki property, but by another internal state (still not determined); this state is possibly not stored in the database by a documented property but could be caused internally by the hook code of SemanticMediawiki extension itself.

Note that SemanticMediaWiki is not supposed to manage any semantic properties for redirected categories that it officially "does not support". However SemanticMediaWiki should not break Mediawiki itself (even if these redirects are valid but the target is also redirected, or because there's a typo made by the contributor in the edited redirect). Hard redirects on categories are possible, useful when they are related to exact synonyms, and valid when they are empty (no members). There are also simple ways to check that they effectively remain empty and maintain this (by using a category tracking template, just below the redirect itself in the category page).

CLOSED This issue is closed by siebrand

Translatewiki and our project seem to have gotten into an unintentional tit-for-tat war over encoding formats. Which of these formats does Translatewiki prefer for qqq.json?

Quotes:

 " or " or \u0026quot; or \u0022

Angle brackets:

 > or > or \u0026gt; or \u003e

Looking at our logs, we see each of the above arriving from Translatewiki at one time or another.

We've recently (a few weeks ago) changed our code to do all UTF-8. So there's no longer \u-encoding.

Why are there no translations for this page? Should it not be translated or are there just no translations _yet_ ?

No need to translate it IMHO.

How is this page different from the documentation there?

The MediaWiki page is for MediaWiki developers. This page is for developers of all current and potential future projects at translatewiki.net.

Yes, but isn't there a lot of general advice on the MediaWiki page? And, doesn't mw:Help:Extension:Translate/Translation best practices also have suggestions for developers which should maybe centralized there?

Is there some way to know how many page visits this page has had?

The mw:Localisation page says: "This page gives a technical description of MediaWiki's internationalisation and localisation (I18N) system, and gives hints that coders should be aware of."

How happy are they going to be that it is extended to cover details of the internationalisation and localisation system on translatewiki.net?

Can you explain a little more about why you are wanting to delete this page? Is it doing any harm as it is now? Is there a project underway to get rid of all help pages on translatewiki.net?

Well, yes, we're trying to improve the documentation pages here. I don't want to delete this page, on the contrary maybe part of mw:Localisation should be merged here, or maybe not; I only want the roles of each page to be clear. The traffic stats are here, they're quite good there.

I have set up a new page as a resource for the developers and project managers of both potential new projects and existing ones - Translating:Localisation for developers

Target audience: Project developers and managers, also providing translators with understanding of project management and communication mechanisms.

Please make additions and corrections.

Thanks for the effort. Not really sure where to integrate this in our current documentation. Any suggestions?

I thought maybe a link from the list of supported projects and the Translating:New project page.

That sounds reasonable ... Please be bold :)

 Done - please reword or delete if preferred.

Thanks. I have reverted the change in Project_list.