right-to-left language like Arabic makes the track menu a mess

[avih]

Discussed in #17119

^{Originally posted by verygoodlee December 11, 2025}
circle is rendered on the right side in the select/select-sid menu.

It's interesting that there's no issue in the select/select-track menu,
the only difference between the two menus is the addition of the track type prefix (Sub: ).

This might need to be fixed by libass, so I post it in Discussion.

[avih]

Copying my comment at the discussion to this issue:

---

Without deep analysis, I'm guessing that the diff between all-tracks and sub-tracks is that the former begins with English text ("Audio"/Video"/"Sub"), which sets the primary direction as LTR.

But sub-tracks don't begin in English, so it sets the primary direction to that of the 1st directional glyph (roughly speaking), which is not the bullet, but it is the text which follows.

Assuming we want to keep all the output generally LTR, even for RTL items (which I think can be considered reasonable currently, because the interface is English, and we don't have i18n interface), then I think there are Unicode codepoints which can specify the primary text direction as LTR or RTL.

Alternatively, just change the format to always start with English text, for instance by adding Sub: prefix.

@Samillion I'd recomend against trying to do manual analysis of codepoints for some quick'n'dirty fix (the discussion had such attempt). Directionality is a very complex subject, and it's best to leave it to tools which already put in the effort to handle it correctly - like libass.

@astiob might be able to help more and/or correct me ;)

[verygoodlee]

For simply reproduce the issue, you can create a subtitle file named "sample.srt", fill in the following content into the file.

1
00:00:00,000 --> 00:01:00,000
Nothing

And then run the following command to add subtitle track to any video.

sub-add "/path/to/sample.srt" auto "العربية" ar

---

Since the ASS rendered context menu is now available, I have further tested the subtitle track of the context-menu, the result was no different from the selection menu.

Fortunately, at least the Windows native context menu is fine.

[astiob]

I can confirm this analysis sounds about right to me. When base direction is autodetected and you want to force it to be left-to-right, you can add U+200E LEFT-TO-RIGHT MARK ("\xe2\x80\x8e" in UTF-8) to the beginning of the line, which is an invisible control character that affects directionality.

However: libass doesn’t autodetect base direction by default. This has to be explicitly selected by mpv when it’s creating the ASS track. If this autodetection is undesired and you want to always use LTR, you can just remove this explicit selection and revert to the default ASS behaviour. To do this, make sure that the Encoding in the ASS_Style is 1 (not -1). If the style is shared with other UI elements that do need autodetected direction, you can also add {\fe1} to the text instead (although at that point it’s hardly more convenient than adding U+200E).

[avih]

When base direction is autodetected and you want to force it to be left-to-right, you can add U+200E LEFT-TO-RIGHT MARK ("\xe2\x80\x8e" in UTF-8) to the beginning of the line, which is an invisible control character that affects directionality.

Presumably this affects only the primary direction, while inner RTL "chunks" still display correctly as RTL within their designated output area, yes?

[afishhh]

Presumably this affects only the primary direction, while inner RTL "chunks" still display correctly as RTL within their designated output area, yes?

If the text contains U+202E RIGHT-TO-LEFT OVERRIDE then it can break the display again. (put ‎اَلْعَرَ‮بِيَّةُ (sub) inside an HTML sandbox or something)

(edit: but if we assume no control codes in the user-supplied text then I think it behaves as you said.)

[astiob]

Presumably this affects only the primary direction, while inner RTL "chunks" still display correctly as RTL within their designated output area, yes?

Yes.

Although as rightfully pointed out, the track name may contain unpaired bidi control characters that will break display of the “(ar subrip) [default]” etc. suffix. You could try to counter that by wrapping the track name in a bidi isolate pair (U+2068 FIRST STRONG ISOLATE before the track name, U+2069 POP DIRECTIONAL ISOLATE after), but it can just as easily contain its own U+2069.

I’m afraid there’s no trivial way to protect against malicious/buggy track names like this… in pure Unicode. But ironically, there is one in libass: as long as ASS_FEATURE_WHOLE_TEXT_LAYOUT is not enabled (or is explicitly disabled) via ass_set_track_feature (and Encoding is not -1), you can force bidi isolation and left-to-right layout of isolates by inserting ASS override tags where you want the bidi breaks to happen. The tags must technically change some style property, but it can be a property that doesn’t visibly affect output. So you could do this:

// assuming the ASS_Style's SecondaryColour & 255 (which is the initial value of \2a) is not 1
// {\\2a0} can be shortened to {\\2a} or {\\r}
sprintf(event->Text, "• {\\2a1}%s{\\2a0} (%s %s)%s",
        track_name_with_quoted_braces,
        language_code, track_format, track_flag_suffix);

[avih]

If the text contains U+202E RIGHT-TO-LEFT OVERRIDE then it can break the display again

the track name may contain unpaired bidi control characters that will break display

Isn't this a problem with any directional control which are applied only as prefix/suffix of the string? For instance if the arbitrary string was wrapped between U+2068/U+2069?

EDIT. Oops:

but it can just as easily contain its own U+2069.

[afishhh]

Isn't this a problem with any directional control which are applied only as prefix/suffix of the string? For instance if the arbitrary string was wrapped between U+2068/U+2069?

Yes, see this HTML issue for more discussion about bidi and user input. You can process the string to remove such characters with some degree of success.

[...] there is one in libass: as long as ASS_FEATURE_WHOLE_TEXT_LAYOUT is not enabled [...]

The approach with dummy ASS style changes feels kind of hacky but I assume it's equivalent to shaping (and reordering) the inner string separately which is a better solution imo. It'd be nice if libass provided some sort of override to do that without disabling whole text layout though.

So the question is whether we want to hack this (disabling whole text layout / not setting encoding to -1 I guess) into being usable in Lua scripts or not?

[astiob]

Oh, but despite what we said, bidi behaviour can still be improved further by adding a Unicode isolate: you want left-to-right base direction on the complete UI line, but the externally-sourced track name itself (or in other UI contexts, file name, etc.) may benefit from direction autodetection if it starts or ends with weakly directed characters such as punctuation.

If you just paste $name into an LTR • $name ($lang) directly, then (regardless of whether you apply the ASS override tag trick) it will be interpreted as part of an LTR string, so leading and trailing punctuation will stay LTR and surround any embedded RTL sequence. For example, if the track name is an Arabic word followed by an exclamation mark, the exclamation mark will be displayed to the right of the Arabic.

But you can apply the override tag trick and insert U+2068 FIRST STRONG ISOLATE at the start of the track name (within the block delimited by the override tags—no need for a trailing U+2069 at this point). Then, direction will be autodetected within the track name while the rest will be LTR: then, the exclamation mark will be on the left end of the Arabic. (And if the track name starts with U+2069, well, that’s its own loss.)

I assume it's equivalent to shaping (and reordering) the inner string separately which is a better solution imo

Yes—and also good point. Not only for bidi, but for shaping, too, the forced break achieved this way may be actually desirable.

It'd be nice if libass provided some sort of override to do that without disabling whole text layout though.

If you mean a way to force an inline break, I see your concern but I’m afraid that’s unlikely to happen (even just due to a lack of a good way to fit it into the syntax if nothing else). But if you mean a larger-scope control toggle, that’s indeed exactly what the “whole text layout” toggle is.

[afishhh]

then (regardless of whether you apply the ASS override tag trick) it will be interpreted as part of an LTR string [...] But you can apply the override tag trick and insert U+2068 FIRST STRONG ISOLATE

Do you mean that the override trick is setting paragraph direction to LTR (for the "inner" text)?

If so this puts us back into the position of "use FSI and hope for no PDI" so if a PDI is going to break stuff anyway I think sticking to just wrapping into an isolate without any tricks is better. Only advantage for override tag trick is that PDI breaks it in a slightly different (though arguably more desirable) way.

[astiob]

Setting Encoding to anything other than -1 sets the paragraph direction to LTR.

Setting Encoding to anything other than -1, disabling whole-text layout, and inserting the override tags, all at the same time, causes every tag-delimited block to be handled separately as its own paragraph. So the paragraph direction of each block will be LTR.

Does this answer your question?

if a PDI is going to break stuff anyway

Personally, I disagree with equating these two cases. PDI with override tags (potentially) reduces the appropriateness of chosen directions within the externally-sourced string, but crucially, it doesn’t let this string affect the rest of the UI in any way, unlike PDI without override tags. If the string does contain unbalanced PDI, then it’s not well-formed and is arguably malicious, so I think it’s somewhat fair to render the string itself weirdly (as embedded-in-LTR); you could even say such a rendering is exactly following its wishes. But try as it may, it won’t mess up the UI if it’s wrapped in override tags.

[afishhh]

Does this answer your question?

Yes, thanks!

Personally, I disagree with equating these two cases. PDI with override tags (potentially) reduces the appropriateness of chosen directions within the externally-sourced string, but crucially, it doesn’t let this string affect the rest of the UI in any way, unlike PDI without override tags. If the string does contain unbalanced PDI, then it’s not well-formed and is arguably malicious, so I think it’s somewhat fair to render the string itself weirdly (as embedded-in-LTR); you could even say such a rendering is exactly following its wishes. But try as it may, it won’t mess up the UI if it’s wrapped in override tags.

This is what I meant by it breaking in an "arguably more desirable" way. Just not sure whether the extra work is worth it since I don't think there's currently a way to change Encoding for osd events (?).

[astiob]

Ah, if changing Encoding in ASS_Style is a problem, I believe you can add {\fe1} to the text to achieve the same effect. I recommend placing it at the very start, but it can technically be placed at at any point (but if inserted in the middle, it will serve as a paragraph break as long as mpv continues to set the style’s encoding to -1).

Of course, you can also choose to avoid ASS shenanigans and just add LTRM at the start and FSI/PDI around the track name. Purely in terms of the amount of code, both options are probably the same? But perhaps you find that the option with ASS shenanigans places higher requirements on people who may try to understand this code later.