"Untranslated" translated field title returns msgid instead of default value

Development Translations and i18n/l10
1

hi all,

in my view, I use

if not relation_caption:
    # translate the default related items field label
    relation_caption = translate(
        u'label_related_items',
        domain='plone',
        context=self.request,
        default='Related Items')

to get the translated text of a field label

the corresponding terms in english and german are here:

When I do not provide my own default value, for english Plone will return the msgid "label_related_items" because the msgstr is empty.

How do I avoid having to provide my own default?

2

Your current code treats 'label_related_items' like a normal string. It is not a translated string.
It should be something like this:

from zope.i18nmessageid import MessageFactory
_ = MessageFactory('plone')
relation_caption = translate(
    _(u'label_related_items', default='Related Items'),
    context=self.request,)
3

Thanks for the suggestion, but that has the same exact result: without providing a default, the msgid is returned for the en translation.

I realize now that what I probably want is to fall back on the title of the actual field. And if any default is then used, it will be the one defined in my schema :wink:

4

Norbert via Plone Community wrote at 2019-11-11 12:29 +0000:

Thanks for the suggestion, but that has the same exact result: without providing a default, the msgid is returned for the en translation.

I think that is exactly what is intended: the message id is translated
according to the current language translation catalog; if this
does not provide a translation, the provided default translation is
used and missing this, the message id itself is used.

You cannot use the normal translation machinery if this is not
what you need.

5

Yep, that was my mistake. I took it as a given that ./en/plone.po would contain the actual msgstr rather than being a copy of plone.pot

Side note - Makes me think that since all the default values are there anyway, it might be possible to have these also stored (pot2po) as messagestrings. Maybe a discussion for some other time...