I found a workaround. On Android, there are two paste options: "Paste" and "Paste as plain text".
Only "Paste as plain text" works correctly in this case.
It took me a while to notice this because I'm a beginner.

It appeared to work on the mobile view, but the pasted content was not submitted correctly and disappeared.

In T292352#9810636, @Jack_who_built_the_house wrote:

There should be a way to have static section links without resorting to this, especially if, AFAIU, this is essential to pages with Translate where you don't have static headlines because each languages has its own? If yes, then, to be honest, the {{anchor}} placing at all seems like a hack which should better be solved by correct section redirecting from Special:MyLanguages/ links, based on the English translation or something. Correct me if I'm missing something.

As mentioned above, there are cases where Template:anchor is placed before a section heading.

{{anchor|section 2}}
<translate>

It appears that the default value of $wgSVGNativeRendering is set to the string 'false'.
Therefore, I have written it as such on MediaWiki.org.
However, wouldn't it be more appropriate to set the default value as the boolean false instead?
https://www.mediawiki.org/wiki/Manual:$wgSVGNativeRendering

I am no longer able to reproduce the issue on translatewiki.net.

I have run composer update --no-dev. Should I run without --no-dev?

Screenshot of Special:Nuke on MediaWiki.org

Special:Nuke lists pages in descending order of creation time.
Translation page will be deleted before some translation units.
After deleting translation unit #1, translation page will be re-created.

In the past, Translate extension sometimes failed to update translation pages, so I make an effort to mark multiple times.

The footer comment of DefaultSettings.php was incorrectly reverted. It should be restored.

I noticed that the type of cl_timestamp in categorylinks was changed.
mw:Manual:Categorylinks_table#Schema_summary

In T230428#6362385, @Ladsgroup wrote:

In T230428#6362384, @Shirayuki wrote:

Why did you change the type of change_tag.ct_rc_id?

Looking at the patch it's INT before and after in all three DB engines.

Why did you change the type of change_tag.ct_rc_id?

getLanguageFactory was introduced in MediaWiki 1.35.0-wmf.4

As described above, the following pages have a move log entry as last change.

• https://www.mediawiki.org/wiki/Help:Lint_errors/bogus-image-options
• https://www.mediawiki.org/wiki/Help:Lint_errors/deletable-table-tag
• https://www.mediawiki.org/wiki/Help:Lint_errors/fostered

See the topic "Help:Blocking users/tr is broken" on mediawiki.org
https://www.mediawiki.org/wiki/Topic:V90munh4hps0czom

Yes.

On marking the page for translation, Arabic translation should be marked as fuzzy, but it is not.

I can reproduce this bug on Microsoft Edge 44.18990.1.0 (as an IP user).

Special:RecentChanges and Special:Watchlist shows IP addresses, but action=history does not.

Hello?

Can you make messages translatable?

No, unable to log in as above.

I have tried capital first letter, non-capital first letter and email address.
I can log into wikitech.wikimedia.org.

:(

Change action-* messages, too.

Don't you remove a period from right message?

Additionally I noticed that action-* messages are embedded in another message: "You do not have permission to X, for the following reasons:", so action-* messages should not start with "modifying" and should not end with a period.

@DannyS712 I think the message should start with "Modify". See https://translatewiki.net/wiki/User:Shirayuki/test.
Additionally, "Modifing" is misspelled.

@DannyS712 See https://translatewiki.net/wiki/User:Shirayuki/test. Right-* messages (other than BlueSpice) do not have a period.