nexedi / erp5

MR lacks tests

@jerome we discussed about this.

@romain , I think that now in new UI an error message defined in the Field (manage_messagesForm tab) like 'This field is compulsory' is not translated. This MR should fix this.

now that I look again, I realize maybe we could implement this getMessage so that we don't have to pass the translate method. For example with Products.ERP5Type.Message.Message we don't need, the __str__ method does the translation.

I'm a bit lost in how this works in zope now, maybe just using it zope.i18n.translate(self.error_text) is enough ?

for reference: https://lab.nexedi.com/Nexedi/erp5/blob/9e695da1ee7e18594b4c0a68e5ddcfbd83b2e574/bt5/erp5_crm/SkinTemplateItem/portal_skins/erp5_crm/Base_validateAddSupportRequestDialogRightGroupField.py#L4 was a place where we should change to use translate

The placeless translation can be achieved with something like this:

  from zope.i18n import translate
  from Products.ERP5.ERP5Site import getSite
  translation_domain = "ui" # or "erp5_ui", there is an alias in Localizer
  return translate(msgid="View", domain=translation_domain, context=getSite() )

This way we could probably implement a getMessage method that does not need to pass a "translate method". But maybe it would still need a domain="ui" parameter, because Formulator should not decide which translation domain to use

This way we could probably implement a getMessage method that does not need to pass a "translate method". But maybe it would still need a domain="ui" parameter, because Formulator should not decide which translation domain to use

mmm not sure which will be clearer API in the end. You think having "ui" as default would be good enough?

Yes, I don't know which API I like better. I suggested the "placeless translation" approach because I saw it was used in some places in zope (including in page template engine), so I felt it might be more in the spirit of zope, but there are still this issue that from formulator we don't know the translation context edit: domain.

Frankly, this API at the end will be used in two places, so we don't need to discuss so much a perfect solution. It's better if we don't make Formulator depend on ERP5* not to have circles in the dependencies.

If we do the placeless way, I'm OK with using "ui" as default value, I'm not even shocked if with hardcode "ui" in Formulator. I'm also OK with this way of passing the translate function.

I do not have strong objection either way, but I kind of feel that passing the translate function, as it does now, will be more straightforward for an ERP5 developer to understand. So I lean towards keeping it this way.