As a product manager keen to research how other businesses had gone about internationalising their web-app product, I was surprised to see the limited number of resources which gave a practical insight into how it could be done.
Piclo’s product, Piclo Flex, is the leading marketplace for energy flexibility services. Piclo Flex brings together buyers (utilities or “System Operators” who manage electricity grids) and sellers of ‘flexibility’ (owners of assets that can respond to network needs), which is a relatively new way to balance our local electricity networks in the age of renewables. It’s a specialist B2B platform, but one that will increasingly underlie how we all get a reliable source of electricity in a net zero world.
Piclo has found ‘product-to-market’ fit in the UK, with a number of enterprise-level customers using the platform alongside a new generation of asset owners. We are also increasingly seeing demand from interested utilities across Europe and beyond. Many prospective customers expressed a strong preference for our online marketplace to be available to users in their local language and, whilst the vast majority of the platform would be globally consistent, some essential elements of localisation would be needed.
Internationalisation vs Localisation
But what do we mean when talking about ‘internationalising’ and ‘localising’ a software product?
Definitions vary depending on what you read but generally we interpreted internationalising to mean getting the base platform in a state that meant it could elegantly extend itself to work well for different customers around the world. Localisation, by contrast, sits “on top” of internationalisation, where locale-specific changes can be made - e.g. displaying translations or expressing currency units differently depending on where the user is. In other words, internationalisation was the general plumbing or tooling in our tech stack that would get us ready to scale; localisation would be everything the user would see that makes the platform “right for me in my location”.
When we first thought about how to evolve the product so it was not solely for English speakers in the UK we immediately thought of translations, but we quickly realised there'd be other types of localisation involved. For example:
- Our interactive map was ‘fixed’ on the UK, meaning it would be suboptimal for users in other countries to find relevant information.
- Alongside coordinates, we utilised UK postcodes for location approximations
- Monetary values were hardcoded to be expressed in £ sterling and punctuation marks between major and minor currency units (like ‘£10.00’) were UK-specific and didn’t work well for some European markets
- Terms were UK-specific, like ‘Flex Asset’, which didn’t always have the same meaning elsewhere
So, to launch our product internationally, we knew we wanted to optimise the experience so the user would feel like the platform had been designed for them and their location.
Getting started
To tackle this challenge, we first heard from the Production team (devs, QAs, designers, and product managers) about their internationalisation experience from other businesses. Nightmare stories and good practice came out in the discussion, along with a recommendation that we carry out a proof of concept with an internationalisation module of a front-end open-source framework we were already using. Nuxt’s module was selected, which would act as part of our plumbing, getting our platform fit-for-purpose for internationalisation. Specifically, implementing it would mean:
- Our code could be elegantly, repeatedly and explicitly written to handle different experiences for different users. Without this, it would be easy to produce poor-quality, spaghetti code that wasn’t very maintainable or functional
- It has a huge library of knowing how to express different conventions per locale. For example, with this tool, we didn’t need to know that European users would prefer to see 31/1/22 while USA users would prefer 1/31/22 - by implementing the time-convention feature, and defining what a user’s locale was, the tooling would serve up a date format appropriate to them
- It had a built-in language toggle tool, so users could choose their preferred language
- Some other features like Search Engine Optimisation to make it more likely a user in one locale would see results relevant to their locale (eg locale-specific help articles)
Selecting a translation tool
But this plumbing still left us with the need to find a translator. While free tools like Google Translate have come on leaps and bounds over the years, they usually contain frequent grammatical and translation errors. Add to the mix the amount of energy jargon inherent in our product, we knew we needed a translation specialist.
Initially, we thought about hiring an in-house translator, but that wasn’t the most resilient model (what happens when they’re on holiday, or ill, or move on; what happens if there weren't translations needed for a couple of months?). Additionally, past experience of working on products being internationalised steered us away from a manual, error-prone process. In particular, prior experience suggested avoiding a process of uploading terms to a translation tool, waiting a few days for translations and then passing them to a developer to enter into the code base.
As a result, we set about finding an agency or platform that would suit our needs, and quickly heard about a solution from a colleague who’d posted a shout-out on LinkedIn asking for recommendations. We selected a company that:
- Met the efficiency goal by being developer-focussed. Our developers could reformat our codebase to make it translation-ready. Their tool would then detect missing translation phrases, and run a process where the English term would be pushed to their system, and return a translation, and that be inserted into the code and deployed using the same CI/CD process as we usually run. No manual back and forth.
- This code reformatting and process was future-proofed, meaning it was extensible to other languages
- The quality and speed of translations were high
Delivering on translation
To translate Piclo Flex into the new language, we programmatically produced a list of all webpages we had, along with automated emails, which identified a total of 67 artefacts to translate. We initially thought of a divide and conquer strategy that would see different teams translating the product content they were responsible for. However, as the process was content- and domain-agnostic, and my team were responsible for putting in place the tooling for internationalisation, we decided that the tooling team would go as far as updating the existing product content, while other teams would need to translate new content moving forward.
To meet some challenging contractual deadlines and deliver a product fit for local use, our tactic initially was to go broad on coverage; in other words, get 80% of the ‘easy’ translations done per page and move on to the next easy 80% on the following pages. This would mean we could progress through more content more quickly. It also made sense to us as not all text is equal, while text like call-to-action buttons and page headings are highly visible, fairly obscure conditional error messaging like “keep responses to less than 100 characters” were rarely displayed.
Beyond translation
The tools above didn’t cover all localisation requirements, however. For example, we needed to rely on using environment variables to define which country to centre the map on and what default language was displayed. We also chose not to address certain things in the short term, like not translating the URL address. It wasn’t plain sailing though. Our biggest challenges were:
- Differentiating between translation suppliers - without contacts providing their recommendations it was difficult to understand the different types of translation services offered, and how to avoid manual translation processes
- Under-estimating how much effort, content and complexity there’d be involved in getting items translated. For example, we discovered what text displayed on webpages came from both the front-end and what came from the back-end, which complicated how to push and pull the text to and from our translation tool.
- Finding our feet and discovering the new. We had very little precedent to go on, and new tools, processes and ways of working needed to be established, largely before we saw much output.
So what’s the overall result? We now support a global experience which is on par with the UK one, meaning new customers in geographies further afield can benefit from the platform as a solution to their own local flexibility needs. Already, we have launched an international partnership with Energijos Skirstymo Operatorius (ESO), Lithuania’s largest distribution system operator (DSO), to explore flexibility procurement in Lithuania, with many more announcements set to come in 2022!
If you’d like to find out more or to book a demo, please contact hello@piclo.energy.
