I’ve spent the last few days at Tekom tcworld 2012, a technical communicators’ conference and trade fair in Wiesbaden, Germany. What a huge event! It was great seeing old friends and meeting new people. Thanks to the tcworld organisers for a successful, rewarding conference.
My introduction to the conference was the speakers’ orientation session hosted by Michael Fritz, executive director at tcworld and Tekom. Here are some statistics that Michael gave us about this year’s conference and trade fair:
- 2400 participants registered for the conference
- 1300 more people registered for the trade fair
- 158 lectures, of which 52 are in English (the others are in German)
- 49 workshops, of which 16 are in English
- 17 tutorials, of which 6 are in English
Yes, a huge event.
Notes from some sessions
I’ve blogged about most of the sessions I attended. I hope these posts are useful to people who couldn’t make it to the conference and to people who were there but couldn’t attend these sessions:
- Irreplaceable young professionals
- Translation interoperability
- Selecting a translation vendor
- QA for authoring and translation
- Engaging your readers via social media – this was my own presentation
- Liquid content
- Augmented reality
- The cosmopolitan information topic
- Meaning in technical communication
- Content strategy and mobile devices
- Content strategy connecting the dots
- Content strategy at Tekom tcworld
Atlassian and K15t Software at Tekom tcworld
There was a steady stream of people interested in Atlassian software, K15t’s software and services, and wiki-based documentation:
Before the conference started, I spent some time wandering around the sleepy spa town. There are more pictures on my travelling bookmark’s blog: Autumn in Wiesbaden, Germany.
Thanks to the organisers, delegates, exhibitors and speakers at Tekom tcworld 2012. It’s a great show!
The room was packed! This is obviously something many people are interested in.
Johannes is speaking without slides. Brave. He has just a few notes in one hand, a microphone in the other. He’s bathed in a gentle purple light from the overhead projector. He’s telling his life story with smiles and gestures.
I didn’t understand much of what Johannes said, but his passion and enthusiasm shone through. I heard him talking about vision, about thinking about technical documentation in different ways, about being open, and about making use of social media.
After the presentation, I chatted to another attendee who said that Johannes’s personality and enthusiasm were great. “He’ll never have a problem in making himself indispensable to a company, with such a personality,” said the attendee. Nice. 🙂
I’m at Tekom tcworld 2012, in Wiesbaden. These are my notes from a session by Arle Lommel titled, “Linport: A New Standard for Translation Interoperability”.
Arle published this blurb about the session:
In 2011 the Globalization and Localization Association, the European Commission Directorate General for Translation, and the Brigham Young University Translation Research Group began work on an open, standards-based container for translation projects. Known as the Linport Project, it has brought together language technology developers who have agreed to implement the resulting specification. Additional collaboration with the Interoperability Now! group is leading toward a joint specification that promises to overcome technical fragmentation that leads to inefficiency in translation processes. This presentation describes the Linport format and its use in a globalization production chain.
Note: Linport is not yet a standard. They are working towards its becoming a standard.
What is Linport?
Linport is the Language INteroperability PORTfolio.
At present Linport consists of two related zip-encoded formats:
- A portfolio for presenting translation projects.
- A package for representing individual tasks. Packages can ge generated from portfolios, and you can combine packages to create a portfolio.
Linport also contains standardised metadata which is very important in translation.
Linport is a format that can be applied to various types of content, including different formats. It’s based on recognised open standards such as XML, XLIFF, TMX etc. It allows you to standardise, but doesn’t force that where it’s not possible.
It supports tasks such as translation, proof-reading, authoring.
The intention is that Linport be used at any point where you need to exchange data, such as between clients and translation vendors, and between translators and their employers. It allows all relevant resources to be sent together. It streamlines the transmission of data and reduces costs and confusion.
Arle summarised the aim of Linport: Simplified interchange.
Arle described the current processes in the translation industry: very manual, with people transferring data haphazardly. Individual small items are transferred, with a lot of manual routing and work. This adds costs, time, and potential for error.
As a result, only a small portion of time and cost in a translation project currently goes into the actual translation: approximately 30%. Translators themselves only spend about 50% of their time doing the actual translation. So, it’s possible that only about 15% of what you pay for translation goes into the actual translation.
The real cost savings therefore would come from speeding up processes. Eliminate the manual transactions.
Arle compared the goals to shipping containers. A very simple specification (dimensions, strength, and corner locking devices) yields a very powerful result.
Linport aims to be the “shipping container” for the translation and localisation community.
Specific features: structured translation specifications
A definition of quality:
A quality translation achieves needed accuracy and fluency, while meeting specifications that are appropriate to end-user needs.
Arle showed us the specific standards that Linport is based on. It’s designed to eliminate most points of confusion.
You can go to this URL to get the specs: www.ttt.org/specs
At the heart of Linport is the idea that, when running a translation project, we document everything up front, so that there is no possibility of confusion. For example, document the required target language. This seems obvious, but Arle has seen occasions where that is not given.
Areas of the specifications are:
- A: Linguistic. These define the requirements for the source content and the target content. For example, for the source: textual characteristics, specialised language, volume, complexity. On the target side, the target language, audience, purpose, file format, and so on.
- B: Production. Is it OK to use machine translation. Translation memory.
- C. Environment. Special workplace requirements, such as secure facility. Technology. Reference materials.
- D. Relationships. Payment, copyright, communication.
Linport provides STS files: Structured Translation Specifications. These are standardised formats as XML files. The assumption is that people will use templates to supply the information.
Arle gave us a demo of an open source tool under development in the Linport project, to make the formats accessible to people. The tool presents a form for you to complete, supplying the data required for the specifications.
Another function allows you to create a TIPP file, which is the one that goes out to be translated. You can choose the format, from some known standards. A TIPP file is a zip file, containing:
- a manifest,
- the source text to be translated,
- and the structured specifications.
The TIPP file can be more complex, for example including the translation memory.
The team is finalising the structural details. They hold monthly conference calls, mainly to resolve minor details. Arle feels that they are approaching a stable specification (not available yet).
They’re working on early implementation, and already seeing early adoption. Some organisations are in beta stages of the implementation. Linport is working to gain implementation commitments, and some organisations are close to giving those commitments.
The team are building the online Linport tools, which will be open source. All the documentation and tools will be available free of charge. See the demo and URL above.
They’re also moving towards testing with real data in larger volumes.
The team is working towards finalising all the small details of formatting. When they reach consensus, they want to submit Linport to a standards body: ETSI or OASIS.
They also plan to improve the Linport apps, making them more user friendly. They also want to implement Linport in more tools and in more DGT production tasks.
You can go to linport.org for details about getting involved.
I’m at Tekom tcworld 2012, in Wiesbaden. This morning I’m attending a session called “Considerations in Translation Vendor Selection”, by Bernard Aschwanden. This is a topic close to my heart, as I’m keen to start planning for the translation of our own documentation.
Here is the blurb that Bernard published for his session:
When a company identifies a need for documentation to be translated into new languages for both existing customers and new customers it is important to ensure you choose the right translation vendor. In doing so, it is necessary to identify options (with associated costs and risks) for meeting current demands, processes for handling future translation requests, and a big-picture strategy for documentation translation needs across product lines and worldwide needs. Learn about key considerations in vendor selection, and identify the factors that matter most to a successful partnership.
Bernard joined us via a remote connection. He became sick just before the conference began, so he recorded his presentation, and joined us via Skype to answer questions. What’s more it was 4 a.m. for him, so kudos that he was able to string a coherent sentence together!
Role of a translation vendor
The role of the vendor is to be a partner, working with you to identify your needs and manage people and processes. They should help with localisation as well as translation. Localisation means making the images and concepts and ideas understandable to a local audience.
The vendor should always provide you with the translation memory. If they don’t provide it, don’t use the vendor.
Should you translate yourself or outsource?
Some things to consider:
- Are you comfortable with sending your content outside?
- Are you happy with the changes in processes that will be required.
- Associated costs, both short and long term.
Make sure you identify everyone who is involved: Reviewers, authors, translators, managers, outside vendors, your clients… the list is long.
Ways to get started
- Talk to people at conferences and make other uses of word of mouth.
- Join interest groups.
- Read industry articles.
- Do web searches.
Then narrow down your options, by Googling the vendors, checking their websites, sending them an email.
Make sure you have a good list of questions to ask potential vendors, based on what’s important to you.
Start building relationships with a short list of vendors. Schedule a demo, set up in-person meetings. Ask them to walk you through the process. Then discuss the results with your team.
These are some initial questions to ask the vendor:
- Does the company outsource its work, and to whom?
- What languages do they manage, and which are their specialities?
- What industry do they specialise in?
- Do they have a recent client list and references.
- What is the rate of turnover for the translators?
- What is their industry ranking?
Bernard then took us through a number of more specific questions. If you’re intending to take this further, it’s worth getting the list of useful questions to investigate. The questions revolved around fees, technology and tools, managing of the translators, workflow, and more.
It’s important to note how responsive the vendor is to your questions, and what your overall impression is of the organisation.
Getting a sample translated
Send the vendor a sample and ask them to do a translation. Make sure the sample is realistic.
Do a workflow model. Assess the result, and show it to the stakeholders who will use it.
Have a systematic way of scoring and comparing the results of the chosen vendors.
It’s important to identify the total costs. Make sure you specify which parts of the job you will do in-house and which parts you will outsource.
Find out about these costs:
- Per word.
- Total engineering effort to set up the system.
- Editing and proofing.
- Project management.
- Layout, graphics, tables.
- Review of the material.
You can save on costs by:
- Content re-use.
- Translation memory. Words that are matched one-to-one will need reviewing, but not full service. Make sure you own the translation memory.
- Using just one firm. You may get a discount for doing all languages with one vendor.
- Doing some of the tasks in house. For example, in-house review by a subject matter expert, or layout.
Bernard closed with some points to note:
- Know what you need. Go in prepared. Be up front about what you need, so that the vendor knows everything they need to know.
- Build trust, on both sides.
- Get the credentials of the vendor. Check their online presences, also on Facebook and Twitter. This will give an idea of how professional they are and what image they are putting out for people to see.
- Find out all of the costs.
- Don’t let the vendor use you as a test case.
- Make sure the vendor has experience in the industry you work in.
- Understand their quality processes, and make sure you know how they handle verification.
At the end, there was plenty of animated discussion from the floor. Audience members included translators, translation vendors, and people interested in hiring a vendor. This is a topic dear to many people’s hearts!