Language tools for templates

[amazingphilippe]

Other keywords: bilingual template, multilingual, editor, message, lang, language, preference

Description

As a Notify sender, I need to be able to send messages in the correct languages so that I can be compliant with official language act.

Job stories as Notify sender (Templates):

When writing a template, I want to specify its language, so that I can organize my templates by language. When writing a template, I want to mark which parts of the messages are in FR or EN, so that my messages support both official languages. When writing a template, I want to be able to provide localization to all fields, so that my messages can be sent to recipients in the right language.

Job stories as Notify sender (Sending):

When a template is ready to send, I want to specify the preferred language of my recipient, so that I can send a message in the right language.

WHY are we building? It isn't practical to serve official language within one or many services. So we can't provide the right tools to enable quality bilingual notifications. WHAT are we building? Fixing critical bugs. Then figuring out what we can improve. VALUE created by our solution: Support for official languages. Better notifications for recipients. Enabling services to leverage language preference data.

Acceptance Criteria** (Definition of done)

To be refined through discussion with the team

• [ ] Given Notify should serve FR and EN messages of equal quality, when a service looks to send messages, then they can provide equal quality messages in both languages.
• [ ] Given Notify should serve FR and EN messages based on recipient language preference, when a service looks to send messages, then they can set recipient language preferences.
• [ ] Given Notify should serve FR and EN messages of equal quality, when a service looks to write messages, then templates can be created and encoded to provide and help further language features.

Roadmap?

1. Fix repeated lang tag bug #491. Fix CSV column header in front-end #677
2. Improve guidance, test and improve tag syntax?
3. Create or find user needs to support. some assumptions:
   1. Localization of data like service name and branding
   2. Templates that can work with recipient language preferences
   3. CSV can contain a column for language preference, provided by the service owner.

If this user story emerged from User Research insights:

• [ ] Link research insight back to hypothesis from Epic or Objective in Airtable
• [ ] Once change/fix/feature is implemented, mark insight as "resolved" in Airtable
• [ ] Once change/fix/feature is implements, link insight to design artifacts (Figma) in Airtable

QA Steps

• [ ] Tested in a realistic production scenario

[amazingphilippe]

Previous work: https://docs.google.com/document/d/1L8NiIhs7qzKrLwFPLoqHzO6xy7C7Mlzf3mI4TFQtgD8/edit#heading=h.8tih6xbf8zg5

Roadmap

1. What language should we support (Yedida content presentation)
2. Start with the bug, then look at the guidance once again
3. Understand more our user needs before moving forward
4. Creating starter templates
5. Localizing fields in services. API setters and getters

Qs:

• How could we provide senders with tools to send messages in specific language. They could have recipient preferences.

[amazingphilippe]

This looks like an epic. I can see this in 3 different stories:

1. Fix the bug
2. Do some testing with users and needs audit
3. Design and deliver some improvements in key areas of Notify

[adriannelee]

@yaelberger-commits I wonder if we could reuse what GC Forms did for bilingual forms?