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!
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
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!
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!
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:
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!