Episerver Add-on: Simple way to ease localization
There is no doubt in the fact that Episerver is well suited for managing localization of content. Localization of the site copy – being e.g. global elements and labels – and site content – being block/page content – is, natively supported via a combination of language branches and xml-resource files.
Many Episerver developers agrees that relying on static XML Resource Files for site copy – e.g. Header-EN.xml detailing the localized copy of ‘Change Language’ – removes a high level of flexibility. Supporting a clients need to establish a new localized country site requires multiple activities such as development, translation and deployment. Important thing is that rolling out a new country site is more than just a task for the marketing team.
I’ve previously read and implemented posts suggesting approaches such as site settings or translation pages for managing these site copy translations. I do, in theory, recognize the approach. In reality, my experience tells me differently. Building an enterprise solution, leveraging e.g. both Episerver CMS and Episerver Commerce, requires a large amount of elements up for translation. Our challenge is that this approach is manageable in the beginning.. but as the solution evolves, we are requiring our editors to manage localization of elements and labels in multiple places, which is not only creating a high level of confusion but are also bloating translation pages with hundreds of fields.
Let me uncover one solution for managing translations that fulfills our overall goals:
- Enable marketing teams to launch and translate a new country site without involvement from a development team or hosting partner.
- Support the need to include a translation in the solution acting as the initial value and foundation for upcoming country sites.
- Create a dedicated, familiar and structured approach to work with translations of labels and global elements
- Support the fact that projects are evolving and that the need for particular translations are changing (create and delete) during the application lifetime.
Let’s take a quick look at how we can support these goals.
Fellow.Epi.Localization: Translations as part of the Episerver UI
This translation add-on provides Content Editors with an intuitive way of working with pre-defined translatable elements through a dedicated Translations gadget.
Usage from both a Content Editor and developers standpoint is fairly simple. Let me take you through some of the high-level features.
Definition of Translations
Translatable fields are, by default, based on existing Episerver XML Resource Files and are automatically included in the Translations gadget based on configurable conventions. Intent is that the translation add-on will fit both new and existing Episerver projects without any need for refactoring.
Working with Languages
Fellow.Epi.Localization is a powerful add-on to any Episerver solution that supports additional language sites. Supporting initial values via language inheritance or language dedicated resource files are essential features when translation of site copy is needed. It allows any Administrator and Content Editor to configure a new language site without deployment or development activities being a pre-requisite.
Easy use on existing Episerver projects
This translation add-on is extending the existing Episerver Localization System via a dedicated Translation Provider. Any Episerver Platform relying on default features for localization and translation can benefit from this solution without any refactoring or customization needed. Conventions within Fellow.Epi.Localization can be adjusted to fit the structure of your existing XML Resource Files.
Customization and Extensibility
Fellow.Epi.Localization can be customized and extended in numerous ways. Architecture is based on a loosely coupled and highly interchangeable strategy ensuring that internal parts can be configured or replaced to accommodate even the rarest needs.
Installation and Usage
You can get the latest version of Fellow.Epi.Localization through Episervers NuGet feed.
Be aware that Fellow.Epi.Localization requires EPiServer.CMS.Core version 220.127.116.11 or higher.
Please use the GitHub project for any issues, questions or other kinds of feedback.
Fellow.Epi.Localization requires two minor code adjustments in order to be fully integrated with your Episerver solution.
Please ensure that Episerver is aware of the translation add-on by adding the custom localization provider through the Episerver.Framework configuration section. Even though we transform configuration files during installation of the NuGet package, some manual configuration changes may be needed in case your solution e.g. includes the Episerver.Framework configuration section via a separate file.
<add name="translations" virtualPath="~/Your-Path-Goes-Here" type="Fellow.Epi.Localization.Infrastructure.Providers.TranslationLocalizationProvider, Fellow.Epi.Localization" />
Changing default conventions
Adjusting the rule detailing which translatable fields to include is needed in order to use any customized structure in your XML Resource Files. It is a matter of implementing an IIncludeConvention and telling Fellow.Epi.Localization about this through Structuremap.
Above implementation ensures that all resource elements below </header>, </commerce> and </form> are included in the Translations gadget. Below is an example on a Resource File matching these conventions.