allow domain and target_language for dates_for_display

[agitator]

https://github.com/plone/plone.app.event/blob/master/plone/app/event/base.py#L733

[thet]

@agitator and i were investigating a bit. this is the outcome.

in a plone.app.multilingual environment, context and/or requests have sometimes the language not set to what the user expects (e.g. when called by a cron job). the usecase actually just requires a translated start date and start time, this is why i recommend not to use dates_for_display, but another translate function directly.

plone.app.locales defines date/time related format strings in the plonelocales domain like so:
msgid "date_format_long" msgstr "${d}.${m}.${Y} ${H}:${M}"

which is aweome, except that datetime.strftime cannot use a format string like u"${d}.${m}.${Y} ${H}:${M}" directly. therefore we need Products.CMFPlone.i18nl10.ulocalized_time, which contains a lot of logic to manipulate these message strings. i don't know yet, why this has to be so complicated and why we're not just using strftime compatible formatstrings in plonelocales message catalog. but however.

ulocalized_time uses zope.i18n.translate in three different places. ulocalized_time accepts msgid, domain but not target_language. zope.i18n.translate does accept a target_language.

i recommend to fix ulocalized_time in CMFPlone to accept and use a target_language.

but the solution for our usecase is to copy ulocalized_time and fix it in our cusomized version, just to get the project done.

[thet]

Much simpler, but also hackish (as it abuses the message strings a bit) solution for this problem:

>>> from datetime import datetime
>>> from zope.i18n import translate
>>> fstr = translate('date_format_long', domain='plonelocales', target_language='de')
>>> fstr
'${d}.${m}.${Y} ${H}:${M}'

>>> ffstr = fstr.replace('$', '%').replace('{', '').replace('}', '')
>>> ffstr
u'%d.%m.%Y %H:%M'

>>> datetime.now().strftime(ffstr)
'21.01.2015 16:03'