Handle date localization

[jonator]

We use dayjs for displaying human-readable dates to users. It has a configuration option for rendering localized dates.

See this for Taiwanese Mandarin on Osmosis frontend.

It would be great if Inlang can detect the date library and use a plugin based system to handle this as well. I'd bet that files (like that linked above) would be constant across projects.

See their docs on i18n:
https://day.js.org/docs/en/i18n/i18n

[samuelstroschein]

Will be part of the upcoming SDK for metaframeworks like SvelteKit, NextJS, etc. #395.

[ivanhofer]

@jonator what would you expect inlang to do here?
This is not completely clear to me.

[jonator]

If a repo is using day.js (or similar), generate date formatters per language (like how to localize “2 day”, or “a year” or “Wednesday”, etc.) Then, we can simply use day.js without having to think about localization.

…

On Jul 11, 2023, at 7:18 AM, Hofer Ivan ***@***.***> wrote: @jonator <https://github.com/jonator> what would you expect inlang to do here? This is not completely clear to me. — Reply to this email directly, view it on GitHub <#992 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDETJN2DOL2UU755AYX4VDXPUZBPANCNFSM6AAAAAAZRYYYYE>. You are receiving this because you were mentioned.

[ivanhofer]

As far as I understand, someone just needs to add the already provided translated object to the code to make it work.
The SDK will probably not provide a solution for every possible library out there.
What I could immagine is a hook that get's called when the language changes. Then any developer could write a function for dayjs or other libraries to load everything accordingly.
We probably need more use cases to actually see the need for an actual plugin system as it adds complexity. I think it should be easy enough for now to leave this up to developers using the SDK.

We will come back to this once we introduce "formatters" to the inlang ecosystem.

[jonator]

It could also be fitting for inlang to have a "registry" of these date formatters for:

• Each major language
• Each popular date library

Then it will be one less i18N issue to deal with. This would make inlang a fuller solution.

[shadow-identity]

Hi guys and thanks for the amazing library!
Do you consider using Intl.DateTimeFormat and Intl.RelativeTimeFormat under the hood? In our experience these APIs are quite mature, pretty customizable and widely supported and the most important thing -- are part of the web platform. That means that we are not dependent on any 3rd party libraries, which can be broken, deprecated or abandoned, buggy, or just have irregular updates missing important changes from upstreams (reminding me these timezone updates). Having one major dependency less is always good.

[LorisSigrist]

That's the plan :) This feature will come pretty soon, but for now you can use the Intl APIs yourself & pass in the formatted values as parameters

[shadow-identity]

Great to know! Good luck with the release!