launchpad development
Let the uploader specify information needed for approval
This specification aims to combine two processes that were separate so far.
- Upload translation files to Launchpad
- Approve these files for import
This currently has its shortcomings and is a source of extra, often tedious work and user inquiries and, worst of all, user frustration.
Central Upload Form
When uploading translation files the user currently has the option to do so in three places.
- To the productseries ("Upload translations")
- To a specific translation template ("Upload a file")
- To a specific translation file ("Upload a file")
To the user it is not very transparent what he is uploading to and what the implications are of that. The forms have a slightly different look and may change depending on the users role in relation to the project.
This specification proposes a central upload form that presents the uploader with clear information about where he is uploading to and gives him a chance to revise that target. Instead of having a different form for each target, clicking on the "Upload translations" link always takes him to the same form with preset value depending on where he is coming from. Here is what it might look like:
To add a template, the "Template" can be set to "New", this would also be the default for the first upload. The setting "(multiple)" for languages could also be called "(not specified)" or just "--", similar for the template if multiple templates are in a tarball. These could be drop-down lists, too.
This way single file uploads will always go to the right template (if the user knows his templates) because would not be possible to upload a file directly to the product series, as it is now. An important part to make this work best, though, is to give the user a feedback about his upload.
Tarball uploads may contain more surprises (multiple templates, directory trees) and therefore need the next step, the upload feedback.
Upload Feedback
After a tarball is uploaded, it is already taken apart internally and stored as single uploads in the import queue. If a file's extension is not recognized, it is ignored. The result of this analysis might as well be reported back to the user.
Moreover, further analysis at this point will lead to approval of the uploaded files. So along side the information of "What I found in your tarball" comes the information "What I intend to do with it". This is what it might look like:
Self-service approval
Once the user is presented with the analysis of his upload, he may be given the chance to give further information, that is missing for approval or to cancel the import (remember, upload has already succeeded at this point). By this the user can himself make sure that his files get approved. In fact, they are approved right then and there and can go straight into the import stage. All that is left for manual approval are new templates, if that is still desired.
Far-out: File-system-like view
Even more transparency could be added if all translation files could be viewed by the user in a tree structure that corresponds to how he uploaded. The top-level entities would be the productserieses so that the user can copy translations between serieses. Translations export is then an operation on a subtree and imports could simply be updates of subtrees. New uploads would show up in the tree, too, letting the user define template - pofile relationships. This way, any directory layout can be served by Rosetta because the user is responsible for it and explicitly explains it. The current preferred layout would still work automatically, of course.
This could also be a bazaar branch, to facilitate easy uploads via bazaar, or imports from codehosting.
