side effect : 'json comments should not be highlighted' discussion -> https://www.mediawiki.org/w/index.php?title=Topic:Xg62nn9s3le2lhns&topic_showPostId=xg62nn9s3pc4tlm0#flow-post-xg62nn9s3pc4tlm0 related to page -> https://www.mediawiki.org/wiki/Extension:Graph/Interactive_Graph_Tutorial

Notice also that reference to such an anchor has a strange format but works on the EN root page -> https://www.mediawiki.org/wiki/Manual:Configuration_for_developers#Configuration_using_extension.json_.28recommended.29

See also -> https://www.mediawiki.org/wiki/Manual:Configuration_for_developers/fr?oldid=5865490#Pour_les_extensions
where there is no explicit link but a tvar declaration as:

Thanks all; I tried the proposed workaround 'translate nowrap' and additional span text no longer appears.

Connexion ok today; sounds normal.

MediaWiki-Special-pages

Normal behaviour has been observed back today. Item shown immediately after translating a random message from within the page. No specific action done.

yes, same situation 2 hours later.

I understand - Im translator admin so i could try the 2 recurrent first steps as we did on Mediawiki in the early days, waiting for upper decision . Thanks Nike.

Cannot save again, same problem today on KDE Techbase => https://techbase.kde.org/KDE_TechBase:Contributors

This impacts also other wikis which frozen the translations of new items. This is the case in [Kde https://userbase.kde.org/Special:Version] sleeping for days
MediaWiki 1.31.7 (e5ad47d) 26 mars 2020 à 15:05
Translate 2019-04-24 (0e35cb0) 24 octobre 2019 à 20:14

still actual

My OS: Windows Vista family Ed premium SP2.

My browser =>Firefox ESR 52.9.0 32 bits.

similar skip detected as long as banner is open => https://www.mediawiki.org/wiki/Topic:Vi6zfn6099atwqp6 which disappears once banner is closed

POINT 4 concerning the 2 french columns: solved, the 'toolbar' Ciencia spoke of is a magic selector of Chrome you must be aware. If it is set on 'français' chrome translate automatically MediaWiki english contents into french so you see two french columns which leads to nonsense for the translator. Now if you select 'english' then left column remains in english and the right one in french which is consistent with desktop behaviour.

I agree with you that on the tablette, there is a 'toolbar' at the bottom of the Chrome window. I dont when it comes from. Any 'normal' page has not this tool bar. It appears always when I click on the link 'Translate this page' calling the page with two columns for translation. But the problem is that 'Je fais' of box 'Search for a language' is opened when you click on the link 'Taduire en XXXXX' that means from Mediawiki CSS and NOT from the toolbar (which has its own list opened using the 3 vertical dots).

Arggr even consecutive dummy updates cannot make the translated messages appear (messages are translated but the /FR subpage is not present; ref. => https://www.mediawiki.org/w/index.php?title=Extension:GeoData/geo_tags_table&diff=3566157&oldid=3566151&diffmode=source

Response to Pols12 => I can open the page and access to translations (it is long) and have translated a few dates successfully as => === 20 février 2019 === on a french translation => https://meta.wikimedia.org/wiki/Community_Tech/Who_Wrote_That_tool/fr . So your issue has not appeared on my side.

28 novembre 2019 à 12:57 diff hist +1‎ Community Tech/Who Wrote That tool/fr ‎ Created page with "=== 20 février 2019 ===" actuelle

A lot of translated messages do not appear after page purge and reload (but problem of title message has not appear since a long time) . Workaround: doing the dummy update on root EN page to unlock all at once

12:49, 28 November 2019 Wladek92 talk contribs marked Help:RevisionDelete for translation

Thanks to @Ammarpad he has changed locally
{{git file|project=mediawiki/extensions/AdvancedSearch|branch=HEAD|file=docs/settings.md|text=docs/settings.md}}
into
[https://github.com/wikimedia/mediawiki-extensions-AdvancedSearch/blob/master/docs/settings.md docs/settings.md]
which provides now a true link.

I observe back now 'normal' behaviour of the functionality; situation is stable in a positive way and has improved for these last few days. : generation of articles to translate is done in one shot operation, immediate integration of translated articles just after translation and reload. Thanks.

Yes I confirm new articles can now be saved just after 'translation requested' has been executed (which allow to progress in the article list => good) but they are not yet rendered; a 'Dummy update' of the root page is needed to see all translations together.

When the previous side effect appears, translation is accepted but when reloading the page (even with purge action) the translated text does not appear. Returning to the message, translation is present and warning panel 'Title does not correspond to a translatable message' displays again.
see => https://www.mediawiki.org/w/index.php?title=Translations:Skin:Timeless/23/fr&oldid=3499936
Applying Dummy Update on the root EN page unlocks the situation and previously translated text is now present in the generated text without new update of the message.
=>https://www.mediawiki.org/w/index.php?title=Skin:Timeless&diff=3499938&oldid=3499922&diffmode=source

• just created new articles this morning for => https://www.mediawiki.org/wiki/Skin:Timeless/fr
• => https://www.mediawiki.org/w/index.php?title=Skin:Timeless&diff=3499791&oldid=3499788&diffmode=source
• behaviour was back ok and I could save my translations in one shot in a normal way

ok i will tell whether the problem still appears - thanks.

worse: pb appears again just now => https://www.mediawiki.org/w/index.php?title=API:Alldeletedrevisions&diff=3495354&oldid=3495342&diffmode=source

seems better performances observed on Translate on mediawiki.org thanks.

I hope so; 2dn url can give datails but Translatewiki is very poor concerning the origin of the string to translate.

I am also impacted while translating Help:New_filters_for_edit_review/Filtering/fr providing a mess in the generated text. IMPORTANT => translations must be blocked if they are subject to be cancelled later to avoid useless work !

It occurs for first revision, as for correction of an already translated text. Workaround: applying @Shirayuki 's proposal, I correct the translation adding a dummy modification (one space after last character of the translated string) and then reload the page => updated text is then taken into account.

It appears that the anchor is not disturbed when I remove the markup * and : (bullet lists/tab) from the text of template hidden parameter 2=...

Concerning my tests on laptop, results show the same behaviour, whether I access the page as an anonymous user or as a connected user @Wladek92. I dont use incognito window.

After some investigations I can say that @Shirayuki is right. My conclusions are the followingː

ok that means there is no problem.

Please take into consideration misaligned anchored text : https://www.mediawiki.org/wiki/Topic:V888vjhhcd047hip

Building the page markup, I observe from a practical point of view that it fails each time. But if you have modified tanslation units already existing at step n-1, the translated text you will enter will be accepted. Failure appears with new created translations unit in the EN text.
When you redo what people call a dummy update of the EN text, or if you go further creating new units, you will then validate the pending new previous one (of step n-1) and push the problem one step forward.

The problem seems to reach also other wikis : similar behaviour (cannot save the translations) has been observed on KDE/userbase (see https://userbase.kde.org/Thread:User_talk:Yurchor/help:_cannot_save_the_FR_translations)

Any clever proposal to help the translation ? isolate the common name from the objet name ? but where is the object name in the string ? ...

? may be Edit Package package configurations' ... but still confusing for translations

Estimation: about 50 % of the translation requests I do must be requested again.

adding me to the list - talk https://www.mediawiki.org/wiki/Topic:V4lcdy7gtnspwywl

Still occured today on mediawiki. Then I made a dummy modification in a EN message of the page (delete one 'a' and reinsert the 'a') before resending 'for translation' . It worked. And I noticed the log only register one action 'sent for translation'.

oh yes it is very clear, thank you. The 3rd point has been detached from here and moved consequently to additional new task : https://phabricator.wikimedia.org/T228572

hi all I trapped in 'The title "Translations:Extension:GoogleLogin/Page display title/fr" has been banned from creation. It matches the following blacklist entry: " .*g+(o+)g+le?\S?((?!Summer of Code\/\d{4})|(?!Code-in\/\d{4})).*"

same again today Jul 5,2019 in Mediawiki on:

Updated in MediaWiki:Metadata-langitem/fr :

Sounds better replacing
<languages/> by {{Languages}}
but I m a bit lost of what to use exactly.

I noticed also that if I select english in the very top banner of the page (near username). And then in the box Other languages I select French then the top banner updates AUTOMATICALLY and switches to français . waow !!!!

In mediawiki I speak of similar problem (see https://www.mediawiki.org/w/index.php?title=Topic:V1r4zru368o47cb9&topic_showPostId=v1r4zru36cm6fg9h#flow-post-v1r4zru36cm6fg9h ) .
Nevertheless (?palliative) I can access to release note of version 1.18 using
https://www.mediawiki.org/wiki/Template:RELEASE-NOTES
You can link to a specific release notes file via {{RELEASE-NOTES|version}}, e.g. {{RELEASE-NOTES|MediaWiki 1.31}}
All release notes seem accessible under :
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+refs

Hi all , problem still met on meta this evening. On message Translations:Communications/Organization communications translators group/39/fr

Referenced on Github as -> https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/3878

... as a workaround when I get the link of the message and if i see semantic mediawiki, I refer the pb to github. Seems to work since Karsten /kghbln answers.

... it would be nice to redirect to Github from translatewiki.net for these messages. Users are shown the form on Phabricator.
Aklapper has answered for my prev remark https://phabricator.wikimedia.org/T219597 - i guess the current one is similar.

ok Nike I 'll do see -> https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/3860#issuecomment-478149397 .

Just to precise to àAklapper that I have added NO projects. When you request help from TranslateWiki.net and this help leads to the creation of a new task in Phabricator, the impacted groups (projects) are set automatically when the form opens. If you disaprove the identity of these projects, may be there is something wrong in the preinitialisation of the form but I hardly comfirm I do not manipulate this field.

Sorry, cancel this request please, because i think those are delimiters.