Same complain recieved to our offical twitter account (arwiki).

@alaa we're trying to track this down, and are having some trouble. Apologies for my ignorance, but can you help confirm the problem with these screenshots? My understanding of Arabic is that the same letter may be written different depending on whether it is at the start of the word, in the middle, or at the end. Is this the issue that we're having? Or is it something different?

Thanks!

Possibilities of source of issue, and some thoughts

• iOS changed font
  • Looks identical on Windows and macOS and IOS
  • Looks identical on multiple versions of iOS
• Our app changed something
  • Report came when we were still on 6.8.2 - nothing had changed in months
• Somewhere on Wikipedia servers changed font
  • Android isn’t seeing similar complaints (though there could be something Android-specific that means a PCS change isn’t being seen on Android)
  • No reports of issues elsewhere

I can replicate while only messing with text size on the article for Crosswords.
I can see a couple characters change when the text size increases and a word gets kicked to the next line.
Arabic letters have different forms depending on where it is in the word. And a letter moves from the middle-position form to the final-position form as the text size increases and the word moves to another line. Which obviously shouldn’t happen.
It doesn’t happen to this word on web.
Also happens on 15.4.1, but not 15.3 or 14.7
On 15.4.1, It does not happen on the output of PCS loaded in Safari on iOS (https://ar.wikipedia.org/api/rest_v1/page/mobile-html/%D9%83%D9%84%D9%85%D8%A7%D8%AA_%D9%85%D8%AA%D9%82%D8%A7%D8%B7%D8%B9%D8%A9). This seems very app specific.

These screen shots are from an iPhone SE (2nd edition) device, running iOS 15.4.1. I cannot replicate on simulator for iPhone 13 Pro running 15.4.

It's from the CSS font-family: Arial found in site.css, in the first part of the file:

html, body, #content h1, #content h2, #content #firstHeading, .mw-body .mw-editsection, .mw-body .mw-editsection-like, .ui-widget, .mw-body #toc h2, .mw-body .toc h2, .flow-topic-title, h2.flow-board-header-title, .mw-collapsible-toggle, .mw-collapsible-toggle > a, .CategoryTreeToggle, .CategoryTreeEmptyBullet, .NavToggle {
    font-family:Arial
}

Remove this, problem goes away.

This comes directly from https://ar.wikipedia.org/api/rest_v1/data/css/mobile/site, which is in a CSS called by the article's HTML.

Site.css's font-family for body is being used over base.css's font-family for body. I'm not quite sure why, though I will note that when debugging it *looks* like it's not actually using the font-family from site - though it clearly is, as when you uncheck that attribute, it looks as we'd expect.

This is getting deeper into web stuff than I know, so I think I'm going to hand this off to someone more versed in web.

Some thoughts:

• This still seems like an iOS problem, as the behavior is different on different versions of iOS. Still, we should fix it on Wikipedia, so it works for everyone.
• I can most easily replicate this with the Bold Text accessibility text on, and changing the text in an article. It's possible it's broken in other situations as well, but this is the easiest path to replication. (Thanks @Tsevener for discovering that!)
• I can't quite find where site.css comes from. Restbase documentation says it comes from https://ar.wikipedia.org/wiki/%D9%85%D9%8A%D8%AF%D9%8A%D8%A7%D9%88%D9%8A%D9%83%D9%8A:Mobile.css, but that obviously doesn't match the output above. I'm curious if something changed in that (for Ar Wiki) recently, though my hunch that this isn't it - because it seems like the behavior is different on different versions of iOS.

It's possible there could be a quick fix using .pcs-platform-ios somewhere. But overall, we need to make sure the Ariel font-family isn't what is being used in the body. There may be an on-wiki fix, but I'm not quite sure how this Arabic wiki specific css feeds into PCS.

Sample page: https://ar.wikipedia.org/api/rest_v1/page/mobile-html/%D9%83%D9%84%D9%85%D8%A7%D8%AA_%D9%85%D8%AA%D9%82%D8%A7%D8%B7%D8%B9%D8%A9

From a quick look on parsoid and mw:
https://ar.wikipedia.org/api/rest_v1/page/html/%D9%83%D9%84%D9%85%D8%A7%D8%AA_%D9%85%D8%AA%D9%82%D8%A7%D8%B7%D8%B9%D8%A9

Ariel is also used on both outputs on my device (Firefox/Chrome on Linux)

More complaints for Znuny

• https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12194037
• https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12194035
• https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12193412
• https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12193322

I have a problem When trying to read an article in the Wikipedia application, which is that the characters appear disconnected, and for clarification, a picture of the problem has been attached

@MattCleinman CSS rules came from load.php for parsoid output and from https://ar.wikipedia.org/api/rest_v1/data/css/mobile/site for mobileapps ( even for local instance ). Check the shot:

Maybe it is possible to override that font directly in wikipedia-ios?

FYI - styleoverrides.css is where we do a little bit of extra style manipulation in the iOS codebase. Might take some plumbing to only override something for an Arabic article though.

I think I'd rather fix this on wiki or PCS than with a hack the iOS codebase. (In part because the fix will get out their even quicker.)

Apologies, but I don't quite understand why something like body.pcs-platform-ios wouldn't help here - can you help me understand why that isn't an option?

I will try to test both variants. I already have some results with overridden styleoverrides.css but will test with PSC as well.

After additional research and testing, I've found that attempting to add body.pcs-platform-ios didn't make any changes. But instead, font overriding applied for wikipedia-ios.
Here is a screenshot that compares wikipedia-ios updated font | current font (which is actual now) | mobileapps updated font via body.pcs-platform-ios class:

And yet another example with overridden and actual fonts:

I tested this a bit with en wiki as well, it works correct but more testing is needed after pull request is approved.
Here is the PR: https://github.com/wikimedia/wikipedia-ios/pull/4240/commits/0888f1335b4f26b5a88de621364471c9d0f30419

cc: @MSantos , @Jgiannelos , @Tsevener

Thanks for this. It fixes the problem and tests great, thank you.

For posterity, a couple risks:

• If any languages currently use a specific font, the PR will break that.
• If any languages move to a specific font in the future, the PR will prevent that.

That said, we don't know of any bad outcomes right now - so we're going to merge this in. Thanks for fixing it.

5 new reports of problems with Arabic text from users on Znuny

This is fixed in the current beta - if we get additional reports of this, we can explain that we expect to have it fixed in the main app store version soon, and we should share the instructions for joining the beta.

Someone replied to a ticket after updating to 6.9.2, it seems like it is working!! 😍

https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12219358#14848224

Two people responded that it was fixed!

In T307407#8008800, @Mazevedo wrote:

Someone replied to a ticket after updating to 6.9.2, it seems like it is working!! 😍

https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12219358#14848224