Customize: Order of fields in date/time control does not honor locale

[munyagu]

The field order of the schedule setting field in customizer is not changed for each language.
The order is changed in 'Published on' in Edit Post etc.

[atachibana]

Reproduced.
It seems to I18N issue. Customizer schedule's date seems to be fixed as "Month Day, Year".

Step:
Preparation - Set locale to Japanese (日本語)

1. Administration Screen -> Settings -> General
2. Select '日本語' (Japanese) => Data Format should be "2017年11月1日" (Y年n月j日)

Open New Post and Click Schedule.
=> You will see correct ordered Year, Month, Day Field boxes.

Open Customizer -> Settings -> Schedule.
=> The Order is Month Day, Year

[atachibana]

Success case - Post Scheduled date

[atachibana]

Error case - Customizer Scheduled date

[SergeyBiryukov]

Edit Post screen uses touch_time()​, which allows translators to customize the date/time format as needed:

/* translators: 1: month, 2: day, 3: year, 4: hour, 5: minute */
printf( __( '%1$s %2$s, %3$s @ %4$s:%5$s' ), $month, $day, $year, $hour, $minute );

Ideally, the same string should be used in WP_Customize_Date_Time_Control for consistency, but it uses a completely different markup and a different approach to 12/24 hour format, so the fix appears to be less straightforward than I thought.

[westonruter]

At the very least we could just detect the ordering of placeholders 1, 2, and 3 and make sure that the corresponding fields for month, year, and day are printed in the same order. This would also need to account for punctuation usage before/after the placeholders.

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/299

[westonruter]

See 42394.0.diff​ for one possible solution. It's not perfect in particular because it isn't able to know whether the content between the date and the time is associated with the date or the time.

I think what we need is new translation strings for the date and time separately.

So in addition to:

<?php
/* translators: 1: month, 2: day, 3: year, 4: hour, 5: minute */
$datetime_format = __( '%1$s %2$s, %3$s @ %4$s:%5$s' );

We also need:

<?php
/* translators: 1: month, 2: day, 3: year, 4: hour, 5: minute */
$date_format = __( '%1$s %2$s, %3$s' );

/* translators: 1: hour, 2: minute, 3: meridian (optional) */
$time_format = __( '%1$s:%2$s %3$s' );

The meridian part gets tricky, however. Right now the meridian part is conditionally included based on whether or not it appears in the time_format option, and not whether or not it is in the translation string.

Maybe for 4.9 we should fix the issue specifically with the year/month/day fields, but then continue with the current hard-coded approach for the hour/minute/meridian fields, since the time format is much less likely to vary between locales (AFAIK).

[westonruter]

Or, instead of using the '%1$s %2$s, %3$s @ %4$s:%5$s' translation string we could instead use the date_format and time_format strings to decide the ordering of the fields.

[Mirucon]

Use of the date_format and time_format instead of translation string sounds good to me. At least in Japanese, the order of date is always the same (Y/m/d), but there are some of the formats. E.g. some prefer 2016年11月1日, but some prefer 2016/11/1 or 2016-11-1.

Should be their own choice rather than the locale.

[westonruter]

Δ ​https://github.com/xwp/wordpress-develop/pull/299/commits/2c0e14f

[westonruter]

@Mirucon @SergeyBiryukov Thoughts on 42394.1.diff​?

[Mirucon]

@westonruter Order of the date is correct, but since that is just considered to have Y, y, o, F, m, M, n, j, d, if the format contains anything else of these string, the extra items will show up after the forms. The screenshot shows what happens with the default Japanese date format - Y年n月j日

[Mirucon]

42394.1.diff - with format Y年n月j日

[Mirucon]

42394.1.diff - with format Y年n月j日

[Mirucon]

Format for the first screenshot is actually d/m/Y :)

[westonruter]

@Mirucon please clear your cache and try again. jp-date-format.png​ is what I see if I supply a date format of Y年n月j日 and it looks good to me.

[atachibana]

@westonruter @Mirucon

I confirmed the patch works successfully.

For the first time, I got the same error with @Mirucon, but minify CSS (customize-controls.min.css) had not been updated yet. After minify of it and clearing cache, it shows the date with correct format.

[atachibana]

After 42394.1.diff, Customizer scheduled date in Japanese locale

[atachibana]

fyi.

Already Japanese Translation Team is discussing about the fix of duplicate '月'(=month) by modifying Japanese resources. After this fix was merged into the Core, they will work.

[westonruter]

@Mirucon in the future you can avoid having to re-minify sources by adding define( 'SCRIPT_DEBUG', true ); to your wp-config.php

[Mirucon]

Sorry, since that was a new environment, I forgot to add it! Thanks @atachibana, @westonruter

No, it was set - so the cache wasn't cleared properly.

[obenland]

In 42394.1.diff​, it doesn't look like $format is used anywhere.

[westonruter]

Remove unused var

[westonruter]

@obenland good catch. Removed in 42394.2.diff​.

[Mirucon]

Scheduling a post

[Mirucon]

This should be applied to posts as well. Shall I create a new ticket or is it handled here?

[westonruter]

Replying to Mirucon:

This should be applied to posts as well. Shall I create a new ticket or is it handled here?

I don't think that is necessary. Please review how the date is displayed in Gutenberg. It's an actual calendar picker component. That is what core will be moving toward, and the Customizer will likely re-use it instead of what it is including in 4.9, eventually.

[obenland]

42394.2.diff​ LGTM. Separators can look a little off at times, but I'm not sure this is something we have much control over

[westonruter]

In 42111:

Customize: Present the date/time control input fields in the same format (and order) as date_format.

Props westonruter, obenland, atachibana for testing, Mirucon for testing.
See #42373, #28721.
Fixes #42394.

[dlh]

If date_format is set to a custom string without at least one of the month, day, or year tokens, then the Publish Settings are knocked out of whack, as illustrated in the above screenshot with a date_format of Y-m.

42394.3.diff​ includes one possible workaround of falling back to the previously default date format if any of the three placeholders are missing.

[westonruter]

@dlh Good catch, though I wonder how many sites would not include all three parts to the date.

I think, however, that the fallback date format should actually be ISO date format: Y-m-d.

See 42394.4.diff​ which also ensures that each format character occurs once and only once.

I also realized the foreach loops could be eliminated.

[Mirucon]

What if it is fallback to locate default?

[westonruter]

@Mirucon I think the point of using ISO as fallback is that it would be an international format and so it wouldn't need to be translated. Otherwise, if it is translatable then it should maybe it should be what I have in comment #7:

<?php
/* translators: 1: month, 2: day, 3: year, 4: hour, 5: minute */
$date_format = __( '%1$s %2$s, %3$s' );

[dlh]

42394.4.diff​ works well for me.

I agree that a date_format without one part of the date would be unusual. The example I was thinking of at the time was a monthly magazine where the day on which a post was published would be unimportant to the site.

That said, if a translated string like __( '%1$s %2$s, %3$s' ) is an option, then is matching the fields to date_format necessary?

[westonruter]

@dlh you're right. If __( '%1$s %2$s, %3$s' ) is available then parsing date_format would not be necessary. I was trying to get by without introducing a new translation string, but if translators are happy with having a locale date format string to translate, we can just use it instead. @Mirucon @atachibana thoughts?

[atachibana]

@westonruter

I believe translators will be happy to do it.
In fact, as @SergeyBiryukov said in comment:5, Edit Post screen has such template string for some time.

[obenland]

We're in RC and with that in string freeze—let's try to avoid introducing new translation strings.
Given how unusual we all think this use case is, I think we should go with 42394.4.diff​ for now.

[westonruter]

In 42117:

Customize: Fall back to ISO date format for date/time control inputs if year, month, or day are missing from the date_format option.

Amends [42111].
Props dlh, westonruter.
Fixes #42394.