Journey from LSP to RLV: Steps and Considerations
The path from LSP to RLV almost always starts when an existing, or even potential, client asks this unexpected question: "Do you support (xx) language?" or "Do you have resources to translate into (xx) language?"
Coming from a single language provider perspective, and being in your own language comfort zone, a typical answer to support a new language (even if it is spoken in the same region) would be "No."
For example, let's take Arabic and Kurdish. We used to receive questions about Arabic variation/dialects such as, "What is the difference between Arabic Saudi Arabia and Arabic Egypt?" These questions were not unheard of. But asking about new language support, like Kurdish, Farsi (as other Arabic script languages) or even an African language, was a surprise.
Being afraid to fail is often the driver for the "No" reply. However, if you keep receiving the same question repeatedly, replying "No" should not be the right answer for long.
Saying "Yes" however is not easy and you must be ready for it. Here are some challenges/ideas to think about before committing to the move from LSP to RLV:
- Language knowledge: it is not just where this language is spoken. A new language is a new language, even if it is spoken in your region. Kurdish for example is spoken in the Middle East. Yet, it is spoken in different countries and it is written with different scripts. Knowing the language characteristics/facts will help you support your client and ask the right questions.
- Skillset: having a skilled project manager to support multiple languages is a must. Adding a localization engineer (if you don’t already have one) will help streamline the process. You might even need to add different roles to your structure; e.g., resources coordination.
- Language capabilities: a skilled/native translation team is mandatory. Yet, finding/qualifying the right one is a major challenge. Conferences and LinkedIn are good means for finding good translation teams. To qualify them though, is a long process. You need to test them, pay attention to their experience, specialization and get ready for arbitration!
- Quality: quality criteria/issues may differ per language. Knowing the language facts will help you focus on what to spot. Use a referenced/acknowledged language specialist to help you define such criteria and for arbitration, when needed. Also, use automation to spot and eliminate major quality issues faster.
- Last but not least, tools: test the tools (Translation/Quality/DTP) to make sure they support your new language(s). If not, you might need to purchase new tools or maybe create/customize your own!
The first time we decided to support more languages was basically because one of our clients decided to support Farsi and Urdu in addition to Arabic. Being an Arabic localization vendor who handled all our client's BiDi localization requirements for a decade, it seemed natural to our client that we could support these other two BiDi languages when they asked. Before that, the "No" was our typical answer but letting down a client who depended on us did not seem right.
We started by listing all the fears/unknowns. The major obstacle was how to get the right resources and deliver with the same level of quality. At the beginning, we thought that having a strong project manager who could communicate with different types of resources and a good localization engineer was good enough to manage the whole thing.
Going through the project we realized we had to go through many changes in our "one language" process. For example:
- We had to hire a resource coordinator who could continuously find, test and help the project manager to allocate the right resources on time.
- We assigned a language specialist per language to set the expectation for the language criteria. Standardizing expectations/language specific checklist was helpful to align the language quality delivery.
- Having localization engineers from the beginning was helpful. Still, we lacked knowledge about locale defaults; e.g., fonts. Thus, collecting language/locale specific information was necessary.
By the time we delivered the project, the client was definitely happy that we were able to support them in their new requirements, and of course it was beneficial to us as well. Not only were we able to help this specific client, but also it opened up the door to helping many other clients.
To sum up, the journey may be long and definitely not an easy ride, but at the end of it there is a gain for the supplier and buyer.