Mozilla related
Solas related
Projects should be defined in a .pootle configuration folder for the command line tool or in the API.
Warning
Q: I think it would make sense to allow codes to be used.
A: Tried but was problematic. Perhaps I was told to change how the resource URI is generated.
TODO: I need to check http://django-tastypie.readthedocs.org/en/latest/resources.html#get-resource-uri but this will be left for the future.
Warning
TODO: Need to look at caching. But this will be left for the future.
Note
Warning
Q: Need to make clear at which levels translations can be pushed or retrieved. I assume that the original idea was to push files.
Perhaps we should start with a low level API and then add that ability at upper levels. By that I mean pushing single units and then add the ability for sending/retrieving files (stores), and after that perhaps add at upper levels (TP, project or subsets of those two).
A: Yes, the original idea in ttk-get and ttk-put is to push and pull files. Also for Solas it would be that ability.
I’m not sure what the lowest level should be, I guess unit for live interaction e.g. Virtaal translating live against Pootle DB. Or a live website wanting to see flow of translations.
But for most project related I would see this as a store, while a store is a collection of units it is what Pootle is using. Unit level allows clearer abstraction of searching and checks I would guess.
Some discussion needed here I think.
Note
DB: Should we call get and put, push and pull to match DVCS semantics? I’m leaning to pull and push.
We’ll use tastypie to handle the RESTful API.
Initial tastypie implementation that puts in all the infrastructure for the API. Including updates to requirements/, documentation, etc.
API version will be 0.9 until stabilised.
Basic API implementation for list_languages and a command line tool that could call it.
Provide stats for Mozilla in terms of translations contributed. Provide a linkable badge for users to brag about translations that makes use of this API.
We’ll address the command line approach as a test implementation. Thus allowing all actions from a pootle-cli tool. This will allow us to iron out issues and easily test error reporting and failures. When it passes that would mean that we can safely expose this to external tools.
Actual Pootle <–> Solas interaction. So expose the API and give feedback to the team on collaboration.
Using Virtaal. Some ideas: