[placeholder]

Continuous Localization at Squarespace

At Squarespace, our mission is to help anyone in the world bring their ideas to life through our platform. We want to provide a fully localized product and set of tools so that our current and future customers have the ability to create a website in any language using the entirety of the product.

Along with the launch of an end-to-end Squarespace experience in Spanish, in this blog post we would like to take a look at some of the major technologies that power our global expansion.

Challenges

The two major challenges that we were facing were: how to provide a fully automated localization experience, and adapt it into our current development and release lifecycles.

We wanted to develop a seamless workflow, so that our product engineers can easily localize their content in an automated fashion without worrying about the complexity of handling translation logistics. We also wanted to make sure that adding product support for new locales is an easy process as we scale and add more languages.

Furthermore, Squarespace is available on various platforms and devices, which each have their own standard for localization. To meet these standards, and adapt the localization process into our current agile development and continuous integration/deployment process, was another set of challenges we had to face.

Continuous Localization Engine

The answer is Idioma, the localization engine we developed at Squarespace which enables the continuous localization process in an automated and scalable fashion.

As the core of the localization engine, Idioma acts as the bridge between our code repository (where our software strings live) and translation management system (where the translations are performed and stored). It is responsible for handling the logistics of translations, and managing the state of translation delivery. It creates a generic workflow that can be adopted for various platforms, such as microservices and mobile apps.

A simple localization workflow goes as follows:

  1. Developer commits their English strings in the string bundle file within a target branch.
  2. Idioma automatically pulls the updates (new/updated/deleted strings) and submits them to the translation management system for translation.
  3. Once the translation is completed, Idioma automatically pulls the translated strings and commits them back to the target branch.

Here is a more concrete example: a developer has created a feature branch and has the English source bundle “email-messages_en.yaml” ready for translation. Once the feature branch has been configured within Idioma, the English bundle is submitted for translation. After translation is complete, Idioma automatically commits back all the translated strings into their associated bundle files based on the locale and the configuration.

The localization process is performed in a continuous and incremental manner, meaning that subsequent updates for source strings and translations will be captured automatically. On top of that, all the localization actions and data are configurable through our localization user interface (covered in the following section), such as locales, file naming, file path etc.

A more comprehensive view of the entire localization workflow with Idioma including string extraction and integration/deployment pipeline:

Localization User Interface (UI)

In order to achieve a fully self-service localization workflow, we also need to provide a good user interface for product engineers to interact with so that they can easily localize their content. Having an easy-to-use, intuitive UI plays a significant role in smoothing the process.

Through localization UI, product engineers are able to:

  • Configure and manage their project/branch for target locale(s) in Idioma
  • Track translation progress on each individual file / bundle level

Translation Management System

Translation management system is a central platform that we use to manage all submitted source strings and translations. While a custom solution is feasible depending on the requirements, we are currently using Smartling, which hosts our translations, and also provide a user interface that translators can interact with, and provide translations.

Next Steps

Translation quality is important to the overall quality of our localized product, and translation context is critical in improving the overall translation quality, especially the visual context. One improvement is to provide a true, accurate visual of the content that is being translated, fully in context. In other words, when translators are able to see what they are translating, they are able to make fast linguistic decisions based on where a particular word or sentence lives, or how it’s being used.

The other challenge is the testing process. Currently, once our product is localized with a new locale, our QA and UI teams have to manually open and log into our product on each target platform and go through every translation to ensure accuracy within the context. This will not scale as we are introducing more languages. One way to improve this is to provide an automated platform which allows anyone to select and filter a specific set of unique screens for a given locale. In this way, a Spanish specialist can easily go through all the target Spanish test screens within a much shorter time in comparison to evaluating every single scenario manually in our product.

We Are Hiring!

The Core Services team is always on the lookout for talent that can help us grow and improve our core service components. Click here to apply!

Building On Solid Ground: Getting Postgres Foundations Right With pgbedrock

The Nuts and Bolts with Robyn Trovati