In this blog we want to talk about localization in software development. We will explore techniques, tools and best practices in software localization that help you avoid the pitfalls of localization and deliver great products to an international audience.
Localization is usually not as complex as it is sometimes presented. All modern development environments support localization and provide the necessary infrastructure to separate strings to be translated from code.
Localization support is integrated directly into .NET Windows Forms, ASP.NET, WPF and all other .NET target platforms. It can be activated with a few clicks in Visual Studio and usually requires you to insert all your strings into resX files, which are then compiled into satellite assemblies.
Angular offers the i18n attribute to highlight text to be translated, and the xi18n tool to extract these strings to an XLIFF file for translation.
So far so good, but the best platform support is useless if the localization is an afterthought. We've seen many projects over the years that have been developed without localization in mind and then inevitably run into trouble when another language needs to be supported. If all your strings are somewhere in your code, unmarked and not separated, adding a new language becomes a real challenge. Finding all strings and changing or moving them to separate files is almost impossible in a larger project and will almost certainly cause many errors that only your customers will find.
So when it comes to localization a good start is everything. Think about localization before you start coding! And follow these simple rules:
Visual Studio is a very productive development environment but with regards to localization if offers very little. Localizing in Visual Studio is possible by creating resource files (.resX files) for the different target languages and then translating the Windows Forms (C# or VB.NET) or ASP.NET pages (.aspx files).