Server Version#:
Player Version#:
Screenshot_2018-12-22%20Mission%20Impossible%20-%20Fallout|690x459
Arabic subtitles are showed normally on VLC player but not on Plex player on my PC or TV
Is there any pieces of advice??
Regards everyone
Your screenshot didn’t take. Can you try to upload it again? Just drag the picture in the reply window.
1 Like
Okay… I see. And you say VLC displays them correctly…
I wonder if it has anything to do with the encoding the subs are in. Still though. Why would VLC play them fine.
Can you open the sub up in say, Notepad and goto saveAs. What is the encoding set to? ANSI? UTF-8?
Every thing was functioning just fine 2 weeks ago, then i have updated Plex and updated my windows and now I do not know which update has ruined everything up?
I don’t see how VLC displays the subs correctly being encoded in ANSI.
I see you have a YIFY release. I did some checking. There is only one listed as a WEBRip and it’s no good. ANSI encoding.
The only other one that looks promising is subtitle
Mission:.Impossible.-.Fallout.2018.720p.BluRay.x264.[YTS.AG]
It’s encoded UTF-8 and displays the text correctly within Notepad. Though I don’t know what it says cause I can’t read Arabic.
Here is a quick peek of the contents of the subtitle.
Download this sub here
Though you might have issues with syncing them cause WEBRip versus BluRay. So, you might need to find a different WEBRip sub or a different release entirely.
But what ever you do, you will have to get one that NOT encoded in ANSI.
1 Like
Precisely.
Please see these threads
@OttoKerner
That solution will not work to correct the subs. When you save in ANSI you loose certain information that can’t be “encoded” back into the file.
How people are saying it worked for them is a mystery.
That’s like the music note symbol ♪. If that symbol gets saved as ANSI it gets “converted” the “unknown”.
And adding here to @OttoKerner
SRT2UTF-8 can do this automatically for you!
If your local codepage happens to be arabic then you won’t lose anything - unless the subtitle file also contains latin or cyrillic characters. 
Ah-ha. Thanks for the clarification… So, is that a decode thing? Meaning it doesn’t matter the system that originally saved the subtitle file. It only needs that local codepage when you try to SaveAs from the downloaded original?
Sorry what?
lol… A bit confusing I know, sorry…
Lets say system “A” has a locale US-EN and saves the subs as ANSI. Then system “B” with local AR(Arabic) downloads them and then saveAS UTF-8. Will the newly saved UTF-8 subs show the Arabic text?
Of course not, because the system with the US locale has already thrown away the arabic characters by saving it as ANSI.
But that is purely hypothetical. When opensubtitles and all the other ususal suspects are offering their arabic subs, they use of course a version of ANSI that is used on an arabic system. (Sorry, I forgot which codepage arabic is).
If you have a certain subtitle file and you know “this sub is containing arabic characters”, then you can convert it to UTF-8 for use with Plex and all other modern systems - totally independently from which locale they use.
Which is what SubZero does automatically, or @dane22 's SRT2UTF-8 plugin.
(You could also use notepad++ if you tell it which codepage it shall assume as the source.)
Subtitle Edit can do the same - even in batch mode for a whole drive.
Not to keep bother you but this very helpful information.
So, from my example above. What if system “A” was also arabic at the time when the sub was savedAs ANSI?
I only ask cause I can take an arabic sub file and saveAs a new name(utf-8) and it will keep the correct text on a US-EN system.
Then all will be OK.However, if someone is trying to use this file on a system which doesn’t use an arabic locale, the faeces hit the fan.
Now imagine a poor streaming server which has to hand out subtitles to devices which sometimes don’t even have a way to set them to arabic locale…
That’s why it is strongly advised to convert all subtiles to the UTF-8 format. Because they will behave always the same, independently of the locally used language settings.
Ahh. Thank you so much.
Much I didn’t know but shouldof, lol. That makes it much clearer. I have a much better understanding now. Thanks.
Sorry, one more thing. Why would someone need to convert it to utf if their locale is already the correct codepage? Wouldn’t their version of ANSI show the correct text?
