I was all around our remote submission code with Jose, and we came down to basically suggesting a remote submission interface via XML-RPC, where users would have API keys instead of being required to be logged in on the remote server all the times. This has a little bit more startup cost for users but does require less attention while being used, since users don't need to be logged in on both sites.
This is achieved by the client providing a client token and the server signing that with its key, providing the user with a private key. The submissions are signed with the private key, thus ensuring that only the given user can submit the translation. The XML-RPC interface also allows remote clients to get some basic information on the server, such as the list of supported languages. This will be built on later.
Comment | File | Size | Author |
---|---|---|---|
new_remote_api_20.patch | 6.11 KB | Gábor Hojtsy | |
Comments
Comment #1
Gábor HojtsyWups, it should be mentioned, that the architect behind this is Jose A Reyero, I am just reviewing, cleaning up and committing :)
Comment #2
hass CreditAttribution: hass commentedl10n_remote_xmlrpc_string_submit have many translatable strings that are not t'ified.
Comment #3
Gábor Hojtsyhass: What we could do is to add a source site language code argument to the API, so that we know what target language to translate the error message to. Even then we can only translate to that language, if the server is running that language (which for an l10n_server) might be likely. So this requires an API change at least.
We made it non-translatable, so that the client can actually log these messages in watchdog (which is expected to use English text). If people think it is more important to have the messages translated, even though they are not displayed on the UI except the log, when we can do that. I think that we do break the watchdog() rules there however.
Comment #4
hass CreditAttribution: hass commentedHmmm... how about adding the strings with t() somewhere in the l10n_server and client code as "potx extractable dummies"? This would allow us to translate it on client and server side, but we exchange only English strings in the API...
Comment #5
meba CreditAttribution: meba commentedsubscribe
Comment #6
Gábor Hojtsy@hass: I'm closing this one, since we have a nice focused issue at #688048: Display feedback on submission error about this, and the original aim of this issue was solved, so let's consider on the UI feedback there.