When starting an export job via the API, one may provide an optional translation ID, in order to dictate which translation is used for the output data’s variable and value labels. How does one obtain this ID currently? If that the translation ID is not currently available from an (REST) API endpoint, could it be added, either to an existing endpoint or to a new (REST API) endpoint?
For reference, I’m asking about
TranslationID in the body of requests for this endpoint.
The only place I could find the translation ID is via the GraphQL API, but haven’t experimented yet to see whether any nodes actually lead to the fields pictured below (from schema.graphql). I also have looked to see if the JSON representation of the questionnaire contains this information.
You find the right place - GraphQL endpoint indeed contains information on translations for each questionnaire, so to get the list of translation id and names your query will look something like this:
This request would work without filtering by specific questionnaire id or version, but reading translation info is somewhat ‘expensive’ operation so if you don’t need to get all translations of all of your questionnaires on the server, makes sense to keep the filter.
Many thanks for confirming, Zurab!
Before closing this issue and marking the above as the solution, any plans to offering translation IDs as part of the return from
For my own part, I’m happy to use GraphQL. But I wonder if it would be reasonable to provide the REST API endpoints with “feature parity” where it makes sense to do so–both for the server, which satisfies requests, and for the the client, who needs to formulate the requests. Where GraphQL does away with pagination or with chained requests (e.g., first, get supervisors, then get users, etc.), it’s clearly the superior solution for all concerned. For requests like this, I might, personally, be more inclined to go with REST, since the client interface is more straightforward (with the type of tooling I use for using API endpoints and their results).
Again, I’m happy to use GraphQL, but imagine that it may not be the most familiar or most easy to use for some.
I don’t think that we’ll be continuing with REST and GraphQL as ‘two alternatives with feature parity’, more like when one does something already, the second will (most likely) not duplicate the effort.
In general, I’d prefer users to be given language-specific client libraries that are ‘officially’ supported so that not every user needs to implement http calling logic. This includes having R client package also, so that that package will have option to get translations and whether it is done via one get call or another post should not bother users.
Working on it
I’ll post for informational purposes once the package goes live. I’m working on some long-form documentation and a few missing functions (like translation IDs) right now.