[wp-trac] [WordPress Trac] #39756: Extend the jQuery datepicker localization

[WordPress Trac]

#39756: Extend the jQuery datepicker localization
-------------------------+-----------------------------
 Reporter:  jadpm        |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  I18N         |    Version:  trunk
 Severity:  normal       |   Keywords:
  Focuses:  ui           |
-------------------------+-----------------------------
 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/39756>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform