Many of our customers include software applications as part of their product offering. The translation of software projects does not have to be tricky or overly complicated.

Some of the critical steps in the translation of documentation are similar to the steps in software translation.

You will often hear software projects referred to as UI, which is short for User Interface, and sometimes also called software stings. These all refer to the same thing – the actual on-screen text a user sees while using the client’s desktop product, web-based software, or mobile application.

Having a robust process for software translation is essential. Our project manager kicks off UI projects by making sure we have a complete software list for translation and understanding the following points:

Is this a completely new build, or are there existing strings?

If there are existing strings, we will build a termbase and translation memory to make sure we are consistent with the previous release.

Benefit: We need to understand this point so that we can determine if we can leverage your previous release of the software. If you did the project with us, the content would be in the translation memory; if not, we would build a translation memory from your previous project. This step saves you time and money.

Are there any length limitations on the strings (number of characters per string)?

If so, we can map those requirements in our projects by placing hard limits on strings in our translation management system. We can also pseudo-translate the content with an expansion factor to see how the build might work out after translation. Please keep in mind that most languages expand in translation, so allow room for growth of the strings during translation. Setting the requirements at the exact length of the English or source is a mistake and will lead to severely truncated and poorly abbreviated strings.

Benefit: Blindly translating software strings without understanding any length limitations will cause issues in the long run. Your engineering hours are expensive. Anything we can do to minimize rework and make the first pass of translation as perfect as possible will save you money and get your product to market faster.

Will we have the ability to validate the software after translation?

It is a good idea to have our editors review the final translated software in context just as your users will end up seeing the software. This functional review pass is a critical quality assurance step and is optional, but do yourself a favor and don’t skip it!

Benefit: Reviewing the final product as your user is of the utmost importance! Skipping the functional review could lead to string overwrites, poor line breaks, and misunderstandings due to a lack of context when translating the strings in code. Help your language service provider spare you the embarrassment and reduce the rework of making adjustments and bug fixes after the release of your software.

What file format do you use for the source files?

Establishing the file format for the software strings is essential. Most clients will provide the following file types:

  • Java properties
  • .PO
  • .NET resources
    • .resx, .exe, .dll, .txt
  • HTML
  • XML
  • Excel-based exports

As mentioned, in a previous point, we can pseudo-translate and complete a round trip of the translation process for testing purposes. That means that we would put test translations into the file and send the files back to the customer so they can test the effectiveness of the process before we begin live translation.

Benefit: This test run reduce rework and also help to pin down any potential pitfalls in the translation process.

Will you be handling the software portion of the project before the documentation?

The best practice for the order of operations on software translation and the translation of the accompanying documentation is to handle the software first. This recommendation will allow your language service provider to build a termbase from the completed and approved strings so that, during the translation of the documentation, all software references will be referenced the same way as in the actual software.

Benefit: Translating the materials in the proper order will make your customers happy and create a good base for your translation memory for future projects. Plus, nobody likes to read a user’s manual where the software references don’t match what is on screen. Do all of your users a favor and make sure to translate the software strings first and the documentation second.

Interested in getting a software translation project started? Give us a shout and we’ll be happy to show you how easy the process can be.

Share This