Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Layout issues in RTL languages #2575

Closed
ShlomoCode opened this issue Jun 3, 2024 · 14 comments · Fixed by #2576 or #2579
Closed

Layout issues in RTL languages #2575

ShlomoCode opened this issue Jun 3, 2024 · 14 comments · Fixed by #2576 or #2579

Comments

@ShlomoCode
Copy link
Contributor

ShlomoCode commented Jun 3, 2024

Summary

Please note that some of the problems will only be presented after the completion of the Hebrew translation (in #2573)

Some languages, such as Hebrew and Arabic, are written from right to left (RTL). Mixed sentences are written from right to left, with terms embedded in their original form, for example:

אני משתמש ב-Github כל יום
Github הוא כלי חשוב

However, when there is a block of text that is entirely in English, it should be spread from left to right.
See also Apple's guide: https://developer.apple.com/design/human-interface-guidelines/right-to-left

I found a few things that don't match in Sparkle:

  1. This is an RTL sentence, but it starts with an English term (LTR) which causes it to render incorrectly (note that the question mark escapes to the beginning of the line).
    CleanShot 2024-06-03 at 15 55 54@2x
  2. Same as 1, in "You're up to date" window:
    CleanShot 2024-06-03 at 19 50 59@2x
  3. The system information is always in English, so the table needs to be LTR to be displayed correctly:
    CleanShot 2024-06-03 at 16 05 58@2x

Version

The Sparkle Test App

@ShlomoCode
Copy link
Contributor Author

A possible fix for 1 and 2 points is adding the RLM char in the Hebrew translation

@zorgiepoo
Copy link
Member

Does issue 1 and 2 occur if the app name is localized?

In Xcode you can select the InfoPlist file for the Sparkle Test App, and enable Hebrew localization in the File Inspector. Then add CFBundleDisplayName = "MyHebrewTranslationHere"; to the InfoPlist (Hebrew) file.

Maybe we should add a RLM char anyway, assuming it won't cause any issue when a developer localizes the app name?

@ShlomoCode
Copy link
Contributor Author

ShlomoCode commented Jun 4, 2024

Does issue 1 and 2 occur if the app name is localized?

No (but it is very rare that localization is done for the name of the app, because it is a "brand")
CleanShot 2024-06-04 at 04 26 16@2x
I will add RLM chars.

@zorgiepoo
Copy link
Member

I assume even if the app name was localized, adding RLM chars would not be an issue though.

@ShlomoCode
Copy link
Contributor Author

ShlomoCode commented Jun 4, 2024

Yes, the RLM character is an RTL distinct unicode character that causes the "neutral" field to identify the content as RTL content (since it determines text orientation by first character), but it is transparent and causes no display side effect.
I could just as easily add "א" or any other letter from some RTL language, but then it would be displayed, unlike the RLM char which is transparent.

However, keep in mind that I'm not a MacOS developer so there may be better ways.

@ShlomoCode
Copy link
Contributor Author

This is how it looks with RLM characters:
CleanShot 2024-06-04 at 04 57 16@2x

@zorgiepoo
Copy link
Member

Okay, looks good.

However, keep in mind that I'm not a MacOS developer so there may be better ways.

Yes, a RLM character is the way to do it:

If a variable appears at the beginning of a string, natural direction causes the entire string to use the directionality of the variable. This is incorrect behavior if the variable directionality is unknown—for example, the variable could be an Arabic or English user name. In this case, insert a right-to-left mark (RLM) character, U+200F, before the variable for right-to-left languages, or a left-to-right mark (LRM) character, U+200E, before the variable for strings for left-to-right languages. Use this technique for left-to-right localizations even if you don’t have localizations for right-to-left languages.

https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/SupportingRight-To-LeftLanguages/SupportingRight-To-LeftLanguages.html

@zorgiepoo
Copy link
Member

zorgiepoo commented Jun 5, 2024

As for how to force the table view to be left-to-right, I'm not currently sure how to do this. Setting the userInterfaceLayoutDirection on the table view to be left-to-right seems to have no effect.

This table view is showing data that will be transmitted anonymously to the update server. So it makes sense it is not localized.

@zorgiepoo
Copy link
Member

zorgiepoo commented Jun 5, 2024

Do you think the table columns should be reversed still? Or should they be in the same order as running the app in English. (I can re-order the columns programmatically but haven't found a property to switch the order automatically)

Should the scrollview still be on the left? (I don't currently know how to change this).

Should the text alignment for the columns change to be more left-aligned? I assume yes, for this question, at least. (There is a property on the table view to Never Mirror for this)

@ShlomoCode
Copy link
Contributor Author

The order of the columns should be as in English, and the contents of the cells should be aligned to the left, yes

Optimally the scroll bar should also move to the right side, just like in the English version

CleanShot 2024-06-05 at 12 18 40@2x

@zorgiepoo
Copy link
Member

zorgiepoo commented Jun 7, 2024

Actually I think we will localize this table where it makes sense, at least for the keys. Since they are "display" fields and aren't exactly what's sent. There will be some things that are English though.

@zorgiepoo
Copy link
Member

I made it possible to localize these keys and values where it makes sense. Check 94440a4 as a starting point (on system-profile-localize-placeholder branch).

@ShlomoCode
Copy link
Contributor Author

#2578

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants