inaturalist / SeekReactNative

Seek v2, built with React Native for Android and iOS
https://www.inaturalist.org/pages/seek_app
MIT License
156 stars 26 forks source link

Date string in the observation form not localized #367

Open kueda opened 3 years ago

kueda commented 3 years ago

Describe the bug The date string on the "Post to iNaturalist" form is not localized.

To Reproduce Steps to reproduce the behavior:

  1. Sign in to iNat in the app
  2. Set the app language to German (Deutsch)
  3. Take a new photo and tap "post to iNaturalist"
  4. The form is mostly translated into German but the date string looks like "Tue Jul 13 2021 15:43", so the "Tue" is not in German (I'm guessing the German convention would be to have the day of the month before the month name as well).

Expected behavior My expectation is that this human-readable date would be localized into the locale from the app settings.

Screenshots

Screenshot_20210714-134037

Smartphone (please complete the following information):

Additional context

Raised at https://crowdin.com/translate/seek/32/en-de#8422

Note that the date as displayed should be localized, but it would be best if the observed_on_string value submitted when creating the observation be in ISO 8601 format.

albullington commented 3 years ago

Closed in 2.12.11

kueda commented 3 years ago

Looks like you're relying on the date-fns format function to do the localization here, which is probably fine most of the time when date-fns has translations for a locale that Seek supports, but not all the time, e.g. Sinhala:

Screenshot_20210809-150903

Do you want to stick with this strategy? If so, we should notify people that the way to support their language of choice is to follow the directions at https://date-fns.org/v2.23.0/docs/I18n#adding-new-language

The alternative would be allow translators to specify the format string, which provides a lot of flexibility, but also leads to errors because the formatting syntax is usually hard for people to understand. I usually opt for the former, but I also usually do that b/c the website and the iNat mobile apps tend to support more languages than most 3rd party packages. And, of course, we routinely end up with situations where a date will like like "3 Abril AAAA" as a result.

albullington commented 3 years ago

Ah, I completely forgot about Sinhala being an unsupported language here. I know there's already an issue in date-fns for Sinhala language support that's a year old. It looks tricky for a non-developer to add a language to date-fns.

For now, I like the idea of sticking with date-fns since we're using ~7 different date formats across Seek and it seems to be working well for 23 out of 24 languages. But I also imagine I would feel differently if we had more than one unsupported language in Seek, so I'm certainly not tied to our current strategy.

kueda commented 2 years ago

@abhasinat, this seems like a product call: ensure localized dates for all languages by making more work for the translators, or use third-party localized dates that won't work for some languages?

abhasinat commented 2 years ago

I think using date-fns is fine, since it seems like that's easier on our end, and seems like Sinhala has already been requested. An alternative on our end could be that when a language isn't supported by date-fns, we could display the date in DD/MM/YYYY 24:00 format, which is pretty universal. But I think having unlocalized dates in a few languages is fine.