Message strings of BatchAction (including DeleteAction) is generated in _conjugate of BatchAction in horizon/tables/actions.py. _conjugate() generates both "present" message string (which is used as table action name and confirm dialog) and "past" message strings (which is displayed as a message popup after the specified operation is completed).
Iin some languages (at least Japanese) we need to use different translated strings for "present" and "past" message strings, but The same string "%(action)s %(data_type)s" is used to generate them. As a result, either of "present" or "past" message string may become odd translation string (e.g., Havana Horizon translation in Japanese has some odd strings due to this issue).
At least it is better "present" and "past" message strings can be distinguished.
From translation perspective, it is ideal we can define "present" and "past" strings respectively for each action class rather than generating strings in _conjugate(). Translator need to use different strings based on action types. It will be filed as a separate bug.
My idea is to use contextual marker [1] to distinguish them.
I would like to hear opinions before proposing a patch.
@@ -557,8 +558,11 @@ class BatchAction(Action):
data_type = self.data_type_singular
else:
data_type = self.data_type_plural
- return _("%(action)s %(data_type)s") % {'action': action,
- 'data_type': data_type}
+ if action_type == "past":
+ msgstr = pgettext_lazy("past", "%(action)s %(data_type)s")
+ else:
+ msgstr = pgettext_lazy("present", "%(action)s %(data_type)s")
+ return msgstr % {'action': action, 'data_type': data_type}
def action(self, request, datum_id):
"""
After this, we can get the following entries in the PO file and assign different translations to "past" and "present" strings.
#: tables/actions.py:562
#, python-format
msgctxt "past"
msgid "%(action)s %(data_type)s"
msgstr ""
#: tables/actions.py:564
#, python-format
msgctxt "present"
msgid "%(action)s %(data_type)s"
msgstr ""
[1] https://docs.djangoproject.com/en/dev/topics/i18n/translation/#contextual-markers
This looks good to me, it seems useful and quite low impact in terms of changing the current code. If it helps the dashboard have more natural sounding translations when used in other languages we should do it :-)
It may be good to also ask the i18n team for their input and the impact on other languages?
In general I worry about having a "_conjugate()" method in the code, this makes a lot of assumptions on language. Perhaps we should also work on a separate longer term solution.