One of the goals of 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.


I can imagine some more things we can do.

- a way to export own suggestion (include suggestion / approved / declined strings)
so you can always get back your own submission. encourage users do more submission online even admin don't like their submission or you get a lazy admin never approve your work.

- add a filter for re-suggested
give a more clear way to admin to see what re-suggested.

- a way to display all declined strings
some declined strings only contains a few mistake. we can edit it to be more better and resubmit again.

above stuff is logging what users have done. but if we can let admin easier to know what users have "do" may much better.
sorting in more way [#598898].
(I don't want to kill all suggestions if only contains few mistake and at the time I can't correct all of them..long time passed, lots of suggestion are there.... and admin really don't know which is new added...)

Thanks for your ideas. Issues welcome as explained at the end of the post. Thanks!

Very nice!

Of course that makes me want even more, so I've submitted a feature request :-)

Sometimes an user makes a suggestion that is almost perfect, with some minor problem, like an typo or a lack of a period. When I see this, I have two choices:

  • I can decline the suggestion and wait for the user (or another) to send an correct version (which in most cases never happens in a low activity community).
  • Or I can edit the translation by myself to fix it, that's what I do normally, but I feel bad doing this because the original contributor don't "earns" nothing. The translation is marked as suggested and approved by me. Will be great if in this cases the author of the original suggestion has their name saved too.

This is something other people had ideas about. Please see for the issue discussing this problem. Now that we have tracking for who added something and who is it attributed to, it is even easier to implement tracking for this kind of feature.

Normally I edit the translation myself, this way it's much faster. This would be great to have such a feature to have the authors name saved so that he could earn as well.

Photo editor free