WIP: Validation message translation
Before this MR, translation happened typically in higher level, where the error message was rendered. but this imposed translation in everything, including mapped messages, pollluting Localizer with unneeded messages.
This MR introduces to ValidationError getMessage, the logic is:
- If the message is defined in the code that raises, then it should be translated there
- If the message is defined in the field (in 'manage_messagesForm') then we need to translate in ValidationError class. Caller should pass translation_service, because we do not want to import it in Formulator
now that I look again, I realize maybe we could implement this
getMessageso that we don't have to pass the translate method. For example with
Products.ERP5Type.Message.Messagewe 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
getMessagemethod 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
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.