App localisation
Written by Mitchell Farguhar
Updated at January 21st, 2025
Table of Contents
Bolt Language Support
Bolt has been developed with localisation (L10n) and internationalisation (i18n) in mind. Apps can configured to be bilingual, multilingual or, as is most common, monolingual.
The apps employ the standard localisation features of iOS and Android, allowing us to extend support to many languages and locales, including Right-to-Left (RTL) scripts.
This document talks about the app container - the actual content from your CMS is shown in the language(s) you provide in your feeds
Supporting Multiple Languages
Languages and locales are configured at build-time, so adding/removing language support will require a new build and submission to the app stores. The app store is then likely to display the app as being available in ‘X’ language when an end-user views the app details in the store before downloading.
When the app is run, the operating system will automatically look at the user's language set up on the device and use this to select the locale which is the closest match out of the available locales ‘baked-into’ the build.
For instance, if an app is configured with the following locales; British English (en-GB), French (fr-FR) & Italian (it-IT), and a user's device is set to Canadian English (en-CA) the operating system is likely to select British English (en-GB) as the closest match. However, an end-user who has selected their device language to Canadian French (fr-CA) is likely to automatically receive the French (fr-FR) translations of the app. Internationalisation of plural strings and date format also works in the same way. See Unicode's language matching chart for more information.
Android always implicitly “supports” American English (en-US). Unfortunately this meant that if the primary device language chosen by the user is closer (see relevant § of CLDR) to English than the user's secondary language, the app will be put into American English. For apps which do not support English, the app will then fallback to a pseudorandom language that your Pugpig app does support.
To add support for a new language or locale in your app reach out via support@pugpig.com. We may require you to provide initial translations for the language until we are able to provide suitable default translations for the language/locale.
Translating Bolt into a new language
We use XLIFF to provide translators with our copy for translation. XLIFF is an industry standard file format. Professional translators should be able to handle this format. Additionally there are various online tools which support this format. It should also be noted that this file format is XML, so any plain text editor can be used as long as care is taken to ensure the edits remain valid XML.
Distribution's copy picker offers the following export options to get XLIFF file for translators:
- “publication copy"; every thing you see in the copy picker with defaults too
- “publication copy with fallbacks”; every key that is entered into the copy picker, but those languages that don’t have defaults in their language will fallback to en-GB as opposed to being empty
- “all keys”; all keys in our spec except read-only keys
- “all keys with fallbacks”; all keys in our spec except read-only keys, but those languages that don’t have defaults in their language will fallback to en-GB as opposed to being empty
Distribution's re-import option will do the right thing when re-uploading any of the above translated XLIFF files.
Dates and times
In order to support the many locales we do, our date formatting options are limited to the Unicode Common Locale Data Repository (CLDR)'s combined formats:
- full
- long
- medium
- short
You can apply these formats to the date and time components separately. E.g. have “full” date, but a “short” time which in US English would yield “Sunday, October 15, 2023 at 6:30 pm”.
Examples
| Date | Time | |
| Short | 10/15/23 | 6:30 PM |
| Medium | Oct 15, 2023 | 6:30:00 PM |
| Long | October 15, 2023 | 6:30:00 PM GMT+1 |
| Full | Sunday, October 15, 2023 | 6:30:00 PM British Summer Time |
Configuring the formats in our products
This is done in the copy picker by editing the relevant key(s). Our date/time localisable string keys support the following mustache template substitutions:
- date
- time
- datetime
Each of the above must be followed by one of the formats above. E.g. {{date.full}} or {{time.short}}. The datetime object must be followed by the date format AND the time format, such as {{datetime.full.short}}.
The platform documentations for their respective implementations of this unicode standard are below:
- https://developer.android.com/reference/java/text/DateFormat
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat
- https://developer.apple.com/documentation/foundation/dateformatter/style