One of the goals of localize.drupal.org is to provide a simple UI on top of a complicated process: translation submission and approval. The system handles strings in three states: suggestion (pending approval), translations (which are approved) and declined strings (which were deemed to have bad quality). For the sake of approaching this as simple as possible, the backend focused on the submission and approval details so far, and neglected other transitions. However, in practice many limitations became evident.

You can choose to submit in the name of Multiple contributors but then the system will not have a trail that you did the submission. When you declined a previously approved string or demoted it to a suggestion, all records of its previous approval were lost. When you declined a translation or suggestion, no records were made as to who did it and when. There were no records of the type of submission interface used despite three different ways to submit strings (via import, via remote submission from l10n_client module and via the web interface). Translators and moderators wanted more information to aid them in their process, and we know it is always good to have more precise data to mine.

That said, it was time to complete the history implementation to cover all cases (and be extensible to more in the future). So I separated the history data from the submission data. This allows users to submit in the name of Multiple contributors but we will still have a record of who submitted the strings and when. All transitions now save history records, so we'll know if a string was declined, re-added or demoted. We store reference to the user doing the operation as well as the time of the operation. A brand new addition is that we store the medium through which the operation was performed. String additions are now possible via three mediums: the web interface, .po file imports and remote submissions (via l10n_client module). Now we'll be able to tell where a string came from much more exactly.

This data is so far only exposed on the translation user interface. Existing transition information was migrated on a best effort basis (we do not know about previous demotion and re-add transitions, and not even decline transitions if followed by re-add). Complete logging for all transitions allows us to get some interesting data to mine in the future. Moderators will be able to tell if previously declined strings re-appeared. We'll be able to look at patterns of use: whether people use .po file imports more, or who prefers the remote submission interface. Do we get lots of re-added strings? Maybe tell those importing the .po files to update their translations to latest versions. Moderators and site admins should be able to have a lot more information on usage patterns to understand and guide translators to be more effective.

All these changes are deployed now. Your window to this information is the byline under each translation (which got a bit shortened) and now displays attribution information (which is not necessarily the same as submission information anymore). Hopefully this little annotated screenshot will help you orient yourself on the new interface:

I think this change was crucial for the future of the project and to let it comfortably fill in its role as a replacement for file based version control handled translations. Feedback is welcome as always, see the issues and requests page for more information on the best way if you find issues to submit.