ActionView::Template::Error - undefined method `symbolize_keys'

[eric-christian]

Hello

We are getting the following exception:

ActionView::Template::Error
undefined method `symbolize_keys' for "<span class=\"translation_missing\" title=\"translation missing: de.good_job.number.format\">Format</span>":ActiveSupport::SafeBuffer (ActionView::Template::Error)
NoMethodError
undefined method `symbolize_keys' for "<span class=\"translation_missing\" title=\"translation missing: de.good_job.number.format\">Format</span>":ActiveSupport::SafeBuffer (NoMethodError)

          options = escape_unsafe_options(options.symbolize_keys)
                                                 ^^^^^^^^^^^^^^^

At https://github.com/bensheldon/good_job/blob/main/app/views/good_job/shared/_filter.erb#L18 the call to t does not return something that responds to symbolize_keys but an ActiveSupport::SafeBuffer which holds the translation missing HTML-Message.

Our app only supports the languages de, fr and it. fr works, because it is supported by GoodJob. de and it are causing the exception, as they are not supported by GoodJob.

What is the expected solution for that? We are unable to enable en for our app.
We could copy the en.yml to our app as de/good_job.yml and it/good_job.yml, which would work until there are any updates to the GoodJobs en.yml. So i would prefer a more permanent solution.

Best regards
Eric

[bensheldon]

Thank you for opening the issue! This is definitely a bug introduced by #850 / #862 that should be fixed in GoodJob.

Let me set up a test/reproduction and I think I can get this fixed.

[bensheldon]

@eric-christian I have a PR (#891) that I think will smooth over some of this. It will prevent the GoodJob Dashboard from raising an exception, and it won't offer untranslated locales in the dropdown, other than what is currently the fallback of I18n.default_locale.

Unfortunately, if :en is not in your I18n.available_locales it's simply not possible to display the :en translations without I18n raising an exception. Placeholders are the best I can do working with I18n afaik. Rails Engines and I18n are more tightly coupled than I would expect.

It's not my favorite either, I think my recommendation in this case would be to copy GoodJob's en.yml to your application as config/locales/{{I18n.default_locale}}/good_job.yml.

[eric-christian]

@bensheldon Thank you for your quick response!

As long as we have an intersection between our locales and GoodJob locales and no more exceptions raised, we are probably fine. I'll have to discuss this topic with my team.

What would be the process of adding more locales to GoodJob? Would you be up for that?

Best regards
Eric

[bensheldon]

👍🏻

For adding locales, you could copy the en.yml file and translate the keys

Alternatively, I could create a PR with a machine translated version first and ask you to review and correct it.

Also, I'm curious if you get value from the localized strings or if it being hardcoded in English would be sufficient (I've had lots of debate as to whether I18n is worth the effort for a developer tool). I also realize localization tends to trail features in GoodJob and not everything is localized.

[eric-christian]

Hi @bensheldon

To add to the debate, we don't really need translations for the GoodJob UI. Everything in english would be fine for us and our customer. Most of the time, we (devs) are the users of the UI. Our customers have access and they can use the UI if they wish, but they usually don't do that very often.

The customers of our customers don't have access. If that would have been the case, we would have needed full translations for all our supported languages. I don't think that i ever had that situation in any project in my past 20+ years.

Maybe keeping I18n out of the mix and instead implement a simple alternative solution would be better.

That said, i could work out the translations and formats for de. I'll create a PR myself, haven't done that in a while and some practice is always a good thing. 👍

Best regards,
Eric

[danielpuglisi]

Same here. We just copied the en.yml file to config/locales/de/good_job.yml to avoid this error. Seems a bit unnecessary.