sparkle-project / Sparkle

A software update framework for macOS
https://sparkle-project.org
Other
7.28k stars 1.04k forks source link

Layout issues in RTL languages #2575

Closed ShlomoCode closed 1 month ago

ShlomoCode commented 1 month ago

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 commented 1 month ago

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

zorgiepoo commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

ShlomoCode commented 1 month ago

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 commented 1 month ago

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

zorgiepoo commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

ShlomoCode commented 1 month ago

https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/SupportingRight-To-LeftLanguages/SupportingRight-To-LeftLanguages.html#:~:text=Flipping%20a%20Table%20View%20in%20a%20Mac%20App

zorgiepoo commented 1 month ago

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 commented 1 month ago

I made it possible to localize these keys and values where it makes sense. Check https://github.com/sparkle-project/Sparkle/commit/94440a412990b67c0cb942467650af417feef8b0 as a starting point (on system-profile-localize-placeholder branch).

ShlomoCode commented 1 month ago

https://github.com/sparkle-project/Sparkle/pull/2578