translation missing: en.discourse_narrative_bot.new_user_narrative.hello.message
If you’d like to learn more, select below and bookmark this private message. If you do, there may be a :gift: in your future!
My current template is :
Thanks for joining %{site_name}, and welcome!
- I’m only a robot, but [our friendly staff](/about) are also here to help if you need to reach a person.
- For safety reasons, we temporarily limit what new users can do. You’ll gain new abilities (and [badges](/badges)) as we get to know you.
- We believe in [civilized community behavior](/guidelines) at all times.
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 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.
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
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} -->.
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.
