Thinking about the release / translation workflow

As I'm maintaining on of the l.d.o translation groups I start seeing the pending approval list growing too much. Yes, I know we need more 'maintainers work' but also there are some issues about how we are currently handling releases and strings that makes old strings stay there forever, cluttering the approval list. This is related to the packaging process too.

So I just want to make some reflection and see what makes sense to implement. Let's consider some cases:

• A new minor version Drupal core / module release is out (Drupal 6.10 -> 6.11, Module 6.x-1.0 -> 6.x-1.1). In this case it may make sense to keep the old strings available for download for people who for whatever reason don't feel the press to upgrade right away. But on the other side we may prefer translators to stay focused on the latest release only.
• A new module point release is out (Module 6.x-1.0-beta1 to 6.x-1.0-beta2). For this case we don't really want to keep old strings or translations. We better just provide a 6.x-1.0 download and keep it in sync with the last module version. We should drop old strings from everywhere
• A new full version version (new branch) of the module is out (Module 6.x-1.0 to 6.x-2.0). Then we should make a difference on whether the old version is still supported or not. If supported we should still keep old strings available for translation, not otherwise. Though in both cases we still want to have them available for downloading.

In any case we should always consider there may be people using old versions of core or modules, either because they have them already download or running, or because they simply don't need to upgrade yet. They may be also doing a fresh install with old versions of modules.

My conclusions from all this:

• For packaging, we just need to keep a file for each minor version of core / modules. Like 6.x-1.0.es.po. But we don't need in any case to keep files for point releases like 6.x-1.0-beta1.es.po. We can also drop the old release and the strings right away when moving from beta1 to beta2
• We need to keep all strings for all minor versions if only for tracking/credits purposes. But old ones we don't want them to clutter the translation ui or the approval queue. So we need something like 'disabled' strings.

How this translates to the module code and data model:

• We need a 'status' field on the releases table to know for which releases we are still doing repackaging and accepting strings
• We need a 'status' field on the strings table to keep track of all translated strings, though some of them may not be 'translatable' anymore
• We need to keep release status in sync with drupal.org project releases. And we need to keep strings in sync with releases. A string needs to be 'deleted' when it is in beta1 but not in beta2. And needs to be 'disabled' when it is in 6.x-1.1 but not in 6.x-1.2 (Unless it is in some other module's supported version)