Understanding software internationalization and localization
You might already know, separating text from code is a basic principle of internationalization (i18n), or making your app translation-friendly. In practice, this means that software developers need to store localization strings, such as UI labels and error messages, as variables in one or more separate files.
This way, the application can retrieve the strings from a single source and the translation can’t mess up the code. The resulting files are often called i18n files.
The actual translation of i18n files is called localization (l10n), since it also involves local adaptation of the user experience.
Choosing the right translation file format
i18n files can have multiple formats; JSON is one popular choice. But PO, CSV, YAML or Java .properties are other popular file formats. Here is a quick overview of the pros and cons of each file format:
Building a good workflow to translate software
One of the software localizations best practices in SaaS is to create separate i18n files for each target language version and find an intuitive directory structure and naming convention. This is an architectural challenge in and of itself.
For example, you could have all source files with UI strings in a separate folder and then add a subfolder called “i18n” with the localized files for each target language. Or you could store all texts in a single file.
Once that is set up, you need to get the original texts out of your code repository (e.g. GitHub) into a translation environment and then send back the translated texts. This gets especially tricky when you’re constantly pushing small, incremental changes.
The interplay between the various tools for creating content, version control systems and translation software is complex and usually requires some type of custom software in the middle.
>> Learn more about string translation
Why use a centralized, multilingual content management system?
To simplify your translation process, you can use an all-in-one authoring and localization tool such as Gridly. Gridly isn’t solely a content operations platform that lets you create, edit and maintain localization files in multiple formats, it also has the functionality of a TMS (translation management system), in case you need to actually translate these files.
Gridly can also work as a content platform to enable SaaS localization. You can choose whether to translate directly in Gridly or use an integration with pure-play translation software, such as Phrase or memoQ.
In other words, you can do all your authoring and translation in Gridly, or use it as a go-between.
Besides using Gridly’s interface or our file uploader to upload files directly to your grid, you can automate the connection between Gridly and any other system that features an API. If you’ve ever depended on an external vendor to build a custom integration, you might see the benefit. Using Gridly’s API allows you to automate your content operations and reduce file handling.
Gridly’s customizability is enhanced by Lambda functions. They let you add code in a wide range of programming languages to do basically anything with your content.
For example, you can set a trigger to automatically retranslate all target language cells and then add a Lambda function with an API call to any MT provider of your choice. Below you see how a workflow for this could look:
Figure 1
Besides using Lambda functions to leverage custom tools, you can use various integrated services, such as Google Translate, AWS translate or ChatGPT on your content without any need to code.
>> Explore how to leverage AI-assisted translation in Gridly
Comparing centralized translation content management to traditional methods
So broadly speaking, Gridly can be customized to cover all your content and translation needs. Let’s have a look at the following two diagrams and see how Gridly works:
In Figure 1, you see a mix of manual and automated processes in a traditional localization workflow. This may even require the customer to write their own middleware. They’ll never have all their content in one place and might need to buy licenses for different translation software providers, because one is specialized for software UI strings, while the other is for website and documentation content. They might even need to buy additional licenses for tools that offer advanced features, such as screenshot management and localization quality assurance (LQA), which are already included in Gridly.
Figure 2
In Figure 2, you see a localization process in Gridly. Regardless of where you produce or store text content, you can easily create your own integrations with Gridly or use what we offer out of the box. You then have the choice of whether to do the translation directly in Gridly or hook up an existing translation management system.
A tech stack for software development can include GitHub for hosting translation files, a custom CMS to maintain the documentation and a website CMS like Typo3 or Wordpress. You’ll work with various plugins that push authoring content and translatable strings to a translation environment and retrieve the translated content.
On top of that, you might have to translate multilingual support tickets in tools like Zendesk and team communication in Google Sheets or tools from the Microsoft Office suite, such as Excel or OneNote. The challenge with this content is that it’s not written for publication, so you don’t want to invest too much or spend a lot of time waiting for human translation. So machine translation is the natural choice. On the other hand, such texts are often written in a casual tone, therefore the quality of user-generated content translated with plugins for DeepL or Google Translate can vary significantly.
Gridly covers a wide user base and can be tailored to many content types. Thanks to customizable views, you can have all experts working in Gridly or let them use their tools of choice. You can narrow down the displayed data to what’s relevant for writers, translators, etc. or define your own user type.
Lambda functions mean you don’t have to rely on out-of-the-box integrations, but can easily connect to any system with an API, just by uploading your own scripts.
Fewer tools, less complexity
Navigating the world of software localization requires you to balance internationalization principles with efficient translation workflows, and find the right mix of machine translation and human translation.
Following sound localization practices, such as separating text from code and choosing the right translation file format can make your job a lot easier. With its customizable features and automation capabilities, Gridly lets you streamline workflows and customize your message for international users.
Beyond sheer technical skills, such as translation or engineering, tool procurement is an often-overlooked cost factor. Usually, less is more, but it’s always a best-of-breed vs. best-of-suite trade-off: either you purchase many specialized tools with a great depth of features or you choose fewer tools that are very versatile but don’t have that many specialized features.
Gridly doesn’t just offer sophisticated translation and content management features, it also lets you cover many use cases, so your content doesn’t get buried under your tech stack. Whether you want to translate JSON files or any other format, whether you already have a translation process or are new to the field, you’ll find it’s designed with developers in mind to avoid bottlenecks and enable continuous localization.
