-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Fix post time localization on Android #6742
Conversation
This looks like a great solution, nice work 👌 (although I say that as someone who can't code or build the app to test it out, of course 😅) One quick question: I can't read either Japanese or Chinese, are the correct date formats really exactly the same in the two languages? I must admit I never would have guessed that was the case 🤷🏻♂️ |
At least in date formatting, they are exactly the same. For the sake of caution, I would like to ask @tkusano to review this if possible. |
the screenshot attached as "After / Japanese (Android)" looks good to me. |
src/lib/strings/time.ts
Outdated
@@ -1,12 +1,36 @@ | |||
import {DateTimeFormat} from '@formatjs/intl-datetimeformat' |
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.
We'd like to avoid importing something that isn't used on the web. Let's instead fork this file like time.ts
vs time.web.ts
and keep this import in the native version. This also lets you remove the inline checks.
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.
In fact, maybe it's worth moving the code into time.android.ts
if we're sure the fix is only needed there
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.
let's tweak to fork the file instead
Reverted I believe the changes are only needed there for now, other time localizations seem fine. |
This comment was marked as resolved.
This comment was marked as resolved.
yarn.lock
Outdated
@@ -4258,6 +4258,31 @@ | |||
"@formatjs/intl-localematcher" "0.5.4" | |||
tslib "^2.4.0" | |||
|
|||
"@formatjs/[email protected]": |
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.
We have two copies of this in the lockfile now. I think we need to bump other related libraries in package.json
so that we have everything in a lockstep and transitive dependencies are shared as much as possible.
@@ -1,8 +1,10 @@ | |||
// Don't remove -force from these because detection is VERY slow on low-end Android. | |||
// https://github.com/formatjs/formatjs/issues/4463#issuecomment-2176070577 | |||
import '@formatjs/intl-locale/polyfill-force' | |||
import '@formatjs/intl-datetimeformat/polyfill-force' |
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.
Just flagging we need to measure the startup time impact of this on a real android device. We've had pretty bad regressions in the past due to related changes.
Another thing we might want to consider is forking this block between iOS and Android. If this is really android-only, it would be good to avoid activating this on iOS.
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.
Actually maybe you can move this import to time.android.ts
? Since that's the only place that needs that API. I realize this makes it a bit inconsistent but it does avoid potentially regressing something on iOS.
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.
I guess I'm not sure whether that would break the dynamic imports below. Do they rely on ordering?
I will test it on Android and iOS later and update the About performance issues, will simulate a low-performance Android device to verify its impact. Not entirely sure whether to introduce this on iOS as well since the behavior on iOS currently seems consistent with the Web. Needs conduct more detailed tests over the next few days to carefully ensure nothing breaks. |
I wonder what the source of discrepancy is. So far Android/iOS have been consistent with other i18n stuff. |
It seems that lingui has an issue when handling long-format dates, as this part is directly formatted through lingui. Maybe I’ll create a minimal reproducible example to report this to upstream, as the issue consistently appears with both the previously used v4.5.0 and the latest v4.14.1 in RN 0.76. And it only affects certain asian languages on Android. It’s quite challenging to find other RN projects that use lingui for time formatting. lingui appears to focus more on handling time formatting for the web, so that I switched to a time formatting method more commonly used in RN projects. |
Just a personal thought, maybe we could try having iOS format the time using DateTimeFormat as well. We could still maintain the i18n-related imports in one place, which might help avoid additional maintenance effort. After cleaning the lockfile, I retested on both iOS and Android, and the time formatting works correctly on iOS as well. I haven’t done rigorous flame graph testing on performance yet, but there doesn’t seem to be a significant impact on the app’s startup time on a simulated low-end Android device. |
I submitted an issue with a minimal reproducible example to Lingui, and this is the response I received:
Based on this I adjusted this PR. We still need to include |
FYI, you also might be interested in that PR (not merged yet) in the lingui lingui/js-lingui#2117 |
Thank you for pointing that out! 5.x also has some features that I'm particularly interested in, such as print placeholder values. I’ll check it again once it’s merged. For now, I'd like to introduce polyfill to address the current issues, since it looks like migrating from 4.x to 5.x requires some changes beyond the scope of this PR. I admit I’ve been a bit eager to push this PR forward since it has been bothering me for some time. Thanks again for clarifying my doubts so thoroughly! |
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.
lets try this
Glad to look into this, but I’d like to learn more details. It seems to be working on Android when I tested. Does it happen when opening DM conversation after switching the language? |
Hmm it does happen for me. Note you have to scroll up a bit so that it shows dates. |
It hasn’t happened to me at this moment, but I have faced it before. Will look into it and see how to fix it when appropriate. |
Co-authored-by: surfdude29 <[email protected]>
* main: (58 commits) Fix tests Layout tweaks (bluesky-social#7150) Trending (Beta) (bluesky-social#7144) Fix emoji picker position (bluesky-social#7146) Tweak Follow dialog Search placeholder (bluesky-social#7147) New progress guide - 10 follows (bluesky-social#7128) Pipe statsig events to logger (bluesky-social#7141) Fix notifications borders (bluesky-social#7140) Refetch empty feed on focus (bluesky-social#7139) Read storage on window.onstorage (bluesky-social#7137) [ELI5] Tweak wording on the signup screen (bluesky-social#7136) alf error screen (bluesky-social#7135) add safe area view to profile error screen (bluesky-social#7134) Adjust gates (bluesky-social#7132) disable automaticallAdjustsScrollIndicatorInsets (bluesky-social#7131) Bump more native deps (bluesky-social#7129) Update more Expo packages (bluesky-social#7127) feat: widen recent search profile link for mobile devices (bluesky-social#7119) Fix video uploads on native (bluesky-social#7126) Fix post time localization on Android (bluesky-social#6742) ... # Conflicts: # src/view/com/profile/ProfileSubpageHeader.tsx # src/view/screens/ProfileList.tsx
* Empty * First pass * More colloquial Romanian * Add Romanian lanaguage * Romanian specfic plural with 3 variants * Adjustments * Chat > Conversație * Keep code alphabetical order * Update messages.po * Add 'ro' to app.config.js * Regenerate and finish RO * Update messages.po * Fixing a previous wrong conflict resolution * Adapt after #6742 Co-authored-by: surfdude29 <[email protected]> --------- Co-authored-by: Alex <[email protected]> Co-authored-by: surfdude29 <[email protected]>
Fix #6728
It seems that the post date localization on Android is handled differently from Web and iOS. In some cases, this may cause the date localization to not work properly on Android. Here are some examples:
Before
Japanese (Web)
Chinese (Web)
Android
For Chinese, this date format is like rolling back to English, so it needs to be changed. At the very least, it should match the date format used on the web. The example after the fix:
After
Android