SalfTrans WebSite (available soon)
RSS feed for our Oversetter blog
There are plenty of networking conferences to get involved with. Here is a quick overview of some forthcoming events:
BP 2017 translation conference
4th - 6th May 2017, Budapest, Hungary - Our Managing Director Nick Rosenthal is one of the speakers!
UA Europe 2017
Annual conference for technical communicators that focuses on software user assistance and online Help
Harrogate, England: 8th - 9th June 2017
The SalfTrans 25th Anniversary Conference
A translators' guide to the EC Machinery Directive 2006/42/EC
Stockport, England: 10th December 2013
Some useful links for you.
The purpose of this white paper is to describe a workflow for taking a product or application in one language, and having the full set of material translated into one or more other languages so that you can sell it in a foreign market.
When our clients are looking to translate their application into other languages, we usually find that a typical software application and supporting material consists of the following components:
Now let's take a more detailed look at our proposed localisation workflow.
Once upon a time, having your software localised meant handing over your source files to the translation company. These days, with modern localisation tools such as Passolo or Alchemy Catalyst, savvy translation companies that specialise in localisation have the skills, tools and know-how that enable them to work from a compiled build. So you don't need to release your source code. You just give us dll's or exe's, and we use our expertise and our specialist localisation tools to localise the user interface. This involved translating all the strings that appear in menus, on dialog boxes, and in any other user-facing context. But we don't just translate the words. We translate them in a manner that is appropriate for the context (and one of the benefits of modern localisation tools is that our linguists see all strings in context). And we can make sure that the translated text fits in the available space, carefully and appropriately resizing control elements if we need to (and there may well be times when that is necessary. For example, the English Undo command translates into Dutch as Ongedaan maken, up from 4 characters to 14 characters). And we then hand back to you a compiled build in the required language, ready for you to ship.
The logic of the workflow outlined in this white paper is valid whether you are developing your applications in Visual C++, in a .Net environment, or using XLIFF. The essential thing is to get the core terminology in the application's user interface translated and approved, and then (and only then) to move on to translating the help system, manuals and any other documentation.
The output from your installer is the first thing that your user will see when they install your software, so it is vital that this makes a good impression. We will work with you to ensure that you have an appropriate solution for your company's needs, whether that is a set of localised strings saying "click here to install the software" visible in all languages, or a fully localised single-language welcome screen if you ship different CDs to different markets.
Many user manuals and help systems use screen clips to illustrate a point. If you have your software translated into a different language, you will need to create the same set of screen images in each language that you have your application translated into. Best practice here is to store the screen images as externally referenced files, and to use exactly the same file names (stored in different folders) for each target language. That way, by using different folders for each language, your localised help system or translated manual will be able to pull in the translated files without imposing an additional time or cost overhead.
For some applications, you may need to have the screen grabs captured on a computer running a foreign-language version of the OS (for example, you may need to run the Italian version of Windows XP or Vista), so that all control elements are consistently in the target language in your screen images.
When translating the help system and the user guides, consistency is vitally important. You want to be absolutely certain that what it says in the French manual exactly matches what your French user sees on his or her screen.
To ensure this consistency, we take all the user interface strings that we translated when we localised your software application, and put them into a tool called a translation memory. We use several translation memory systems, as they each have different strengths. The main translation memory tools that we use are Trados TagEditor, MemoQ, and Déjà Vu, but this is a fast-changing market and our technical experts are constantly evaluating new tools. Because translation memories work at sentence level, we also import the user interface strings into a bilingual glossary, which will proactively support our translators as they work. Which in turn means greater consistency.
As another aid to consistency, we recommend localising the software application and doing a QA phase once the software itself has been localised, before you take the screen captures and start translating the documentation. That enables any feedback to be taken into account without causing rework overheads. If you are relying on your local office or in-country distributor to give feedback on how they want the localised software product to read, that is a good point to get their input. That way, you can lock down the software localisation before taking the localised screen clips, and before the help system and user manuals are translated. So any minor stylistic changes that your German office or Dutch distributor request can be easily and cost-effectively incorporated.
For a lot of our clients, it is important to have the translated manuals match the original version of the manual on a page-for-page basis. For example, if your support team need to be able to say "You'll find that information on page 68 of the user guide", then this is an important consideration. We're happy to advise on design and layout considerations that can help reduce the overhead of any final DTP phase in each language.