pat-datetime-picker relies on browser language configuration instead of Plone configuration

[erral]

I don't know if I should open this here or in Patternslib...

The pat-datetime-picker pattern used in Plone 6 relies on browser interface language to render itself, producing different output in at least Firefox and Chrome.

This is Firefox configured to have the interface in basque:

This is Chrome configured to have the interface in english (I can't set basque as interface language)

As you can see, not only the date picker shows in English, but the datetime format of the input box is also formatted in English.

It looks like the pat-datetime-picker degrades to HTML5 date picker which relies on the browser language.

I would say this is a bug. The date picker should be rendered not in the browser language but in the content language. I don't know if this can be set in the HTML5 standard date-picker (I don't see how here, so perhaps we should render the JS date-picker anyway?

cc: @libargutxi

[petschki]

The field formatter is set here https://github.com/plone/plone.app.z3cform/blob/master/plone/app/z3cform/widgets/datetime.py#L104 ... you should be able to adapt this with zope.i18n.interfaces.IDateTimeFormat adapter.

[erral]

but here the field formatter isn't in action right? The above screenshots show the same page in the same language, in two different browsers rendered differently.

I would render the datepicker JS anyway, without letting the browser render it by itself except there is a way we can tell the browser "render the datepicker using XX language" and pass the current content's language

[petschki]

Meanwhile I also think it would be best to switch back again to JS date-time picker, because you have better customization/internationalization options there. This means pat-datetime-picker has to give an option to "force" it to show.

The browser native implementation is different from Browser/OS/Language in many ways without a possibility to style or translate it.

/cc @thet

[erral]

Thanks @petschki I have been checking answers in Mozilla's Bugzilla and StackOverflow and all of them say there is no way to tell the browser how to render the calendar, according to the standards browsers should follow user preferences, which they take from the browser preferences.

[petschki]

Just looked a bit more into pat-date-picker and pat-datetime-picker ... this is the result:

• schema.Date field uses pat-date-picker. There you can force the behavior to "styled" which always shows a JS picker and then you can define the output format like in this schema field snippet:

    project_start = plone.schema.Date(
        title=_("Project start"),
        required=False,
    )
    plone.autoform.directives.widget(
        "project_start",
        plone.app.z3cform.widgets.datetime.DateFieldWidget,
        pattern_options={
            "behavior": "styled",
            "output-format": "DD.MM.YYYY",  # forced german format
        }
    )

• schema.Datetime uses pat-datetime-picker which cannot be configured for JS picker when the browser supports native datetime-local field types ... I'll prepare a PR in patternslib to also implement something like "behavior": "styled" there ...

[erral]

Thanks. This will be Ok for custom fields, but what about existing datetime pickers in events, effective/expiration dates, etc?

[petschki]

hm ... just activated pat-datetime-picker locally for schema.Datetime fields ... since it defaults to native picker there has been no efforts anymore to update or style it. Also the after feature from pat-date-picker doesn't exist there which is needed for Event end date usability. I'm not the one who can make decisions in patternslib but it seems that this pattern is abandoned ... either we put some effort into this or we search for alternatives ...

[thet]

It should be possible to fix this pattern within the scope of a sprint.

The date picker would be the same as the pat-date-picker. But how should the time picker look like?‌ Any suggestions?

Regarding the language: We should add a language option which falls back to the lang attribute somewhere in the DOM tree of the Pattern - e.g. <html lang="de">. This would give enough flexibility to override the language but fall back to what the CMS uses.

[erral]

Regarding the language setting, we have several patterns that rely on a language such as tinymce or select2 so this could be handled in a similar way

[thet]

@erral we were discussing this issue yesterday and came to the conclusion that we want to stay with the native date picker. Moving to a JS picker would destroy the user experience on mobile devices where the native date pickers are way better than anything else and are an expected part of the user experience.

Not having a Basque translation in Chrome is more of a browser problem. Also the rest of the browser UI is in another language than Basque, so there must be some way for the user to understand the browser UI translations.

However, there is another plan which might be a fit for you:

• pat-date-picker from Patternslib currently only allows for native behavior or styled behavior. The styled behavior draws a <time> element instead of the <input type="date"> which shows a formatted time and opens the date picker when clicked on the time element. In Plone we want to directly edit the date value and have an option to open a picker - which is possible with the native behavior. I created a PR for another behavior keyboard where a <input type="text"> is rendered instead of the datetime to avoid the native picker and the JS picker would be opened when clicking on the input. feat(pat-date-picker): Introduce new behavior mode "keyboard". Patternslib/Patterns#1172

• The library pikadate does not ship with any translations but there is a pat-date-picker option i18n to define a JSON file which provides translations. So when using this picker you would need to provide translations too. But these are very minimal, this is an example: https://github.com/Patternslib/Patterns/blob/master/src/pat/date-picker/i18n.json

• pat-datetime-picker would need to be updated. There were quite some changes in pat-date-picker since the pat-datetime-picker was last updated. For example, a after support, a clear button, validation handling, etc.

• After these changes, activating the pat-datetime-picker would just be the same than adding a pat-datetime-picker class to the datetime-local input fields.

@erral Would you be able to contribute here? I'm currently on other topics.

/cc @petschki @MrTango

[erral]

I would definitely look at this. Thanks for sharing.

Anyway I think that sticking with the native datepicker is a wrong choice, looking from a point of view of a multilingual content editor. I edit content in a site in 3 languages, and in all cases the datepicker will be shown in my browser language (which I think is wrong) instead of in the content language.

Adding Basque support for Chrome is another story, I think is more of content-editing stuff.

Anyway, I will look at your suggestion and go through it.

[thet]

@erral If you need any help, let me know!