Investigate how our proposed internationalisation approach works for service teams

[vanitabarrett]

What

Test our internationalisation spike with service teams to check that it works for 1) teams that aren't doing translations yet, but are interested in adding some and 2) teams that already support translations in their own services and which our solution will need to work alongside.

Some service teams will have their own requirement to support different languages and will already have a process in place in their own application for internationalisation. We should get an understanding of how service teams have implemented this, so we can keep this in mind when investigating our own solutions for internationalisation. We need to make sure that any solution we build fits in with what service teams are already doing.

Who needs to work on this

Developer; User Researcher

Who needs to review this

Developers

Done when

• Identified some service teams to talk to who are interested in internationalisation
• Created some draft documentation
• Generated a pre-release
• Decided any specific questions that we have or any specific things we want people to test, e.g: translating a character count, even if their service doesn't use one
• Decided a deadline for feedback
• Drafted a message to send to testers with information on installing the pre-release, link to documentation, info on what we want them to do and how they can provide feedback
• Talked to all teams
• Written up any findings, specifically any actions we might need to take
• Ask user to clarify on issue with _one plural form - what were they trying to do and what error did they get? Write spin off card if needed - pending reply

[vanitabarrett]

@claireashworth is going to draft up a message we can post on Slack to see if people are interested in testing with us.

[calvin-lau-sig7]

Just putting this idea here: I can reach out to the GDS International team to see if they can help us spread the word to any international partners.

[vanitabarrett]

We've had some feedback from one user. They tried to translate the accordion component and ended up with multiple show/hide buttons in both English and Welsh. My hunch is this is because they're calling init() on the accordion twice - I can replicate the same issue if I have two initAll() statements (one with translations passed, one without). We should wait for other testers and feedback to come back, but we may need to take a look at the docs and make sure it's clear to add the translations to your existing initAll() / init() statements rather than just copying and pasting the code examples we provide.

I've also asked this user for more feedback on their experience finding the information they needed and whether it was easy to understand what they needed to do, so I'll see if they get back to me on that.

[vanitabarrett]

@kr8n3r raised a good point that we don't have any guidance on how people might translate multiple instances of a component on the page (with different translations) - specifically, text in component JS. We probably don't have many examples of that happening as we only have hardcoded strings in the accordion (which would all be the same) and character count (possibility translations may be different here). We might want to think about if that's something we want to add into the docs.

[querkmachine]

The above problems feel like they could be related to me: for example, we may want to make it so that there are protections against a component being initialised more than once.

Then it may become possible to initialise individual components with the needed customisations, followed by everything else with the defaults.

new Accordion($element1, { … }).init()
new Accordion($element2, { … }).init()
initAll()

[vanitabarrett]

Have started collating the feedback in this doc so it's all in one place https://docs.google.com/document/d/1B9ag7WPN0dDuBxVSKntVBxUM7Y7xVTKromKPcZwIjZc/edit#

[vanitabarrett]

Have sent a follow-up message to the user we wanted to get some more details from. Moving this into blocked until we've heard back.

[vanitabarrett]

One user who tested our pre-release reported issues when they failed to provide a translation for a plural form required by that language. In their code, they hadn't provided a translation string for _one.

Their code:

character_count: {
        i18n: {
          locale: "en",
          translations: {
            characters_over_limit_other: "Thou hast writen %{count} letters too many",
            characters_under_limit_other: "Thou hast %{count} letters remainen"
          }
        }
      }

The error they got: Uncaught TypeError: outputString is undefined.

Full video:
https://user-images.githubusercontent.com/29889908/185928647-8ddac8da-0c0e-4aae-ba7a-e012541080e5.mov

We might want to see if there's a "nicer" error message we can give in this kind of scenario.

[vanitabarrett]

Have added a note about the above comment to the card where we'll implement the pluralisation logic.

Going to close this card now.