Ticket #11171 (closed Bug: fixed)

Opened 4 years ago

Last modified 17 months ago

time format in Plone4.0 no longer reads portal_properties/site_properties/localLongTimeFormat

Reported by: bslash Owned by: vincentfretin
Priority: minor Milestone: 4.x
Component: Internationalization Version: 4.2
Keywords: Cc: trs22, esteele

Description

In Plone 4.0, setting a time-format via ZMI in portal_properties/site_properties/localLongTimeFormat no longer works.

That means, you can't select a 24-hour time format for English locales. But there are many cases (international organisations) where English is the lingua franca, but time format should be ISO or another standard. Note: even the usual Linux trick of setting the locale to en_DK does not work.

Change History

comment:2 Changed 4 years ago by vincentfretin

Yes, those properties are unused now and should be removed.

You can override translations by creating a plonelocales.po in your package too, please see  http://plone-regional-forums.221720.n2.nabble.com/plone4-how-to-override-translations-in-plone-app-locales-tt5456430.html

comment:4 Changed 3 years ago by trs22

  • Cc trs22 added

I can see the requirement for being able to set the date/time format on a per-language basis, but it seems like it would be fairly straightforward to keep the Plone 3 behavior as a default (so as not to confuse novice/intermediate users) but also provide for flexibility in customization.

I see a special case for format strings beginning with 'date_' or 'time_' in i18nl10n.py:

 http://dev.plone.org/plone/browser/Products.CMFPlone/trunk/Products/CMFPlone/i18nl10n.py#L127

If the msgstr for date_format_long, date_format_short and time_format is set to the corresponding msgid in plonelocales.po, then the ZMI variables can be used to control the date format by default. I don't see these msgid's used elsewhere in the core code.

Once a developer is in the position of customizing the date formats for multiple languages, they'll be changing those values anyway, so it won't be as big of an issue as it is for a novice/intermediate user.

I put together a step-by-step tutorial on both customizing the date format in the approved way, and reverting it to the Plone 3 behavior for non-internationalized sites:

 https://weblion.psu.edu/trac/weblion/wiki/Plone4DateFormat

Since this ticket was one of the top hits when I was researching the problem, and I had never touched internationalization before, I figured documenting the steps would be helpful to anyone having the same problem.

Also, as @kleist noted, 'localLongTimeFormat' is used in event_view.pt, so different values in the translation catalog versus the ZMI could produce unexpected results.

comment:5 Changed 3 years ago by djay

This is a loss of functionality. We have sites where we need to configure different plone sites within the same instance to use different date formats. The work around only works for a zope instance globally.

Wouldn't it be better to test for the existence of the ZMI properties and if they are blank or missing default to using the locale format? If agreed I can submit a patch for that.

comment:6 Changed 3 years ago by mintsauce

+1 for a user facing way to modify this behaviour, it's one of the top 10 requests from my clients - their eyes tend to roll when I explain what I have to do.

comment:7 Changed 22 months ago by kleist

  • Version set to 4.1

I've now removed "localTimeFormat", "localLongTimeFormat", and "localTimeOnlyFormat" from "/portal_properties/site_properties":

 https://github.com/plone/Products.CMFPlone/commit/e751c27470a9f74096047d1307ee5112e8b0a609

It turned out that "event_view.pt" did read it, but never used it:

 https://github.com/plone/Products.CMFPlone/commit/5ca101bc2a2a7cfd91c98dc09f293a65e8e1e3cc

In the unlikely case that message catalog translation fails, hardcoded format strings are now used instead:

 https://github.com/plone/Products.CMFPlone/commit/db373c4d134a5fbb2b24c8335c82c8e2d3f3ae21

This change invalidates parts of  https://weblion.psu.edu/trac/weblion/wiki/Plone4DateFormat, but brings us a small step forward in our journey away from ZMI.

Last edited 22 months ago by kleist (previous) (diff)

comment:8 Changed 22 months ago by kleist

  • Status changed from new to closed
  • Version changed from 4.1 to 4.2
  • Resolution set to fixed

comment:9 Changed 22 months ago by davisagli

  • Status changed from closed to reopened
  • Resolution fixed deleted

Why have we removed the ability to customize the date/time formats?

comment:10 Changed 22 months ago by kleist

The properties weren't actually used - because message catalog translation (using plonelocales.po), should never fail. The date/time formats can still be customized by changing plonelocales.po.

Quoting vincentfretin in the second comment:

"Yes, those properties are unused now and should be removed. You can override translations by creating a plonelocales.po in your package."

comment:11 Changed 22 months ago by davisagli

But as Dylan pointed out, sometimes it's necessary to customize the format only for one site in a Zope instance, which doesn't work using the plonelocales.po approach.

My preference would be:

  1. Re-introduce the format settings as plone.app.registry records.
  2. Use the value of those settings as a format if they are set; otherwise fall back to the format from the locale.

Regardless of whether we do that, there are some test failures from your changes, kleist, in Products.CMFPlone, plone.stringinterp, plone.app.discussion, and plone.app.layout. Could you please fix those or revert the changes?

comment:12 Changed 22 months ago by kleist

  • Status changed from reopened to confirmed
  • Cc esteele added

I'm really very sorry for having messed up the tests, will fix them asap.

Will also re-introduce the format settings as plone.app.registry records. Might take some time though, I've never touched registry code before.

Last edited 22 months ago by kleist (previous) (diff)

comment:13 Changed 22 months ago by kleist

Using the 4.3 coredev buildout, I get no test failures from these:

bin/test -m plone.app.layout

bin/test -m plone.app.discussion

bin/test -m plone.stringinterp

This one...

bin/test -m Products.CMFPlone

... reports "5 failures, 2 errors", but nothing related to translation.

Do you still get these test failures?

comment:15 Changed 22 months ago by djay

That commit seems to set values for the formats. David's proposal was to not set a value so that the format set in locales is used by default. Is that still the plan?

btw, most of the existing translations don't have time and date formats set. Is there a way to use a standard set of language specific date formats if there is no specific translation?

comment:16 Changed 22 months ago by kleist

I plan a boolean record that enables/disables these formats (disabled by default). When disabled, they will not override the translation formats.

If no translation formats exist, and the new registry formats are disabled, I guess we should fallback to hardcoded ISO formats (along the lines of  https://github.com/plone/Products.CMFPlone/blob/db373c4d134a5fbb2b24c8335c82c8e2d3f3ae21/Products/CMFPlone/i18nl10n.py#L156 )?

comment:17 Changed 22 months ago by davisagli

That sounds reasonable to me.

comment:18 Changed 22 months ago by kleist

Have now committed the fix:  https://github.com/plone/Products.CMFPlone/commit/fcf0e285c46ede20505a508f1443552e4a2dcadc .

Will close this ticket when I've fixed the tests.

comment:19 Changed 22 months ago by kleist

  • Status changed from confirmed to closed
  • Resolution set to fixed

Now "my" test failures in Jenkins are gone.

comment:20 Changed 17 months ago by tonim

Can't see this code from github in Plone 4.2.1. Will it be i n 4.2.2?

comment:21 Changed 17 months ago by kleist

If nobody backports it, I believe not until 4.3.

Last edited 17 months ago by kleist (previous) (diff)
Note: See TracTickets for help on using tickets.