Translation fallback approach needs to be confirmed and applied

[maxgds]

Applications sometimes call components when the page is in a translated state. When this happens they are expected to supply the translated string to the component. The component may also augment this with strings that are internally translated, for example dates or fixed elements of the component.

We need to be able to handle what happens when either of these strings are not available in the desired language.

GOV.UK frontenders discussed this today and propose the following mechanism:

Since only the application can know if it has had to fall back and is supplying English, we should implement a mechanism to pass this information to the components. The component should respond to this parameter by applying lang=en to the container element so that the likes of search engines and assistive technology can recognise that the component is in English, and by using the English strings for any copy it supplies. We should present the whole component in English to avoid having to mix and match different elements within it and apply further lang attributes.

This does not address what to do if the content for the component is passed in the foreign language but the elements of the component don't have translations for the relevant language. In this case we should not apply the lang=en to the wrapper as we will not be changing the content back into English - this would be impossible for dynamic content. We should make best efforts to ensure we have all component strings translated to all supported languages to avoid that, but ideally when that is not possible we should label the individual component elements with lang=en where we cannot translate them. The downside of this approach is there would potentially be a lot of clutter with the language switching back and forth.