Hide Forgot
Description of problem: Consideration of Server-side file conversion and REST service: * Server tasks * REST services to support all file types (raw upload of all formats that we support in the client) * 'File' project type will now support both okapi (.odt, idml, etc.) and Properties/Utf8Properties projects * Server to check file size and filename before accepting, reject files that are larger than our current maximum file size. * Use existing async framework to process the uploaded files. * One call to deliver the file, multiple subsequent calls to ask for progress * Sent file should send following metadata: * MIME type * File size * File name * Have the upload (from the JavaScript) use the REST API * project-type only File, but support all the file types in it * push source and translation * pull source and translation Future enhancements: * File handling (future enhancement to allow thin java client) * Which files to be pushed/pulled * File mapping rule * Streaming for text base translation formats (e.g. gettext) * (Optional) compress the uploaded file. gzip is a good option. * Keep previous version of the uploaded file.
Michelle, we might want to raise the priority on this one. It's one that will let us have a thinner clients. We can discuss.
Agreed. Making this issue high priority to work on in coming sprints. Thanks.
Pull request: zanata-common - https://github.com/zanata/zanata-common/pull/9 zanata-api - https://github.com/zanata/zanata-api/pull/26 zanata-client - https://github.com/zanata/zanata-client/pull/57
zanata-server: https://github.com/zanata/zanata-server/pull/772
Testing/requirements note: Should we make sure that you can still download translated properties/xliff files even if the raw document has been removed from the file system?
See Also: https://bitbucket.org/okapiframework/okapi/issue/459
VERIFIED with Zanata 3.7.0-SNAPSHOT (git-jenkins-zanata-server-build-integration-master-5214) Client: Zanta 3.7.0-SNAPSHOT (commit: 57b61850cc35e0f01182531062fe74a55c698400)