[GSoc Idea] Gettext API for Drupal contrib and core

Drupal core has some support for parsing and generating Gettext Portable Object (.po) files. This functionality was improved with Drupal 7 to support text context, that was part of the spec but not implemented in Drupal before. However, the actual code that is used to process and generate Gettext files is so baked in, there is no practical way to reuse them at all.

As a result, for example Translation template extractor and Localization server duplicate code for generating .po files themselves while Localization update and Localization server duplicate code to process .po files. While these implementations are more pluggable, there are already too many copies and the bigger problems are not solved. A major problem with .po file parsing is our one-pass approach, which bumps into memory and runtime limits on basic hosting.

1. Build a Gettext API module

Abstract the locale module code to be a better, extensible Gettext handler with an actual API. Architect this API after research of the needs of existing modules as well as any potential needs uncovered for the future. The module should be able to process and produce Gettext files from arbitrary data sources, potentially in multiple pieces.

As a first proof of concept, re-implement the Drupal core import functionality to use this code to be more shared-hosting friendly. (Re-implementing the export functionality will probably not lead to any user facing functionality difference).

Make sure the module has good test coverage (which can be built in part from the core tests, but given all the new capabilities, it will need significant expansion).

2. Get other modules depend on your work

To reduce module code duplication, develop patches for related modules to depend on this new module and use its APIs instead of copying core code. There is a high likeliness that if (1) is well done, the modules will accept the proposed patches (I'm maintainer or co-maintainer to those mentioned above, and can hopefully convince maintainers of other affected modules).

3. Get it into Drupal 8

Work with the multilingual initiative lead (if there is one such initiative at the time) and/or identify people in the community to team up with to get this functionality into Drupal 8 to avoid redoing the API in contrib in the future. The above contrib implementations should prove that the approach is sound and reusable, which is great supporting the core inclusion.