App: Timestring is not being properly set on Refreshing the tab when the Language is English
If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Details
https://github.com/Expensify/App/issues/4218#issuecomment-892122092
Action Performed:
- Go to newDot
- Open any chat
- Refresh the page
timestringwill update fromSpanishtoEnglisheven when the Language is set toEnglish
Expected Result:
It should show the timestring in the language that is set.
Actual Result:
Workaround:
Visual Issue.
Platform:
Where is this issue occurring?
- Web
- iOS
- Android
- Desktop App
- Mobile Web
Version Number: Logs: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos: Any additional supporting documentation Expensify/Expensify Issue URL:
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 16 (12 by maintainers)
@aman-atg Thanks for the info, I’ll submit another PR I’ve missed that previously
preferredLocalewas along the...propsspread I’ve only passedlocaleto trigger re-render when it changes, I had no idea it was actually used in the child components…@parasharrajat is correct in saying this should be fixed by the original author. We always wait 7 days to pay our contributors so that we can find regressions like this one. The PR we’ve been linking to is actually another regression fix from this original one, which was only merged 5 days ago.
Thus I think @kidroca should make this change (it’s a tiny one-liner change but that’s our process).
Tagging Eng for another set of eyes.
@lschurr I see that Changes here https://github.com/Expensify/App/pull/4366 caused this issue.
As @aman-atg mentioned https://github.com/Expensify/App/issues/4404#issuecomment-892506251. That prop name was renamed in that PR to
locale.No. In that issue we were not showing
Spanishversion at all. And currently theEnglishversion is being updated with a delay in this Issue.There’re many instances when regressions are fixed as Separate issues when found out later after the PR is merged. But I don’t think that I’m eligible to answer that question. Someone will surely clarify later.
I’ve already provided context in the ticket itself.