Make WordPress Core

Opened 8 years ago

Last modified 14 months ago

#39756 new enhancement

Extend the jQuery datepicker localization

Reported by: jadpm's profile 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 when showWeek is set to TRUE.
  • 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.

Attachments (1)

39756.diff (3.2 KB) - added by jadpm 8 years ago.
First proposal

Download all attachments as: .zip

Change History (3)

@jadpm
8 years ago

First proposal

#1 @jadpm
8 years ago

  • Keywords has-patch added

#2 @swissspidy
14 months ago

#55577 was marked as a duplicate.

Note: See TracTickets for help on using tickets.