Internationalization Specification
Learn how Courier helps with content internationalization for browser, email and push notifications.
Flow
A notification template is changed and submitted for translation. Upon submission, an outbound webhook call will be made that will notify of a pending change submission. Upon receipt of the webhook event, the content for the notification template can be fetched and the translation process begun.
Diagram
Fetching Content
When the “notification:submitted” is received
GET /notifications/:notification_id/draft/content
Sample Template
Sample Template Response
Block Alias and Context
Every block can optionally have an alias and a context. This can be used to have supplementary block information for organizing blocks better.
Retrieval: GET content endpoints can be used to retrieve alias and context per block
Updates: Can only be changed from the Courier UI by clicking on the block info(i) icon
Template Block Info
Block Info Dialog
Block types supported
Text Block
Example: Text block with a variable {name}
and a highlight
Text Block Example
Here’s how the block JSON would look like
Let’s talk IDs
Block ID: This is the top level ID which every block gets and is prefixed with block
.
Variable ID: Unique IDs that a variable inside a block content gets
Highlight ID: Unique IDs that a highlight inside a block content gets
Note - All the IDs are auto-generated by Courier and are used in resolving the contents for the block. The locale variations PUT should also have exactly same IDs for accurate consolidation and resolution.
Quote Block
Example: Quote block with a variable {name}
and a highlight
Markdown Block
Example: Markdown block with a variable {name}
Action Block
List Block
List blocks can get a bit confusing - an article that can help an article that can help
Template Block
Note: We intentionally omit styles and comments in the API response to optimize the translation payload
Checksum
We md5 hash the contents for each block, channel and notification so you could track if contents have ever changed in order to manage translations workflow as needed.
Channels
We expose the email (subject) and push (title) to be localized (assuming you have those channels configured with your notification)
Updating Content
When translated content is received, template content should be fetched and the new content should be overlaid. This can be repeated each time a piece of translated content is received.
PUT /notifications/:notification_id/draft/locales
Updating partial contents
In case you’d like to update a specific block or a channel’s locales, or all blocks and channels for a specific locale (for ex: Chinese translations for a notification), we’ve got you covered. You can use the following endpoints -
Update locales for a specific block
POST /notifications/:notification_id/blocks/:block_id/locales
or POST /notifications/:id/draft/blocks/:blockId/locales
Update locales for a specific channel
POST /notifications/:id/channels/:channelId/locales
or POST /notifications/:id/draft/channels/:channelId/locales
Update block and channel contents for a specific locale
PUT /notifications/:id/locales/:localeid
or PUT /notifications/:id/draft/locales/:localeid
Completing The Process
Once all content has been updated, Courier can be notified that the process is completed and release the template to be published.
PUT /notifications/:notification_id/:submission_id/checks
Fetching Checks
Checks API GET endpoint
GET /notifications/:notification_id/:submission_id/checks
Example - GET /notifications/SFTYJKSF0241SVH2TWY97TTFFTQG/1630424150210/checks
Locale based preview
Notification Preview section reflects localized content if there’s a locale associated with the profile in your test-event. Here’s an example -
I have "locale": "fr_FR"
in the profile object of a test event
Localized Preview
Default Preview (no locale in the profile object of the test event)
Using locales while sending messages
You can use locale as a profile attribute while invoking Courier’s /send endpoint. Here’s an example -
Webhooks
As mentioned earlier in the doc, you could configure the webhooks in Settings → Webhooks and we’d call those when a notification was submitted for a review, when it was canceled and also when it got published. Please note: At this point we do not have a granular way to allocate webhooks so you could get other events (like message sent events) for the webhooks you add to the Settings, feel free to ignore/not handle those. Here’s a couple of screenshots -
Submitted Keys
Submitted keys are used when you have to send a notification that was submitted for a review but maybe not ready to be published. Basically, submitted is an interim state between Draft and Published. Here’s how it works -
→ If notification was published, a submitted key send operation uses published notification contents
→ If notification was submitted for review, a submitted key send operation uses latest draft notification content
Submitted keys can be retrieved, updated or deleted from the Settings → API Keys UI.
Block overrides
We also expose blocks
via overrides
object in case you need to override the contents on the fly during the send operations.