@Ladsgroup today in Wednesday!

In T432509#12149723, @hubaishan wrote:

DELETE from flaggedpages 
WHERE (SELECT page_namespace FROM page WHERE page_id=fp_page_id) not in (0,6,10,100,828);

@Novem_Linguae no error code, I changed ticket tag

@Ladsgroup We need to run SQL queries in arwiki to clean this bug outputs until it fixed

The cause of this bug is that FlaggedRevs work in template and main namesspaces and does not work in project namespace.
when the page (A) created in template namespace so FlaggedRevs tracked it revisions and the page has record in flaggedpages table.
the bug occuered when page (A) moved to project namespace which is not tracked by FlaggedRevs.
new revisions created for page (A) but untracked by FlaggedRevs.
when page (A) transcluded in page (B) which is main namespace and controled by FlaggedRevs, so FlaggedRevs checks page (A) last reviewed revision witch is outdated before page (A) moved to project namespace.

I think this bug is fixed now

In T423006#11876118, @SanBonne wrote:

Could you describe what you do to fix it? And what was the problem exactly?

After testing this bug is fixed now.

Thank you @Krinkle , I am sorry for misspelling be sure that MoveClaim and also Move is in selected I mean is not selected .
I hope to clearfy this point in https://www.mediawiki.org/wiki/ResourceLoader/Core_modules#mw.loader.load

I support this feature since Transkribus does not support RTL (Arabic, Persian, Hebrew) languages.

arwiki use FlaggedRevs so no need to this line. review right is assigned to editor which work as patrol.

In T368193#10271432, @awight wrote:

There are several related tasks about this bug, but I think this one has the correct framing: the issue should be fixed for Arabic interface locales and not only by configuring wikis with an Arabic content language.

The upstream CLDR data is probably the source of the problem. Looking at the numbering system defaults, https://unicode.org/cldr/charts/45/by_type/core_data.numbering_systems.html#Numbering_System one can see that the ar locale will use Indic Arabic numerals by default, but ar_AE, ar_DZ, ar_EH, ar_LY, ar_MA and ar_TN will use Western Arabic numerals by default. There is a political question of where the center of the Arabic-reading world is located, I suppose?

The problem is severe enough that we might consider a language converter approach, or let users choose between different variants of Arabic locale in their preferences. Assuming of course that there are users of Arabic interface language who would prefer to keep Indic Arabic numbering?

In T338115#11097308, @Lucas_Werkmeister_WMDE wrote:

It’s been almost a year with no response… I’m inclined to say we should just merge the change. If some Arabic speakers want to use different numerals throughout MediaWiki, that’s a wider issue (already tracked at T368193); I don’t think it’s a valid reason to block this change, which after all is just a tiny fragment of the numerals seen on Wikimedia wikis (even the day part of date values still uses MediaWiki’s preferred numerals!), and which should also benefit other languages.

+1 the patch is good I tried with Arabic and reparsing work good in different precisions.

How we can retype rules in https://ar.wikisource.org/wiki/Mediawiki:Gadget-Site.css#L-5 to 24 to run with Parsoid?

It seems work now.

see also this parameter test

In T382666#10434220, @Tpt wrote:

@hubaishan Thank you! A workaround is to write {{#if:{{{فقط الفصل|}}}|onlysection={{{فقط الفصل}}}}} instead of onlysection={{{فقط الفصل|}}} to only set the onlysection parameter only if فقط الفصل is set

@Tpt see this revision on صفحات template in arwikisource I create it to simplify access to pages tag with only local language (Arabic) parameters , this is important for beginners. But it does not work for sections because of empty onlysection.

In T382666#10420917, @Soda wrote:

I'm struggling to comprehend which part of this is not intended behavior ?

Note that

<ref>text1

In T341321#10406759, @gerritbot wrote:

Change #1104689 had a related patch set uploaded (by Hubaishan; author: Hubaishan):

[mediawiki/extensions/Cite@master] [T341321] Add group to cite reference

https://gerrit.wikimedia.org/r/1104689

This is another message have the same issue, do think we need to open a separate report for every MediaWiki component? message box must have min (top bottom) margin which can be overdried by another classes you describe.

It is fixed now.

After clearing CentralNotice local storage, the notices are shown. I cleared local storage because I think I closed these notices before.

In T366959#9995482, @Pppery wrote:

That's not how train deployments work. If there's a specific patch you don't want to roll out to all wikis you could potentially revert and backport that one patch. But we won't keep one wiki on a legacy version because unspecified bots are slow (that was whoever wrote the patch's responsibility before putting it on the train).

Can you skip arwiki from this Update. Arabic month names changed and this may stop some bots from run there

@Jarekt Is interface language in global preferences set? was it set when trying with Firefox?

@Aklapper I have updated the task

I am working in adding Hijri (Islamic) calendar. I think it is better to split calendar specified functions of Gregorian and Julian calendars to separated classes and create a common interface for them. Then create a new calendar classes.

Please stop merging the patch until we discuss it in arwiki

This is a Firefox bug, the screenshot seems from another browser.

In T360988#9782318, @SToyofuku-WMF wrote:

I'm not able to reproduce this using firefox on any android devices (on browserstack), including the galaxy note that @hubaishan suggested. We might want to wait until Jon gets back, or the author responds with further instructions on how to reproduce

@Aklapper sample links:
https://ar.wikipedia.org/wiki/%D8%A7%D9%84%D8%B5%D9%81%D8%AD%D8%A9_%D8%A7%D9%84%D8%B1%D8%A6%D9%8A%D8%B3%D9%8A%D8%A9
https://ar.wikisource.org/wiki/%D8%A7%D9%84%D8%B5%D9%81%D8%AD%D8%A9_%D8%A7%D9%84%D8%B1%D8%A6%D9%8A%D8%B3%D9%8A%D8%A9
https://fr.wikisource.org/wiki/Wikisource:Accueil

This bug is caused by `.firstHeading::before` I can't locate it in code . It has rule:

	right: -9999px;

I think no need for `.firstHeading::before` the page run perfectly without it.