Opened 8 years ago
Last modified 17 months ago
#39756 new enhancement
Extend the jQuery datepicker localization
Reported by: | jadpm | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 4.8 |
Component: | I18N | Keywords: | has-patch |
Focuses: | ui | Cc: |
Description
Since #29420 whenever the jQuery datepicker script is enqueued it gets automatically localized. However, there are three options still not properly managed, mentioned and described in ticket:29420#comment:22, that should also get included, as they are indeed mentioned in the Localization section of the official documentation:
https://api.jqueryui.com/datepicker/
Unless we do include them, our datepicker localization is incomplete and can not replace using external resources, hence plugins relying on localized datepickers can not truly trust and make complete usage of the bundled locales.
The official localization files for the whole jQuery UI suite can be fond here:
https://github.com/jquery/jquery-ui/tree/master/ui/i18n
and they all include such options.
Those missing localizable options are:
weekHeader
: the string on the week column header whenshowWeek
is set toTRUE
.showMonthAfterYear
: a boolean to switch the month and year in the datepicker header, seems to be used by East Asia languages.yearSuffix
: the optional string to append to the year in the month headers.
We have at least two approaches on how to include the missing localizable options:
- We can filter the array of localization data added as an inline script for
jquery-ui-datepicker
, so plugins and third parties can add such options by themselves (hence forcing them to include those localizations on their own, and enter a possible race to be the one that forces its values). - We can add them as first-class properties in the
WP_Locale
class, stating as comments for translators both the meaning of the value that they are translating, and the jQuery UI localization files they can use to set the right value on their language.
Although I understand that providing localization for external libraries might not be in our roadmap, this is what #29420 actually did. It managed to cover most of the localizable options since we already had their translations. This is slightly different as we need to add specific properties for specific options, but still I would go with the second approach, and I will be attaching soon a patch for its consideration.
First proposal