"translation missing" being delivered via email

bug
1

An email with this subject got delivered to users on today’s digest, on 1.8.0.beta9:

translation missing: pt_BR.user_notifications.digest.subject_template

This message was originally indeed not translated (was sent as “[%{site_name}] Summary”), and I then properly translated it by hand by customizing in the respective settings tab. String appeared fine, but the actual message was sent with the above instead.

Seems like some kind of issue with that context specifically. Customizing other messages showing up in the UI itself seems to have worked fine.

2 Likes
3

Its same with me “translation missing: tr_TR.user_notifications.digest.subject_template”

image.png756×91 7.36 KB

image.png1090×218 16.4 KB

3 Likes
4

Thanks for confirming @Celil. Clearly there’s something wrong happening with translations there.

More details about the behavior:

There is already a translation in place for the string:

Despite that, the email arrives untranslated:

If the string is manually re-translated the error shows up as the email subject:

2 Likes
5

Same thing happens to me but only if I use %{site_name} in the translation. The problem seems to be the misleading default translation. If you instead use %{email_prefix} Your translation it will work the way you want it to.

I am looking at the code for the first time, but if this does what I think it does that means SiteSettings.title is provided to the translation as ‘email_prefix’ because of customizable email branding settings.

I’m not really sure where the misleading default comes from because, in the case of my language at least, there is no default provided and the default for english uses email_prefix.

4 Likes
6

That’s a great hint, thanks!

I bet the main logic and default sentence was changed when the email_prefix was introduced, and the pre-existing translations were left behind.

Trying your suggestion now.

7

Confirmed, it does work with %{email_prefix}, so the confusing bug is indeed the incorrect and misleading translation.

Might also be worth improving the error message so people are guided towards the right solution.

3 Likes
8

this string has also caused the same problem in our case:

%{topic_excerpt}

1 Like
9

Hello. It’s still same

translation missing: tr_TR.

user_notifications.mailing_list.why

user_notifications.mailing_list.subject_template

image.png1092×228 16.3 KB

image.png919×168 8.4 KB

image.png957×172 8.62 KB

10

@codinghorror can you help me for this problem?

11

I suspect the issue you’re having is because you’ve changed the variables in the translation strings. For example, for the subject template, the English translation is

[%{email_prefix}] Summary for %{date}

Therefore in any translation you can only use the email_prefix and date variables. I believe you must actually use both of them for it to work.

In your subject_template, you’ve put site_name, which won’t work.

3 Likes
12

thank you. I will try.

13

Since it is rather easy to break custom text (in the sense that it will fail to render due to missing translation), it would be great if there could be a security mechanism that prevents emails from being sent out if they contain translation missing: and instead send an error message to the site admin?

3 Likes
14

This would be great. Obviously with email it’s super important, but I wonder if the same thing could also be done across the site. It’s quite hard to check every single translation, and no way to do it automatically AFAIK?

Maybe a “failed translations” tab on the logs section of the admin screen? Ideally would contain errors from both the JS I18N and the ruby I18N