-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Update more in-app Stats texts to always use western arabic numerals #17217
Conversation
cc @ParaskP7 who will cover for me as Release Manager for WPAndroid while I'll be AFK the next 3 days. We might want to try to include that fix in the beta you planned on doing tomorrow (the one we usually do for L10n smoke-testing) |
📲 You can test these changes on WordPress by downloading wordpress-installable-build-pr17217-32cf991.apk
|
📲 You can test these changes on Jetpack by downloading jetpack-installable-build-pr17217-32cf991.apk
|
…' into fix/20.8-western-arabic-numerals # Conflicts: # WordPress/src/main/res/layout/stats_block_value_item.xml
As mentioned internally (p5T066-3Ak-p2#comment-13594) imho there's really no reason to push this to |
WordPress/src/main/java/org/wordpress/android/util/extensions/StringExtensions.kt
Show resolved
Hide resolved
Moved this PR to the next milestone: |
WordPress/src/main/java/org/wordpress/android/util/extensions/StringExtensions.kt
Show resolved
Hide resolved
android:visibility="gone" /> | ||
android:visibility="gone" | ||
tools:text="-7 (-100%)" | ||
android:layoutDirection="ltr" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a request for a change. Just curious why we set the layout direction here 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for raising the question @antonis 🙇
I noticed this view was placing the number sign inverted when using a RTL language, see screenshot:
This isn't the case in other places because we always have a prefix / suffix or the number is part of a longer string.
Upon further investigation it appears this happens only when the text of the view contains a number and any other characters except letters.
This seems to be the behavior of text views in RTL languages, though not consistent after we've introduced the changes to use western arabic numerals.
A few other explorations without setting android:layoutDirection="ltr"
:
Prefix word | Suffix word |
---|---|
Conclusion: In order to maintain a consistent position of the number sign with the other places, this change was indeed needed 🙂.
At the time I was also using Wikipedia to check the topic and my understanding was that the negative sign is positioned to the right only for eastern arabic numerals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work @ovitrif 👍
I've tested the app on a Pixel 5 (Android 13) and everything worked ass expected. The code also LGTM 🎉
A couple of notes but nothing blocking for this PR to be merged:
- We could add a release note (though this would seem duplicate to this)
- Do we need to set the layout direction here?
Thank you for reviewing & testing @antonis 🙇
|
Fixes
20.8
beta-testing issues discovered on #17160 (which fixes partially #17002) [internal ref: p5T066-3Ak-p2#comment-13583]Included fixes (see previews):
To test:
1️⃣ Test Case 1 : Jetpack / Wordpress App Stats
Me
→App Settings
→Interface Language
and selectArabic
.My Site
→ tapStats
& explore the first tab (Insights
)Stats
tab (Days/Weeks/...)Previews
1. Text in "Total"-type cards
2. Views & Visitors chart dates
3. Value "change" text
Regression Notes
Potential unintended areas of impact
Texts using text view component that forces western arabic numerals.
Updated texts for non-arabic languages.
What I did to test those areas of impact (or what existing automated tests I relied on)
Manual testing — the changes are rather trivial, just exposing a former private method public and reusing it.
In one instance (for the "value change" text) we're forcing LTR text direction — this text is expected to include only numbers and symbols.
What automated tests I added (or what prevented me from doing so)
N/a — PR consists of small UI changes.
PR submission checklist:
RELEASE-NOTES.txt
if necessary.