Software localization refers to the complex processes required to make a software product available in more than its original language. For more information on software localization, read our article: What is Software localization? Website localization is analogous to software localization, and shares many similarities but also has key differences that need to be considered.
Content for translation lives in a repository in both cases
Websites typically rely on a Content Management System (CMS) such as WordPress, Drupal, or Adobe Experience Manager. The CMS will store and manage the pages, components, and content. This is more or less analogous to GitHub or another code repository used as the source for website localization.
Content needs to be exported – and in both cases, this is a key step
Regardless of the repository or Content Management System, the content for translations needs to be exported in a translatable format such as XML, XLIFF, CSV, or other formats that allow content to be exported and imported. The considerations for website and software localization when it comes to this step are the same:
- Parsing needs to be optimized to ensure that:
- Content needs to be isolated from code
- Variables need to be protected
- Segmentation needs to be optimized to ensure that line breaks and content breaks make sense for the content. For example, you probably don’t want your main taglines to read as two separate sentences just because there is a line break as that will compromise localization and knowledge management processes.
- The import/export process needs to be tested
Content needs to be translated in both cases with similar concerns
- Key Focus around terminology and consistency – in websites more focused on Search Engine Optimization (SEO) purposes whereas on Software more focused on buttons, key interface text, and other UI/UX-focused terms;
- Key Focus on contextualization – While websites tend to have a mix of content types such as heavy writing on main landing pages vs. technical writing on support pages, software tends to be more homogenous in terms of its writing style. But the key tenant remains the same. It doesn’t matter if the words or even the sentences are translated correctly from a technical perspective. It matters whether we are providing the user with a great experience;
- Both use cases are heavily reliant on our web preview feature in Bureau Works as that allows translators and reviewers to look at how their translations and rendering in real-time, adding another layer of contextualization richness to the process.
Content needs to be QAed
Bureau Works’ software has a constant concern with the quality level of translations.
Both Software and Websites require a QA/Testing process to fine-tune translations and ensure that results are as desired.
Now let’s discuss the critical fundamental differences between Sofware and Website Localization.
Difference nº1: Purpose
User Experience vs. Conversion.
Software is focused on User Experience while Websites are typically focused on searchability and conversion. This means that terminology management in Website translation has another dimension to it: SEO.
It also means that keywords are meant to compel users to take certain actions or feel certain things. So while software will typically focus on accuracy, predictability, and intelligibility, Websites need to generate results.
This will typically mean that you will need to spend a lot of time and resources to ensure that you have carefully decided on your keyword strategy and that you are happy with the copywriting used in your main conversion pages. This also may mean that for websites you may want to explore transcreation or even have a local agency re-work the translated copy so that it reads and feels like entirely new copywriting in that target language.
With software, the bar is a bit lower. It needs to be consistent, but it doesn’t need to get someone to do or feel something.
Difference nº2 – Not all content is created equally
Support, Headlines, Homepage, etc.
Software content will vary in relevance depending on the traffic certain parts of the app get. Certain aspects or components may be a lot more relevant than others.
Difference nº3 – There is less complexity in terms of code for websites
This is not necessarily true but it is a rule of thumb. In general website, exports will present less need for a specific parsing strategy than software. But depending on the content management system you are using and the architectural complexity of your website, you can make software localization seem like a walk in the park in terms of your parsing and segmentation strategy concerns.
With websites, you need specific strategies for instance: how to treat hyperlinks, external reference material, or embedded documents such as manuals, white papers, or videos. So while the web content itself may require less file engineering than software content, the web will typically exist in a multimedia format which will result in more complexity to the overall localization process.
All of these assets need to be looked at decisions must be made on whether they will be within or outside of the intended web scope.
Website and software localization have one thing in common. Both can become incredibly messy and complex nightmares on wheels. They also have the potential to become predictable, sustainable, and simple to manage. It all stems from having the overall localization architectural design mapped out from the start.
People will often go with a content management system and a translation management system and think they will then pull a rabbit out of their hats but that couldn’t be further from the truth. With any process management, there is no single better or proven process. But there is the best process for each use case.
And the use-case needs to be considered in its entirety and with all its complexity to then simplify and arrive at the most sustainable and scalable process that will deliver your required results.
In one word: clarity. If you know what you have and what you need to deliver, it’s fairly easy to make good decisions.
But in most enterprise use cases, you don’t have a single point of ownership and need to start fighting battles with different camps in your organization over processes, tools, and providers. Sometimes it even seems like it’s like working with entirely different companies within the same group.
Putting politics aside (which typically is the most complicating factor in both web and software localization), it’s about keeping it as simple and effective as possible.
As you continuously update or add content or languages, you will pay dearly for any minor cracks in your overall localization infrastructure.
Start early, start small and iterate. It always pays.
September 22, 2022