It often happens that a singular lightbox will need to be shown in different geographical areas and translated accordingly. Digioh supports this with the Internationalization Translation App.
First, install the app:
To do this, you’ll need to install the Digioh Internationalization Translation App. Go to your profile menu, select Custom JS (Apps), find “Internationalization Translation” in the list and click Install.
Next, configure a Google Sheet with the necessary translations:
The sheet will need to be set up with:
– column for ‘Label’
– column for ‘Submit Value’
– column for each language (details on how to label those later in the documentation – in the next step under the bullet labeled ‘i18n_regex’)
Here is an example sheet to start with and to reference in the documentation: – linked here.
Next, configure the widget-level metadata:
The 3 metadata listed are necessary for Internationalization App to translate elements on any lightbox:
- i18n_gsheet_id – If you are using a gsheet, this metadata is required
– Here, add the id of the GSheet link for the translation sheet
– For the example translation sheet listed above, that is 1GHFH_JR76WTLBsXu0fXN2eSj_tcc2J1hUE3Fkw_qf3A
- i18n_csv_url – If you’d prefer to use a .csv file instead of a gsheet, you can use this metadata instead
– Here, add the link to the .csv file
- i18n_gsheet_gid – (required if not ‘0’)
– This is the id of the tab of the translation sheet within the GSheet
– This will default to ‘0’, and when there are multiple tabs in a GSheet, it will be listed in the link after ‘gid=’
- i18n_lang_regex – (optional)
– This is where you can put a custom Regex Equation to find the language necessary to translate
– By default, the App looks in the URL for ‘xx-yy’, where xx is the language code and yy is the country code and pulls xx to use as the language (for instance ‘en-us’, ‘en-gb’ will both pull ‘en’ as the language)
– If you need to change this behavior, this configuration allows you to personalize the app to pull the language from the page’s URL – it will return the second matched group
– Note that the language will need to match the language heading in the Translation GSheet (if the URL uses en, the label in the sheet must be en, not English)
Next, configure the elements in the lightbox to be translated with their labels:
In the editor, the elements that need to be translated will need to be labeled through the metadata configuration.
These labels will need to match the labels in the ‘Label’ column of the Translation GSheet.
Once the elements are labeled, they will translate for each language for which there is a column/translation in the Translation GSheet.
In this example, a CTA on the first page of the lightbox needs to be translated (‘Click to Begin’).
The translation spreadsheet will have a row with ‘intro_cta’ in the label column, and the translations for that button in the appropriate rows (the Spanish translation under ‘es’, the German under ‘de’, etc).
These labels should be added to each element (whether text or button) with the key ‘i18n’.
In the case of elements used multiple times throughout the lightbox:
When there are buttons or text used multiple times throughout the lightbox, use the same label for each.
For example, if there are back buttons on each page, each back button in the editor should have their metadata configuration set with the same configuration:
- Key: i18n
- Value: back_button
Then, in the Translation Sheet, only one row needs to be set for these buttons with the translation (example in the Translation Sheet from above).
In the case of dropdowns:
When dropdowns are translated, they will also need their values set for each language.
To do this, add the desired submission value for the option in the same row as the option label under the ‘Submit Value’ column
This allows for different geographical locations to have customized dropdowns.
– For example, maybe the German site should not include the brand ‘Brand 3’
– To make this happen, in the row for ‘Brand 3’, simply leave the cell in the ‘de’ column blank
– Then, as the translations are done, the dropdown will not include ‘Brand 3’ when translating to German
In the case of input ghost text/error message:
To translate the ghost text of an input (or an error message associated with an input) , begin by installing App 61 Universal Merge Tags (documentation linked here).
Next, for input ghost text:
- configure the ghost text input of the element with [i18n|ghostTextLabel]
- where ghostTextLabel is the label in the translation sheet for this ghost text
- ex: [i18n|emailGhostText] for an email input where “emailGhostText” is the label for the translations of this element’s ghost text in the translations spreadsheet
For input error messages:
- configure the error input of the element with [i18n|errorLabel]
- where errorLabel is the label in the translation sheet for this ghost text
- ex: [i18n|emailErrorText] for an email input where “emailErrorText” is the label for the translations of this element’s error message in the translations spreadsheet
In the case of ghost text for first and last name elements in a form:
The name element in a form can show in multiple ways (first name only, both first and last name, full name). In order to translate the name input’s ghost text:
- If you are using first and last name:
- In the metadata of the name element, add ‘i18n’ : ‘first_and_last_name’
- In the translations spreadsheet:
- add a placeholder label ‘first_and_last’ with the rest of the row blank
- label the first name translations with label: ‘first_and_last_name_first’
- label the last name translations with label: ‘first_and_last_name_last’
i18n Interoperation with Other Apps
You may need to adjust the configuration of other apps based on the dynamically determined language. To support this, i18n recognizes and processes a prefix of i18n:xyz: on metadata commands. So for example, if you are using the Product Recommendation Quiz app, you might want to swap out a different product GSheet based on the language:
This works for any metadata command. In general, configure alternate metadata commands for each possible language, with the i18n:lang: prefix. So if your metadata command is “app_command”, and you have languages en and fr, then use metadata:
i18n:en:app_command = something English specific
i18n:fr:app_command = something French specific
How this works is that i18n first detects the language, then scans all metadata looking for a prefix match. All matching commands have the prefix removed, thereby activating those app commands dynamically. The other app will not recognize commands where the prefix remains, only those that have been activated by i18n.
Questions? Comments? Let us know at firstname.lastname@example.org