Closed misha closed 2 years ago
@misha Yeah, sure, you can submit PR. After that I can merge both to master, also, I can do it and merge just the test case 😃
@misha Nvm, I'll add it since there is one more pull request and will publish with this, tnx for the test case.
The test case is merged in 2.4.2, however, commented out for now since it will fail. There are a few places to improve locale support so it will be included in 2.4.3.
For localization, the library is using JavaScript built-in Intl
support, however, adding locale to format, it would need date-fns
locale defined object, I will have to check how to work with both, because, ja-JP
is available in Intl
but in date-fns
it is used as ja
Yep, that's where I hit a block. The language codes in date-fns appear ad hoc, so we may just have to map between them.
Would you be open to having the user specify the date-fns locale separately? For my applications we only need one locale, and then we wrap vue3-date-time-picker in a custom component anyway so it's easy to supply the locale as a default.
We would just include that you need to pass the date-fns locale as well in the documentation. This also helps keep package size low, if the current build has been trimming out unused date-fns locales.
Yeah, probably it will be another prop, something like formatLocale
or similar
Also, I am not familiar with the Japanese language, so I don't know if it is correct, do you think on the calendar days and years there should be also some different format or it is ok?
I manage to come to a solution, the prop formatLocale
is now added and will accept date-fns/locale
import. However, these packages can become quite large if they are all imported so that the components could just handle the language code. I'll leave this to the developers to provide imported languages (also, date-fns
enforces imports that are used only).
The usage would be something like this
<template>
<Datepicker :formatLocale="ja" />
</template>
<script setup>
import { ja } from 'date-fns/locale'
</script>
I discovered that locale does not seem to affect the format output, and added a test for it.
The root cause is not passing the component's
locale
down to thedate-fns
format function. Would you accept a PR if I modifiedformatDate
to also accept a locale? Several components would also have to know about the locale as a result.This PR is just the test.