1. 3
  1.  

  2. 1

    This is an excellent improvement to Rails i18n! But as a regular user of gettext, I’m a bit surprised nobody figured this out before. Analyzing the application source code to extract translation strings is a standard feature of gettext and people have been using it for years. Anyway, kudos to the authors for porting this to the i18n gem!

    1. 2

      Compared to gettext, doing this for i18n is less trivial. I’ve never used gettext, but a few things that gettext does not have to deal with, but this gem does are:

      • relative keys
      • plural form subtrees
      • over 9,000 different ways to call I18n.translate in ruby (scope argument, dynamic keys, etc)
      • locale data stored in multiple files, routed to files based on key patterns
      1. 2

        Sorry for answering so late. I’ve just read your reply. You’re right, i18n was not designed with static analysis in mind, unlike gettext. Now I understand why implementing this gem was not trivial at all. Thanks for sharing your insights about this; it would probably be helpful for a JS project I’m working on!