[PM-20026] RTL text direction

[codokie]

🎟️ Tracking

#4753

📔 Objective

Fixing text direction of LTR text in RTL layout, and vice versa.

📸 Screenshots

(see "Steps To Reproduce" in the tracked issue)

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[S-Kakar]

Thank you for your contribution! We've added this to our internal Community PR board for review.
ID: PM-20026

[codokie]

Note that there is still a problem with bi-directional text in the password history view.

Historic custom hidden passwords are not formatted properly. See the following screenshot:

(Password is 1234 5678 in both cases, only field label has been changed. Current behavior is the one to the left.)

Upon some digging I've found this to be the root cause.

Possible solution:

PasswordHistoryView.password should not include the label of the hidden field. Instead, in PasswordHistoryListItem, add a separate Text composable for the label.

I could not figure out how to add a label property to PasswordHistoryView data class, so I may not be able to implement the fix for this. It also seems that old fields are stored in the cipher, so there would be a need to migrate them.

Alternatively, BidiFormatter may prove to be useful. See this Android doc for usage and more info about bi-directional text formatting.

[codokie]

@david-livefront @brian-livefront

Could you please review the proposed changes?

Thank you

[SaintPatrck]

🤔 I'm wondering if having a BidiTextManager and ProvidableCopositionLocal<BidiTextManager> would be a better way to handle formatting. Something along the lines of

interface BidiTextManager {
    fun unicodeWrap(text: String): String
}

val LocalBidiTextManager: ProvidableCompositionLocal<BidiTextManager> = compositionLocalOf {
    error("CompositionLocal BidiTextManager not present")
}

Then we can apply the formatting in our common Composables.

An example from BitwardenTextField would look like...

fun BitwardenTextField(...) {
    var textFieldValueState by remember { mutableStateOf(TextFieldValue(text = formattedText)) }
    val textFieldValue = textFieldVauleState.copy(
        text = LocalBidiTextManager.current.unicodeWrap(value),
    )
    // Remaining logic omitted...
}

With that approach I was able to achieve the following results

[SaintPatrck]

We should avoid manually setting the text alignment in screens like this.

We also do not want to use Left and Right alignments. We should be using Start and End so they respect the selected language's layout direction.

[SaintPatrck]

All files must end with a newline.

The Setup section of README has instructions on how to create a macro to enforce this and other Code style guidelines.

[SaintPatrck]

We should not be removing alignment assignments in the screens. Start and End will respect the layout direction of the selected language.

[SaintPatrck]

Should this be using TextDirection.Content?

[SaintPatrck]

Should this be using TextDirection.Content?

[SaintPatrck]

Can you update your fork & branches? There are several conflicts since we've moved common logic and UI components to their own module.