Harnessing the Power of Braze, Lokalise, and S3

Maximizing efficiency through a custom integration of Braze, Lokalise, and S3

I love my job of Sales Engineer at Lokalise. I thrive on solving puzzles with out-of-the-box thinking. Each day presents new challenges, and the lessons learned yesterday become the building blocks for tomorrow's solutions.

The Scenario:

One of our customers utilizes Braze CMS for their push notifications and email campaigns, translating the content through Lokalise. However, their workflow in Braze leads to duplicated key names in Lokalise, with only the filenames serving as unique identifiers.

To send translations from Lokalise to a Lokalise AWS S3 bucket and inject them into customer messages using Braze's Connected Content based on their language preferences, the customer relies on the Braze app within Lokalise.

See their workflow drawn out below.

The Challenge:

Within a Lokalise project, the Lokalise-Braze app allows only one file per language in a designated AWS S3 bucket. As a result, all English translations are sent to the "en.json" file, and all Spanish translations to "es.json."

Why is this problematic? The file structure prohibits the use of repeated key names, and the customer’s workflow in Braze relies on repeated key names. Therefore, making it incompatible with Lokalise's out-of-the-box Braze app. Unfortunately, modifying the file structure is not an option.

The Solution:

Given the customer's preference to continue using their Braze workflow for emails and push notifications, I explored various angles to find a resolution. Initially, I considered modifying the Braze workflow to generate unique key IDs, thereby eliminating repeated keys in the Lokalise S3 translation files. However, this approach proved less than ideal as it would require altering the Braze workflow.

Late one night, while engaged in an unrelated activity, the solution struck me. I recalled configuring my own S3 bucket to deliver content. My website project dynamically loaded language data directly from my S3 bucket when users switched languages, without relying on individual language resource files. This realization sparked a question: If my web project could fetch translations from my S3 bucket, why couldn't Braze's Connected Content do the same?

Indeed, it could! Leveraging my own custom bucket, I uploaded translations to unique files, eliminating the need for mono language resource files in each language pair. Consequently, I could now use repeated key names in my Lokalise project and S3 bucket because they now uploaded to separate files.

See the updated workflow below, paying attention to the Amazon S3 bucket:

Conclusion:

By adopting a clever approach to integrate Braze, Lokalise, and S3, we overcome the challenges posed by the customer's workflow. The need for repeated key names within Lokalise, caused by Braze's file structure limitations, no longer hinders the localization process. Because Braze's Connected Content can fetch translations from a custom S3 bucket, we have unlocked a seamless solution.