[WIP][DO NOT MERGE] Nunjucks internationalisation support

[querkmachine]

In addition to updating our JavaScript to allow for localisation (#2614), we also have a few instances of hardcoded strings and fixed word order in our Nunjucks code that need to made configurable. There isn't a 'one size fits all' approach to doing this and we'll probably need to use slightly different methods for enabling localisation of each component.

Identified issues

• Character count: Fallback hint text is not editable within Nunjucks. Nunjucks parameters are interpolated into the hint in a fixed content order.
  • Character Count 'count message' cannot be customised or translated #1681
• Error message: Some visually hidden text (which defaults to ‘Error’) and a colon (:) are hardcoded to appear before the error message, creating a fixed content order.
  • Error message: Remove hardcoded content order #2650
• Footer: Content licence and Crown copyright notices are hardcoded.
  • Add ability to override or remove Crown Copyright in Footer #1290
  • Add ability to override or remove OGL logo in Footer #1291
• Header: The visible 'menu' link text is hardcoded. Currently, it will overlap the GOV.UK branding if the replacement label is quite long.
  • Make 'menu' text in header customisable #1904
• Summary list: The row key is interpolated alongside action text in a fixed content order.
  • Summary list links are hard to localise #2094
  • Summary list: Allow customisation of full action link content #2649

Possible improvements

• Date input: Each input's label is localisable, but only by providing the entire items array, requiring service users to also re-define the default name and classes if they don't want these to change. There may be a nicer way of doing this.
• Error summary: The description is always be interpolated between paragraph tags, even if the description is provided via the html parameter. This is the only component to do this; other components only add paragraph tags if the content is provided via text.

None of the above changes are to enable RTL language support.

[edwardhorsford]

Date input: Each input's label is localisable, but only by providing the entire items array, requiring service users to also re-define the default name and classes if they don't want these to change. There may be a nicer way of doing this.

I suspect in most cases teams might already have to do this? Don't you need to provide these where you're pre-setting a date? If a team has a check your answers page they'll likely be needing to pre-set.

(I think it would be great for you to be able to pre-set a date without requiring providing the whole array)

[querkmachine]

Regarding localisation of error messages and summary list action links—doing this is already possible by discarding the visuallyHiddenText and manually adding a visually-hidden span into the html parameter, such as doing this:

{{ govukErrorMessage({
  visuallyHiddenText: false,
  html: '<span class="govuk-visually-hidden">错误：</span>输入事件名称'
})

{{ govukSummaryList({
  rows: [
    {
      key: {
        text: "Name"
      },
      value: {
        text: "Nomen Nescio"
      },
      actions: {
        items: [
          {
            href: "#",
            visuallyHiddenText: false,
            html: '<span class="govuk-visually-hidden">Namen </span>ändern'
          }
        ]
      }
    }
  ]
}) }}

Is this a 'good enough' solution for those circumstances? It would require no new code changes, though this process would probably need to be documented somewhere.

Conversely, it does make languages that need to take this approach feel a bit 'second class', but they might be uncommon enough in implementation that it's not worth fussing over.

[edwardhorsford]

I reckon it's probably good enough in the first instance. Agree on documentation as I don't think it's obvious you could do this unless you were rather experienced with the deisgn system - I wonder if it would suit for the design system to have a specific page all about localisation which talks through the various things you might do.

[querkmachine]

Consensus within the team also seems to be that the above proposal will do for the time being. We'll revisit it if it proves to be too manual or too inflexible for service teams needs.

[querkmachine]

The contents of this branch/PR have now been incorporated into #2614, so I'm going to close this PR.