Databases Reference
In-Depth Information
Copying Translations to Other Environments
Most of our customers uses multiple environments: usually one for development where developers have
the flexibility to change almost anything, one for user testing that is usually more restricted and often
used for testing the move to production, and a production environment that is completely secured and
restricted. This section explains how you can move your applications and their translations from one
environment to another.
Translating an application into multiple languages generates a separate application for each
mapped language. When the seed is completed, the translation repository is populated and this data is
used to generate and publish the translated applications. These applications cannot be modified in the
builder, but can be exported and imported.
Be aware that when exporting and importing an application, APEX keeps the mapping to the
application IDs defined in the globalization attributes. But this does not export and import the
translation metadata and, without the metadata, the translated application cannot be republished.
Because the application mapping to translations is done with the application ID, the same
application IDs must be used in all your environments: development, test, and production. In an APEX
installation, application IDs are unique throughout all the workspaces. This is also true for translated
applications. In order to keep the translation mapping and translated applications working, keep the
same application ID in all environments.
Anyway, it is good practice to use the same application IDs in all environments, especially if you
have translated applications. It is also important to be aware that if an application is shared with others,
the same application IDs will have to be reused to keep the language mapping.
The following sections describe two methods for moving applications from one environment to
another, copying only the applications or copying the primary application and publishing the translated
applications.
Copying Only the Applications
If you are using a runtime-only installation for production, this would be the method to use. In a
runtime-only installation, the builder is not available; as a result, you cannot do the translation process
and publish translated applications.
First, export the primary application and export all the translated applications. In the application
export, you will be able to select all the applications including the translated applications. Translated
applications cannot (and should not) be modified, but can be exported and imported.
Then, import all the applications, using the same application IDs, into the other environment.
Importing applications does
not
populate the translation metadata.
Using this method, you will not be able to regenerate and publish the translated applications in
those environments. So if a change must be done in the primary application and the corresponding
XLIFF file is not available, you will not be able to push those changes to the translated applications.
Copy the Primary Application and Publish
At some point in the development cycle it can happen that the development version of your application
is different than the one in production. What do you do if a quick fix is required in production? You
could temporarily bring the production copy back to development and fix it there. But to regenerate the
translated application, you need the corresponding XLIFF file for the production version. You could also
fix the problem directly in production and regenerate the translated applications.
To do so, first export the primary application, and then extract the corresponding XLIFF file with the
Download translatable text from repository to translation file (XLIFF File) option. Ensure that the
translation has been seeded with the latest version of the primary application.
