Multilingual maturity in Scaling SaaS Businesses

Multilingual maturity in Scaling SaaS Businesses

For over a decade we’ve worked with some of the biggest names in SaaS and cloud computing. Over that time you get a pretty clear view of how organizations in this space evolve in terms of their international efforts, and how the most successful set themselves up.

It’s pretty rare to come across a founder or executive who doesn’t recognize that success in international markets is central to building a resilient and sustainable SaaS business over the long term. It’s even rarer to find one that’s been funded beyond Series A or B without a coherent international plan that’s good to go.

Which is why it can be useful to take a look at how different businesses evolve in terms of localization as they grow. Learning from others’ mistakes and successes, benchmarking against peers, and sharing best practise is a big part of succeeding in this space.

Based on our clients and experience, the table below will give you a feel for the most common path to multilingual maturity. There will be differences and cross-over between marketing and product — it’s entirely possible that you may have multilingual marketing content before your product is fully localized. In reverse, you may have a localized product due to customer demand, without having yet localized your key marketing assets.

Of course, it’s not meant to be prescriptive — just to give you a feel as to what the next step may be according to where you are now.

Where do you sit on the scale?

We tend to get most involved from stage 2 onwards, but in many cases we’ve been talking to the organization involved from stage 1. It’s never too early to plan ahead, and always a mistake to leave your localization planning until the last moment.

Talk to us today — there’s no obligation in having a chat, and we can probably help you avoid making the same mistakes we’ve seen founders with international ambitions make time and time again…

Taking your fintech global? Don’t forget the humans…

Taking your fintech global? Don’t forget the humans…

In March last year, Fintech stakeholders from every continent converged on the Guildhall in Central London for the Innovate Finance Global Summit.

The mood was upbeat, positive and collaborative. Even when London’s self-proclaimed status as the fintech capital of the world was challenged with the suggestion that New York or Berlin might lay claim the title, diplomacy won the day. That, and valuable insight from Singapore, India, and another 30 countries ensured that the global nature of the event was reflected in the debate.

The three the most prevalent themes from the summit were compliance, open APIs, and international expansion.

The eagle-eyed amongst you will notice that all three are intrinsically linked.

Delivering financial services in global markets requires a keen understanding of local regulations and rigorous governance procedures. Open APIs will help new fintech entrants access the crucial data they need to verify identity and deliver financial services to demographics and markets that currently have limited access to such products.

All these things can take place across borders, across continents, and across cultures.

In theory, at least.

The one thing missing is one of the most ancient elements of humanity — language.

OK, so a back-office system or blockchain transaction has a universal language all of its own. That’s all very well and needs little consideration beyond compatibility and data exchange (hey, back to APIs!), but what about the front-end?

Whether it’s a consumer using an app, an analyst crunching the numbers, or the IT guy in the office over the weekend trying-to-get-the-damned-API-configured— there’s usually a human in the mix somewhere down the line.

And that human relies on language. Their own language.

The IT guy needs documentation to understand what he’s configuring, the consumer needs to understand what the AI bot in the app is telling them to do next, and the analyst will rely on online help to generate the report they need for their next client meeting.

In an environment where fintech firms are looking to operate in multiple countries, effective communication comes down to local language and culture.

Which is where we come in.

With the fintech revolution comes a whole new set of technologies, a raft of new terminology, and an entirely different mindset from young, ambitious financial services providers.

It’s not just the traditional financial services industry that needs to adapt to this. Translators and software localization teams need to be able to adapt to this brave new world. They need to learn new technologies and embrace a new flexibility that many won’t have experienced before.

And just like legacy banking and insurance platforms that are deemed no longer fit for purpose, monolithic localization companies with their rigid processes and high employee churn will struggle to make the cultural investments necessary to meet the needs of this new reality.

So when you come to introduce your fintech offer to new markets, ask yourself one simple question:

Am I translating some text, or am I investing in the future international success of this business?

Thankfully, our clients are firmly of the latter view. If you’d like to talk to them about how we help them achieve it, give me a shout and I’ll put you in touch.

Terminology and why it should differentiate your company

Terminology and why it should differentiate your company

Depending on your industry and the languages you produce in, a terminology library can be a vital tool in creating a clear product understanding and acceptance in your target market.

The vast majority of our clients (I would guess at least 90%) see the appropriate translation of their industry and company-specific terms as one of the most important elements of every localisation project they undertake.

Apart from carefully tailoring the selection of translators to match the terminology needs of the job at hand, the best localisation providers will collaborate with their customers to produce comprehensive terminology guides and “termbases”.

termbase is a list of English and translated key terms that allows translators to establish a style and consistency to their translations, so localised content is smooth, flowing and follows a consistent pattern. Termbases also allow multiple translators to work simultaneously on large pieces of content as they can all access the same terminology resources from within the translation tool they use.

A good termbase is multi-layered and, by and large, could have some or all of the following influences:

  1. Language Dictionaries. For all major languages reference lists exist outlining the proper terms to use for common words and combinations. Termium Plus for example is the Canadian governments’ reference source to help translators with French Canadian translations.
  2. Broad Industry Standard Terms. Many companies might, for example, insist on using Microsoft terminology where applicable across all of their content. These terms are widely and easily available and are used by many companies across millions of pieces of content. The terms in these resources run into the tens of thousands.
  3. Industry Specific Terms. Each major industry often has a list of commonly used terms that can/should be used across content relating to that industry. For example in ERP terminology one could choose to use the SAP reference facilities to find translations for commonly used ERP terms.
  4. Company Specific Terms. Sometimes a company will have a particular meaning for a term that needs to be accurately reflected in their translated content. The translation reflects their unique position in the industry or their unique application of a term. The word “account” for example has a common translation in Italian (“conto”) which is not suitable for the purposes of Salesforce, a world leader in their field, who have chosen the English term to properly reflect the meaning of a sales account in Italian.
  5. Local Office Preferences. Occasionally local office experts determine the translations for certain terms. These choices can often be un-orthodox to established translators but it’s vital that this input is known and implemented in translated content.

A good termbase will have all of the detail required for the term. Not only is the source and target language term listed, but also the provenance of the term — where it occurs and what it means in the source language (usually English), the source of the translated term (industry glossary, government dictionary, pioneering company term, company specific term, local preference, etc…) and finally a comment qualifying the choice.

Any changes to the termbase need to be made only with the consultation of the vested parties in the content organisation which includes developers (on occasion), product management, localisation and the local office.

Whether we work with you or not we’re always happy to advise on terminology or any other localisation issue that you need a fresh perspective on. Call or email us with no obligation.

What do you know about the translators working on your stuff….?

What do you know about the translators working on your stuff….?

It’s a question that might not apply to you. You may know the translators working on your projects very well and go out for drinks with them every week.

But the chances are you don’t know them. Or you think you do, and the reality is very different.

So why is that the case, and why does it matter?

The reason you probably have no idea who your translators are is because of the way the industry works. Most (but not all) companies engage an agency to manage their localization and translation projects, or use an online service to co-ordinate and commission translators.

A few companies find and manage their own translators directly. They’ll know their translators well, but it’s time-consuming and only really feasible if you’re starting very small or if you have a business large enough to employ a team to manage them.

If you use an agency, they find and manage the translators for you. Translators are usually independent freelancers who work for many different employers.

Some agencies and the translators outsource and sub-contract work themselves if they’re busy, adding yet another layer to the supply chain.

Before you know it, you are two, three, or even four steps away from the people dealing with your most sensitive information.

That’s the first problem.

The second is how they’re paid. Badly, on the whole.

Everyone wants something for less. And fast-growing tech firms, with their caring, sharing, ethical values are no different in this regard. A large number of them want and expect cheap translations.

And if they get them, everyone suffers.

The translators at the bottom of the sub-contracting chain suffer, because everyone else has had a slice of the pie before them. They’re left with the scraps.

The agency suffers, because the only way they can win business is by offering cheap rates and providing low-quality translations. Their reputation suffers and they have to fight for work with the other 90% of low-quality providers in the industry.

Most of all, the tech firm buying the translations suffers. Because they’re the ones who are going to get really poor-quality translations. And those poor-quality translations end up in your UI, in your marketing material, and on your website.

Guess what? International users hate bad translations. They like their products to look, feel and function like they were created locally. A poor user experience leads to slow sales, excess churn, and dissatisfied investors.

So what’s the moral of this sad story?

Like many things in life, if you want quality you have to pay for it. That’s no bad thing as there’s a direct commercial benefit to you in paying a fair price for a good quality piece of work. On top of this you can be more confident that the translators behind the scenes are being paid fairly, managed carefully, and appropriately vetted before they get their hands on your content.

If cheap is your only option, wait until you have the traction, revenue, or investment to do it properly.

And if you won’t wait, don’t think you’re kidding anyone with your philanthropic CSR statement and bullshit startup ‘story’. Nobody’s buying it.

Customising Your Way To Localisation Success

Customising Your Way To Localisation Success

One of the challenges we face on a daily basis is our customers’ increasing need to get more details, facts and figures about their project assets, and to give them a better understanding of what can be done and by when. Source material is getting bigger and more complex, but sometimes the budgets (and the deadlines) are not expanding to match.

We’ve seen projects grow from medium sized projects which would invariably be completed in their entirety across all languages to much larger, multi-strand setups where certain elements are included and excluded across different language sets, often depending on target markets and available budgets.

Effectively what this means is that instead of just pointing a TM tool at a full set of files and producing a nice consistent analysis log across all languages, we are more often providing a “menu” of items which our customers can pick and choose from, depending on their requirements. And that is where customisation fits in — unless you can be flexible with your pre-translation processing, you end up with a one-size-fits-all solution which will not work in a lot of situations.

So what does customisation actually mean? It can mean a number of things actually — such as knowing which people to use and when for specific projects and tasks, dividing work effectively across people, using technology to share relevant information across teams (customers, translators and project management), utilising the best file handling and TM methodologies to achieve the highest possible leverage and even developing tools and systems to fine tune file-handling based on customer requirements.

Case in point — one of our regular projects has grown from a simple, flat structured help content type project into a multi-faceted, interactive, online training system with numerous format types, now split into modules and sub-modules, with different elements localised into different languages, often depending on market requirements and budgets. Initially all files were processed through the TM system and costed, and all translation work was carried out in all languages. Customising our processes and developing our own unique set of file manipulation tools has allowed us to grow with the project, ensuring we can meeting the increasingly complex demands of the project. Involving the right people at the right time means that as each new requirement is put in front of us, we can quickly address it and build it in to our overall project processes. In fact, as we get further into customising solutions for our clients, we often find that we are able to offer new approaches and ideas to them that they hadn’t even thought about, demonstrating that real customised solutions are more than just reactive patch-ups to get over a hump.

When planning your localisation project, it’s a useful exercise to think what it might look like in 6 or 12 months time. Localisation projects are becoming more fluid, larger and more complex, and it would be a prudent exercise to evaluate your localisation provider’s ability to handle changing project requirements as well as being able to handle the project as it currently stands.

What’s the best way to set up a software localization program?

What’s the best way to set up a software localization program?

Simple answer — there isn’t one. A generic ‘best way’ that is. Don’t trust anyone who tells you otherwise.

The key is not to seek out ‘the best way’, and instead to look at setting up a localization program that’s most suited to yourbusiness, your objectives, and your current growth stage.

I’ve spoken to a number of founders, CTOs and product owners in recent weeks who are at the stage where they have significant traction in their home market ($5+ million ARR) and are looking to specific overseas markets for the next ramp in growth. In most cases, this is driven by a specific opportunity or a notable take-up of their English-language product in a market where English isn’t the first language.

When localization is on the horizon, and it’s recognized that there’s a defined business benefit in doing it, it’s time to make some difficult decisions about how to actually achieve it. Many founders and CTOs have little first-hand experience of localization and even less time to get to grips with such a complex area. It’s easy to fall into the trap of seeing it as a pure translation process.

It’s true to say that text translation forms the bulk of the work, but to view a software localization project as simple translation of a few UI strings and help docs is setting yourself up for a whole heap of trouble.

Let’s look at some of the options you might consider:

Engage a freelance translator to carry out the linguistic work and integrate it into the product in-house.

That’s fine, but assumes a lot of things and comes with a lot of health warnings. Firstly, how do you know your translator is any good? Can they deal with terminology of your product and market? Do they have the technology at hand to make the translation process as efficient as possible, or are you going to pay extra for their inefficiency? There’s also the development time to consider — are you really going to tie your tech resources up extracting text, re-integrating it, bug-fixing etc, when they could be developing your core English-language product and responding to feature requests? Is this a good use of valuable developer time?

As far as visible costs go, this is a cheap (if not easy) route to take. However, the less-visible cost of tying resources up on non-core work shouldn’t be underestimated. It also comes with the highest risks in terms of quality, delays, and final user-acceptance.

Adopt a SaaS translation tool, or make use of a translation connector that integrates with your current technology stack.

This is a really appealing option for many SaaS businesses. After all, SaaS businesses use SaaS solutions, right? It can be a great solution if you have localization resources in-house who can manage the nuances of the program, or trusted translators who you simply want to equip with the technology to work more efficiently and integrate more tightly with your development environment. If you don’t have these, it can simply be an additional cost overhead with few advantages. Many translation tools quickly become walled gardens that can be difficult to escape from when your needs change, and where the translations you’ve paid for are shared amongst many clients.

That’s not to say SaaS translation tools don’t have a place. Just don’t let the shiny-suited salesman tell you it’s an easy and flexible way of localizing your software — in the wrong hands, it’s often not. In a hybrid environment, where you engage a trusted localization partner to integrate with your stack using a SaaS tool, it can be an excellent choice. At Iota we use a range of tools according to our customers’ preferences, and we’re always happy to recommend the best one for your circumstances. However, unless you have a mature and established internal localization team, we’d rarely recommend going it alone. Even then, there are very few global software giants who take this route exclusively.

Engage a proven localization company to manage end-to-end localization for you.

This is the method that is most likely to deliver the best results, without delays, and without additional internal resource requirements. But like most things worth doing, it doesn’t come cheap. A fully managed localization service represents a good investment — the initial cost will be high compared to the options above, but you’re far more likely to get a positive outcome.

Of course, this only applies if you choose your localization partner carefully. There are some cowboys out there. The best localization companies will tick the following boxes:

· Will take the time to understand your business and objectives, before building a program to meet your specific needs. They won’t force you into a way of working that disrupts your existing workflow.

· Will usually be able to work directly with your source files, whatever your development environment looks like. You won’t need to tie up resources extracting text, comparing to previous versions, re-integrating, or testing beyond your usual QA processes.

· Will have experienced localization engineers who will take your source files, prepare them for localization, quality check and bug-fix after localization, and return them to you in their original format ready for deployment.

· Will have access to an existing network of experienced and proven translators, based in-country and familiar with your customers’ industry.

· Will have tools to manage customer and industry-specific terminology effectively, and make use of translation memory to ensure you don’t pay for repetitive words and phrases to be translated from scratch time and time again.

· Will have a senior team of non-shiny-suited localization experts you can turn to at any time for help and advice.

To sum up, the ‘best’ way to set up your localization program will depend on your budget, experience, objectives, growth stage, and many other factors. We’re happy to talk if you’d like to explore what might be best for you — there’s no obligation and we won’t pressure you into taking a route that isn’t right for you.

Getting maximum benefit from your localised marketing content…

Getting maximum benefit from your localised marketing content…

Of all the types of material that we localise for companies, marketing content is perhaps the area that is most susceptible to “heated” discussion and ultimately, potential trouble.

It’s understandable really. The way your message comes across is almost as important as the product or service you’re marketing. Everyone wants to know and understand how the message comes across in Japan, say, relative to how it’s perceived at home.

Our customers take diverse approaches to their localised marketing content. On one end of the scale we have companies who want to keep a tight rein on what’s being said locally and want the message to be almost a literal translation of the source content. This can reduce their ability to be funky and “local” in their approach and it really can influence how their English content is phrased.

At the other end of the scale, some of our customers’ copy differs completely between their source content and the localised material. The localised message reflects the source message in general concept only, while the language, phraseology and tone are absolutely geared to the target market. Although all local marketing output is consistent in its core message, it often bears little or no resemblance to what is being said in sister markets — this is true ‘transcreation’.

The majority of our customers lie somewhere in between, as you might imagine.

The key to striking the right tone is to make sure that the people writing the original English copy and the teams responsible for marketing in the target country agree on the local objective. There needs to be a clear directive for localisers about how far they can, or how far you want them to, stray from the source message. Establishing the process and tone for local marketing needs to yield a consistent, repeatable output. Localisers will want to know they can trust the intention of the local office, to avoid constant rewriting, correction and confusion.

Cost can often determine the direction for localised marketing content. The closer the localised content is to the source content the lower the cost, typically. While the cost of a marketing translator will often be more than a regular translator, it is a still a relatively defined and predictable cost item, charged by the word. Once you cross over to “indigenous” message compilation and transcreation, where the localised text bears little resemblance to the source, you pay for creative development of marketing pieces, which is significantly harder to acquire and much more expensive — perhaps three or four times the cost.

If you’re about to embark on a local marketing campaign, bring the stakeholders together and agree on a common objective. Early buy-in will save you money and heartache in the longer term.

We’re here and happy to help in any way we can.

Where does pseudo-translation fit in to the localisation process?

Where does pseudo-translation fit in to the localisation process?

The holy grail of software development is predictability. No-one likes surprises, especially those that crop up just a few days before a major release is due. Delayed releases can have major commercial and financial implications as well as impacting on the reputation of your brand.

When it comes to software localisation it’s difficult to predict the impact of introducing a new translation without careful planning, testing, and QA at every stage. Iota use a number of tools and techniques to manage risk throughout the localisation process, an important one being pseudo-translation.

We use pseudo-translation frequently when customers localise new applications, or if major changes are made to an existing module or component of an application. It is very useful in highlighting internationalisation issues such as hard-coded strings, string size limitations, character display issues and functionality issues caused by over-translation.

Pseudo-translation is the process of mimicking the translation of resources and populating the strings with test characters. The resources can then be re-integrated into the application in the same manner as a proper translation, and then the application can be checked for internationalisation issues. The benefit of pseudo-translation is that it can be done quickly, rather than waiting for a ‘full’ language translation of the resources and only then seeing potential issues.

The tools we use allow us to specify the anticipated amount of string length growth, so we can pseudo-translate strings to a certain percentage longer than the source and check for sizing issues. We can use characters typical of the languages we are planning to translate into, using language dictionaries if required. This means we can see how the application handles double-byte, Cyrillic,and bidirectional text if those languages are target languages for the application.

Iota engineers can work with you to define a pseudo-translation plan to prepare your application for localisation. A little time spent up front doing this work can save a lot of time if issues are discovered further down the line with release dates looming.

We’re here if you need any advice. No obligation, no cost.

Where did your words end up? Do you know? Does it matter?

Where did your words end up? Do you know? Does it matter?

I am a member of an interesting group on LinkedIn, which largely relies on its input from translators who have a negative story to tell about the LSPs (Language Service Providers) they work for. Basically a story will start along the lines of “you won’t believe what XXX have asked me to do, and for how much….”.

Stories of jobs being offered to professional translators at as low as 3 or 4 cents per word are common. What strikes me when reading these posts is that the person or company who commissioned the work is usually unaware that this scramble is happening to get it done – at way below any decent translator’s minimum wage. I doubt that the original buyer is told that eventually her/his job will be shopped around for anyone who is desperate enough to take it. Often this comes from the original agency outsourcing to a sub agency and as we go down the line a slice is taken off the original fee per word for each handler, leaving very little for the person doing the job in the end.

Apart from the moral issues this brings up, it also raises the question of the quality you can expect from such a process. The sole criterion of getting stuff done at a ridiculously low price puts paid to any claim on a decent translation. You probably will get what you paid for…..even though you may have paid a lot more to begin with.

I have always recommended that buyers of translation and localisation services engage sufficiently with their vendors and partners to be aware of the path their files take. Where they will be translated and by whom are questions that must be asked and answered.

Iota uses exclusively in-country partners. Established translation companies we have worked with for years, who we know and trust. We have a path to the final translator. We know the source of our translated words. And they’re paid a fee that befits their profession and service.

Should instinct or data drive your localization decisions?

Should instinct or data drive your localization decisions?

Every technology organization and founder will have a different definition of success as they see it. Whatever your success metrics look like, there’s a good chance that the development of an international user-base will feature somewhere along the line.

For some, global expansion will be crucial to meet their projected revenues, and for others the decision to expand will be prompted by individual customer demand. Some started out with a wholly domestic focus, but then found that investors are generally more interested in funding businesses with a clear international strategy and a larger addressable market.

This makes sense of course — after all, why limit your potential? However, it does raise a lot of questions about the point at which an early-stage business should begin to scale internationally, and how they can do it intelligently — without burning cash for little return.

Aside from establishing infrastructure and recruiting staff in a new country, marketing and product localization are two of the biggest investments you’ll need to consider.

The decision to begin localization is made easier if there’s a deal on the table that will only close if the product is localized. Then it’s a relatively simple process of considering the prospective revenues versus the standard costs of accepting the deal. Where localization is a requirement, this can be factored in and applied wholly to that deal. However, it’s far more likely that a proportion of the localization cost will be charged to the first client, with the remainder being amortized across the rest of the addressable market in that region — hence kickstarting activity in a new location.

Of course, that’s overly simplistic. If your product includes a large volume of content that is unique to an individual customer, localization costs can’t always be apportioned across a wider customer base. There are also cases where the language(s) required for a specific deal are so niche that the wider market opportunity will be too small for the localization costs to be shared.

In cases like this, or where a strategic decision is made to localize and aggressively target a particular region or country prior to the first deal win, it’s important to assess what the wider language demand might be. No organization can afford to localize without doing their research first.

Instinct is usually best left to unicorn founders writing about their success with hindsight — for the majority, data-driven decisions will be the most effective path to growth.

So where can you look for early intelligence?

Web traffic — Are there any particular regions or countries where you see a significant amount of traffic coming from? If a country where English isn’t the first language is highly represented, this might suggest further research is warranted.

What does this group do when they hit the site? Do the number of page views and durations suggest they’re clicking away when they find their language is not covered?

What are your competitors doing? Where are they active, and which languages and regions do they localize for? Importantly, where are they not active — this might represent an opportunity.

What passive enquiries from shortlisted regions are you seeing? Are your SDRs actively researching and targeting prospective regions, or are you receiving passive enquiries and engagement via your website and social media?

Once your initial findings are validated, don’t forget to revisit the web stats to find out which content is most popular, which knowledgebase articles are most read, and which assets are most regularly downloaded. Aside from the core site content, these are the elements that you should consider localizing first from a marketing and support perspective.

Whilst we count many of the world’s largest SaaS, CRM, and analytics companies amongst our client base, we started working with many of them when they were in the early stages of international expansion. This means we’ve been alongside them from their earliest days of validating language requirements right through to the stage they’re at now where they are simultaneously shipping complex releases in multiple languages.

We can help you identify and validate these early localization decisions too. There’s no obligation — just get in touch and we’ll be happy to share our experience with you.