narralabs/i18n-ai

[BUG] Fix issue where rails app fails to load when first time loading a locale

Opened this issue · 2 comments

How to Reproduce

  1. Make sure no locales exist in config/locales besides en.yml
  2. Given a page /good_morning that uses locale:
<%= t("good_morning", locale: params[:locale].presence || I18n.default_locale) %>
  1. Add the new language:
- config.generate_locales = [:es]
+config.generate_locales = [:es, :fr] 
  1. Restart the rails server
  2. Load the translated page on first load: /good_morning?locale=fr
  3. The page will break citing the locale does not exist but fr.yml has been generated and next load will be successful.

What Should Happen

The page should load successfully on first load without error and with fr translations

It appears the our current approach of generating locales at runtime is causing issues on the first load of a page with the new locale. Also, checking and generating locales at runtime can be an intensive and potentially expensive process, which may impact application performance.

To address these concerns I propose we generate translation during initialization, before the server starts handling requests. This shift from runtime to initialization will ensure that all locales are ready before any requests are processed.

By doing so we can "fail fast" catching any issues during initialization rather than at runtime.

If we want to continue generating the locales at runtime, we can then just add the newly created locales to I18n.available_locales and call I18n.backend.reload! when finishing generating all the translations.

What are your thoughts on this?

It appears the our current approach of generating locales at runtime is causing issues on the first load of a page with the new locale.

@wilburhimself that is correct. i believe this is due to the nature of rails loading the available locale files before processing the request. the fact that fr.yml did not exist initially made rails think it wasn't available even though it was generated within that same request.

Also, checking and generating locales at runtime can be an intensive and potentially expensive process, which may impact application performance.

at the current structure, that is correct, especially if the yaml files are big enough and imagine having many of them (like in one of our production apps). it will indeed be an expensive process.

as far as solutions:

  1. your solution of generating translation during initialization makes sense although it would add a step to restart the server everytime you modify any base translation file which could be annoying unless you are using guard to watch the files and automatically restart.
  2. i was thinking to cache each line in the base yaml file and only translating those that are changed but i imagine the code to be more complex to handle this.
  3. we could also implement another solution similar to tailwindcss-rails watch process. where we can introduce something like bin/rails i18n-ai:watch which watches the base yaml files and translates when needed.
  4. continue generating at runtime and implement your solution of: I18n.available_locales and call I18n.backend.reload! (although i haven't tried if this works yet)

thoughts? i'm currently voting for 3. but then still expensive so maybe includes some of 2. as well. will give it a day to think about this. how about yourself? what solution do you prefer?