In order to better communicate with international clients, Software Publishers will look to translate and localise their applications into other languages. During this process, one of the first steps will be to approach a Language Service Provider (LSP) to evaluate project requirements, scope and cost.
Some Software Publishers show concern at outsourcing to an LSP, and will maintain a preference for on-premise localisation, using in-house translators.
The localisation industry has come a long way in terms of their technical capabilities, which allows them to be flexible when dealing with various systems and file formats. Let’s explore the pros and cons of each approach.
On-premise Software Localisation:
- Visibility – Having an in-house linguist working alongside the rest of the team offers visibility and transparency to the process, and allows translation to be carried out within the vendor’s software environment.
- Agility – Although much more time-consuming, an on-premise localisation approach is more in-line with the ‘scrum’ method of software development. Having a linguist sat with the development team can be beneficial if on-going development is required.
- Personnel – The main challenge with this approach is sourcing suitable talent.
It’s not easy to find qualified and native linguists, with experience in localising software, located within a reasonable vicinity of your offices, who are also available purely for a short fixed-term placement.
- Costs – Significant additional costs can quickly rack up: as well as their daily rate, don’t forget about the linguist’s weekly travel, food and accommodation expenses.
- Security –Businesses need to be aware of the pitfalls online activity that can result from careless distribution of sensitive information. An in-house linguist is likely to carry out the translations on their local laptop, with files being sent via unencrypted email or USB drive. It’s harder to keep tabs on where your confidential data is going and how secure the connection is, especially important if you’re releasing software that you don’t want your competitors to get their hands on.
Remote Software Localisation:
- Quality – Any LSP worth its salt will offer translation by one linguist, and proofreading by a second, as a standard service – this second pair of eyes is not available with the in-house model, therefore quality is harder to monitor. The additional quality check from a second linguist is essential, in exactly the same way you would never dream of releasing a new English software update without testing it first.
- Personnel – In contrast to the previous approach, giving the LSP the freedom to work on exported language files offers an unlimited scope in terms of choice of linguists. This allows the LSP to select software localisation industry experts from their global network.
- CAT Tools – With the use of Computer Assisted Translation (CAT) tools, the linguist’s time is more focused and targeted. There will be no dead time spent learning how to navigate the system, or managing development issues. These tools will also leverage repeated text from within the software strings and most CAT tools will also provide added traceability features.
- Cost – All things considered, this approach will cost roughly half the price, as LSPs will have already established procedures and systems, not to mention a large database of linguists with a number of language pairs and specialised industry backgrounds.
- Visibility – Some Software Publishers may feel that on-premise localisation offers more transparency. This is the only real drawback with the ‘out of house’ approach. Comparatively, the client does not have the same level of visibility as the in-house model.
Although this luxury could be viewed as a major distinguisher, you will need twice the budget, twice the time, and ultimately, the linguistic quality will be compromised due to restricted linguist options.
- Security – Reputable LSPs will use secure, encrypted systems and strict ISO processes to handle the translation process and ensure that your data is secure at every stage.
It’s easy to understand why some buyers would initially opt for this first option; perhaps there is nervousness amongst some that a LSP would not grasp the technical content without constant supervision. As long as the LSP has access to screenshots, glossaries and style guides, and you have allowed time for language testing, this should never be a problem.