There's a module for that! Drupal architecture and module development

In part 1 of this series, I introduced the workflow we use for managing i18n-friendly configuration using Features. One of the cornerstones of the solution is the Features Translations module (hereafter called FT for brevity), which stores string translations in the feature.

One former limitation of FT is that it exported all translated strings in a given language/text group set, even if those strings had never been changed manually after importing them from the Drupal Translations site. For the Default text group, the resulting feature file was huge. With a deployment workflow that involves drush fr-all -y each time, the deployment time became unbearably slow.

We fortunately found some time to fix this problem, by optimizing the translation sets to only changed strings. The general idea of the solution is extremely simple: we just want to export those string translations that are different from their original translation, or that don't exist in core or contrib. Our reference is the .po files served by Drupal Translations.

You can try it right now:

• Update FT to 7.x-1.0-beta3 or later.
• Enable the Localization update module
• Set the local po directory path at admin/config/regional/language/update
• Update your contrib module string translation using drush l10n-update and ensure the .po files are correctly saved where you pointed
• Update your feature that contains translations using drush fu my-translation-feature -y

That's it! You should notice a significant decrease in the exported string translations. Many thanks to fellow Meedani Mohammed El-Sawy for the neat implementation.