Open kueda opened 3 years ago
Closed in 2.12.11
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:
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.
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.
@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?
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.
Describe the bug The date string on the "Post to iNaturalist" form is not localized.
To Reproduce Steps to reproduce the behavior:
Expected behavior My expectation is that this human-readable date would be localized into the locale from the app settings.
Screenshots
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.