-
Notifications
You must be signed in to change notification settings - Fork 0
dft street manager spike 0022 localisation
As a GOV.UK service we need to support Welsh language, which means localising our application content for users English/Welsh.
This has implications for development, testing and long term support, as Welsh content will need to be validated and the service tested in both languages as long as it is active.
Standard approach is to read the users language preference from the users browser (see here) and also allow the user to set their preference via a cookie set via a language selection option.
Both Node and Java web frameworks have a number of options for localising content using files to store translated content for different languages. These files can be generated from view templates and code which includes english text and provided to translation services to be populated with content.
If notifications are required to be localised into Welsh then there are two main options:
-
Record the users language preference and when sending notifications and maintain both English and Welsh versions of notification content.
-
Send notifications with both English and Welsh content.
In both cases dynamic content needs to be considered, as changes in reference data, singular/plural terms can affect the localisation.
Choice of approach for notification localisation is mainly a business/design decision, as it may not be possible to determine users preference upfront.
As part of normal development, developers need to wrap and identify all English content with the localisation library (e.g. i18n.__('Hello')). This ensures that all content to be translated is identifiable. At the point translation is required a script (created by developers) is run to pre-populate the translation file with English-English mapping, this file is supplied to the translators with some additional business context (screenshots, UX prototype access etc.). When the translations are supplied the file is added/updated into source and the application can be sanity tested by testers then tested by Welsh language users. The scripts used to generate the translation file should be run regularly to check that no content has been updated without an updated translation.
Alternatively, localisation can be left to end of development. This requires searching the entire application for all English content, wrapping with localisation commands and getting translations, which adds risk and large effort to end of a release.
We should include a localisation library as part of our initial setup of any web application and include localisation as an NFR as part of the first notification stories.
The choice of localisation library should depend on language/framework choice, but as localisation is such a common requirement it is very common for major frameworks to have a default or popular localisation choice, so this should not be major concern.
It is important that English content is wrapped in localisation functions early, as if this is attempted later it is very likely that some content will be missed (e.g. dynamic content), so this should be part of the standard development process.
- What approach for localisation are we taking in Beta MVP?
- Who will be performing the translations and how will they supply them?
TODO - Review