Discobot translation missing error

  • Yes, site is in english.
  • Running latest version v1.9.0.beta2 +7. I upgraded this morning.


I changed %{site_name}, to %{title},

and confirmed it by creating a new account. Thanks.

Hmm should this say “translation missing”? The error seems to be

Thanks for joining %{site_name}, and welcome!


Thanks for joining %{title}, and welcome!

Perhaps a better result would be

translation error: en.discourse_narrative_bot.new_user_narrative.hello.message

is that possible @tgxworld?

That is the message returned by the i18n gem when the given parameters do not match the expected parameters in the translation string. If we want to change the message we’ll have to propose it to the gem which might not be worth the trouble. Instead, I’m more inclined to fix the root cause here by adding a validation to check the same parameters are used in the customized string.

I think the upstream fix is superior in this case and would help more folks, bad error messages are very very dangerous.

1 Like

I don’t think the message is incorrect here. What is happening here is that the user is asking for a translation string that takes in the site_name params which isn’t defined so translation missing is correct here IMO.

I don’t agree. The translation is looking for key value pairs, the substitutions are at best optional parameters. In this case the translation is present according to the key value pair but missing parameters.

It is a very misleading error message… if it’s too hard to fix right, then so be it I guess.

1 Like

Is there any chance that these translation missing errors could also trigger a warning message to staff? In the case of emails, it might be best to suppress emails containing an error message as proposed here:

The substitutions are not optional in the case of translation strings with params.

I don’t necessary think it should be called an error but I do think that translation missing message can be improved to display the keys that are missing. Also the error that the gem raises is named I18n::MissingTranslationData so the message should probable have been translation data missing instead of just translation missing.

I just re-read through the guides and a nice thing that we can add is to test the user’s customized string first before allowing it to be saved. We can do something like

[13] pry(main)> begin
[13] pry(main)*   I18n.t('test.same_key', some: 'haha', raise: true)  
[13] pry(main)* rescue I18n::MissingTranslationData  
[13] pry(main)*   puts "o noes you didn't customize the text correctly"  
[13] pry(main)* end  
o noes you didn't customize the text correctly

Yes translation data missing works much better than translation missing! The messages need to be significantly different.

Created an issue in



Text customization will now check for right interpolation keys



What’s the reasoning for enforcing that all interpolation keys are used in the message?
(The missing_keys check in the commit.)

I ran into this when updating an email template on my forum — I cannot save the template unless I actually include all of the variables in the text.

Is there any way to turn off this validation from the admin interface?

Would be happy to contribute a pull request, but I wanted to check here to get some context/discussion on appropriate fix first. Thanks!

I can’t speak to the reason for requiring all variables, @tgxworld will need to, but you should be able to get around that by using HTML comments. For example <!-- %{site_name} -->.


Good idea, I’m not 100% sure what will happen in an email if you do that, I’d definitely test it out.

1 Like

I saw that suggestion here, which is marked as a solution by the OP so I’m assuming it works. (Emphasis on assume)


I considered that, but it won’t “resolve” the issue for email subject lines.

The idea is to help users check that they didn’t leave out any of the interpolation keys from the original translation. I didn’t think that some users would want to remove them completely. This isn’t critical but I added it along with the invalid_keys check which was the more critical one that would prevent users from shooting themselves in the foot. Unfortunately, that has since been reverted while I think of a solution for this hash which mixes parameters for the translations and options used to decide what type of emails to send.