It’s an unfortunate truth that most localisation projects are launched at the wrong time. All too often we see localisation done as an afterthought – too late and too rushed. To really give your localisation project the best chance of succeeding, you really need to start thinking about it as early as possible. Ideally, this should be as early as the design stage.
The worst possible time to start localisation is at the post-market entry stage. It’s really common to see digital projects being hastily retrofitted with localisation after they’ve already been presented to a local market (and aren’t faring as well as hoped). This is an example of a brand learning the hard way that localisation is really essential to the success of a digital product in a new market.
The second worst possible time to first start thinking about localisation is just before market entry when there really isn’t enough time to do things properly. Unfortunately, these deadline-driven localisation projects usually uncover a host of design-related restrictions that make it much harder to localise the content successfully within the timeframe.
If you leave localisation until after the design process is complete, you’ll encounter a lot of bugs when you eventually come to localise your content and realise your content management system (CMS) can’t handle the character sets, your font libraries are not supported or you need to recreate all your buttons as they are created as text within images.
Thinking about localisation at a much earlier design stage means that localisation can be implemented in a much smoother (and often cheaper) way when the time comes to enter a new market.
It helps prevent encountering bugs when you realise a digital project that’s built with just one language in mind can’t easily accommodate a different alphabet or text direction. Although it may seem to add complexities at the initial design stage, ultimately it saves a lot of headaches!
Start early
The challenge with approaching localisation after the design phase is that a digital project that’s designed with one language in mind may not translate easily into a new language. The design will run into problems when it needs to accommodate a language that reads in a different direction to the original language of design, or it needs to accommodate a language that has much longer words, for instance, German.
If there’s a lot of text within images, those images will all need to be recreated for the new language. Or preferably, remove the text altogether and use CSS to overlay plain text on top of a background image. If you really haven’t thought things through, your content platform may not even support your target languages.
If you don’t consider localisation as part of the design, all these practical challenges will need to be resolved before you can launch into new markets. This can be as disastrous as requiring you to completely rebuild your application.
What this means is you’re essentially designing your digital project twice, with all the costs and considerations needing to be repeated. This is why it’s so much more effective to avoid this by planning for localisation when you’re still making the initial design choices and testing different approaches with target-language text to ensure that it appears correctly and the application remains functional regardless of the language.
Pseudolocalisation of digital products
Pseudolocalisation is a technique that can help you prepare your web project for eventual localisation into different languages. Designers use machine translation to get a crude translation of the provisional content for the website and see whether the design will manage to accommodate various languages.
It’s a quick and simple way to assess whether the design can accommodate different languages, particularly ones that may eventually be targeted for localisation in the future. This exercise will uncover how tricky a future localisation project might be and whether the design or the technology it’s built on could be changed at this early stage to avoid future difficulties.
By using pseudolocalisation at the design stage, your team can hopefully avoid your future localisation project becoming a major redesign project. Although it complicates the design phase and initial project launch, it may save a great deal of cost and delay in future phases.
Pseudolocalisation at the design stage can help you avoid redesign complications during future localisation projects.
If you can avoid a situation where future language content can ever break the design, you won’t have as many costly bugs to fix. Over the product lifetime, this could lead to huge savings.
Perhaps one of the biggest challenges to design-phase localisation is getting the team to agree on the importance of including localisation considerations so early on. Most brands want to get the project launched with as little fuss as possible, as quickly as possible.
That’s even if it later causes headaches for them to resolve. Design-stage localisation also requires a higher level of collaboration between designers, developers and the product, content and translation teams. Getting all these players to agree on priorities can be tricky.
It’s important that the leadership remains focused on localisation in order to achieve this collaboration – later cost savings can be a key motivating factor for these decision-makers.
Getting the right tools
You need to choose the right tools and technology for your localisation-conscious design project. The good news is that there are tools available in the market to support your design project and future localisation plans. The bad news is that choosing the tools can be a big consideration for your team. Teams can be very attached to particular tools and technologies which may not be the best ones for a project that’s meant to factor in localisation.
With a localisation-first mindset, you’ll be more likely to choose a suite of tools and technologies that will eventually support a localised digital project.
If your team is doing software localisation for the first time, you will probably need to select and get used to new localisation tools such as translation management systems. You might want to consider a headless content management approach as this may help you manage localisation better by providing more flexibility in your themes.
Complex projects require high levels of collaboration. A typical design and localisation project will bring together teams from various disciplines and potentially from a number of different organisations.
If your project team includes people from outside your organisation, such as freelance translators and developers, then you’ll need to think about the practicalities of collaborating with them. You’ll need them to have the ability to share files and track versions between teams, for example. A dedicated messaging service such as Teams or Slack may be useful and issue tracking and ticketing software such as Jira will also be helpful.
It’s important to make sure that every member of the team knows their role and who the other people on the team are. One common problem is the lack of visibility of who are the decision-makers on other teams, which can slow down progress.
It’s also important to agree on who is responsible for which decisions, such as who is making key naming decisions on things such as hierarchical labels for menu items or subfolder names in URLs. A good tip for achieving milestones effectively is to agree who is responsible for decisions and for signing off project phases, and for trying to limit the number of decision-makers.
Another key factor for the success of your project is thinking about where assets are stored. Things such as source content, translated content and a glossary of terms need to be available to everyone involved with the project.
It’s also important that all players have access to the most up-to-date version of these assets. There are real pitfalls associated with storing assets in spreadsheets but it’s a common habit, particularly when teams are used to working in silos. S
Some teams are better at storing assets in the company intranet or digital asset management system but this also doesn’t always work when they’re collaborating with people outside the organisation. This is why many project teams choose to use software localisation tools that allow assets to be shared collaboratively.
Educating for collaboration
Any complex design and localisation project has 4 key groups of players. These are:
- Designers
- Developers and QA
- Managers, including product owners and project management
- The content and language translation team
Getting these teams to work together and avoid silos is a big part of achieving success at any stage of your project. They’ll all need to be encouraged to shift their focus away from established ways of working and possibly adopt new habits. This may include inducting people into Agile approaches such as parallel working and related ceremonies. They need to be convinced their interests align, and agree on an approach to working.
If you’re working effectively using an Agile approach, it may be very useful to have team-wide retrospectives on a regular basis to see how you can optimise your collaboration and address any problems.
Localisation-focused design projects require higher levels of interdisciplinary collaboration than many teams are used to. Getting the right practical tools and processes in place to support advanced real-time collaboration really is half the battle!
You’ll need to get everyone up to speed on how the team is expected to work together and make sure everyone is in the right mindset to collaborate. Your project won’t succeed if half the team refuses to use the same tools or can’t work in parallel.
Educating your team and getting both hearts and minds on the same track is a big part of the battle. Solutions include employing an Agile coach and having project kick-off meetings that really set the tone and expectations for ways of working.
Designing localisation-focused digital projects rely on building collaborative, localisation-focused teams.
A key success factor is how the project team identifies and tackles bottlenecks. If your project is struggling with bottlenecks it’s a good indication that you don’t have effective processes in place for working together.
It usually means people or teams are working too much in isolation and not communicating effectively with the person or team who is supposed to be responsible for the next phase in the workflow. Bottlenecks really slow things down and lead to frustration. You need to have an effective way to identify why bottlenecks are happening and resolve them before they become a real problem, for morale as well as for progress.
Reap the benefits
Localisation projects tend to have a reputation for being slow, laborious and complex. By implementing localisation into the design phase, you can really reduce the complications associated with the project over its lifespan.
Making the design phase that bit more comprehensive really helps reduce costs and issue numbers when it comes to the actual localisation of your digital project.
You might even be surprised how quickly the localisation process can be if it’s been planned for right from the start. Although localisation-focused design projects are slower early on, they inevitably save time and costs at a later stage of the product lifespan.
A big part of getting a design and localisation project right is getting the right tools and processes in place for teams to collaborate. These projects are really complex and the team needs to be well structured and briefed in order to work effectively.
Although things such as choosing the right localisation software are important, good leadership that’s focused on the task in hand and choosing the right localisation partner are vital components of success.
