Translations Resource


This guide builds off many concepts reviewed in the Translations walk-through. The translation option used during form construction are the identical with the exception of where the data in stored. Instead of manually defining the translation definitions in the application layer, translations are stored in a remote resource within the users project on As a result, users can either embed a form within the project itself to modify the remote resource or use as an interface to manage form translations directly.

Source Code

A demo of this application and affiliate source code is available online. We encourage you to walk through the full guide, but if you would like to have this application up and running quickly, hen feel free to run the application from the source code. You can also use the source code as a reference when walking through this tutorial. Click on the button below to download the source code for this application.

Application Setup

Since this application is a continuation of the Translations walk-through, the final example serves as the starting point for this demo.

The Objective

This walk-through seeks to replace the local variables used in the above example with remote data stored in a platform resource. Please take this opportunity to download and import the resource.json that we’ll be using for the next part of the walk-through. Once finished, feel free to make a few language submission, for reference here is the spanish submission used in the demo.

As a point of reference, the language text-field defines the language codes while the data grid is responsible for creating the key value pairs which will manages the actual translated content. Finally, you will want to markdown the submission Id which can be found URL when viewing the submission data.

Using Portal Resource

With the stage set, it is time to replace the localized data with API calls to the new platform resource created above. A link to both the language Resource and their affiliate language Ids have been added to this of the project. Feel free to update these values with ones from your own project. Additionally, fetch logic has been added to to each button even handles retrieving, parsing, and injecting the language returns into the form definition.

Next Steps

If you are feeling ambitious, there are a couple of immediate improvements that go beyond the scope of this walk-through. The first would be to loop over all language results, thus removing the need to localize the submissionId’s. If you are interested in the PhraseApp integration, we do just that. Secondly, create a local cache of the translations. Not only would this localize the data after form construction, but would have the added benefit of dramatically reducing the number of API calls to the server. Next, you could reduce the fetch function that’s included in all three button events down to a single function call. Finally, add browser language detection and set the default language on form construction.