i18n: in production
Prior to going to production, you should consider the following:
- How does our translation function work when we:
- don't have access to an interpolated value?
- don't have access to the dictionary?
- don't have a phrase associated with a token?
- Does your automated testing framework request a copy of the dictionary from your TMS with each run? Consider mirroring the dictionary locally or on an internal resource to save costs
Bugs
One bug you might encounter is when interpolation fails:
<Invoice>
{translate('invoiceTitleAndNumber', {invoiceNumber: invoiceData.invoiceNumber })}</Invoice>
- If this page is compiled before the API call to our invoice endpoint is made, will the passed value be defined?
- How will the
translate()function perform when the value is undefined?
If your translation function does not handle this gracefully, you may end up with Invoice number: {{invoiceNumber}} appearing in your application.
Another stepping stone to consider is the strategy by which you deliver your dictionary to your application. You may wish to grab a copy via your CI/CD scripts when the application is being built & bundle that. You may wish to serve this programmatically via API. In both cases, you might have to adapt how your translation function works to accommodate for this. In our use case, bundling the latest copy of the dictionary with the application when it was built was the right call.
You should also consider how your translation function behaves when it receives a token which:
- Has no phrase associated with it in the requested language
- Is not a valid token name according to your dictionary
Additionally, you can catch errors like this by engineering your CI/CD scripts:
- Examine the diff between the current commit and the planned deployment
- In any calls to the translate function, extract the name of the token
- If this token is not present in the dictionary file, alert or abort the build.
next: doing it again