"translation missing" being delivered via email

(Gustavo Niemeyer) #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.

Show indicator when a default text content element has been updated?
(Celil Çağlar ÖzlÜ) #3

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

(Gustavo Niemeyer) #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:

(Jan Wąsak) #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.

(Gustavo Niemeyer) #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.

(Gustavo Niemeyer) #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.

(Pad Pors) #8

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


(Celil Çağlar ÖzlÜ) #9

Hello. It’s still same

translation missing: tr_TR.



(Celil Çağlar ÖzlÜ) #10

@codinghorror can you help me for this problem?

(David Taylor) #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.

(Celil Çağlar ÖzlÜ) #12

thank you. I will try.

(Christoph) #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?

Discobot translation missing error
(David Taylor) #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

(Jeff Atwood) #15