Browsing Tag


getting started in tech comm, global communication, localization, Uncategorized

5 Things You Need to Know about Global-Ready Content, Part 2

September 24, 2014

Earlier this week, in Part 1, I shared the first two things you need to know about global-ready content. Here are the other three.

3. Manage Change

One of the biggest reasons for content strategies and content management systems to fail is poor change management, both the human kind and the technical kind. 

You can have the best technology and the most user-friendly system in the world, and it won’t matter one iota if you are having team issues that prevent you from maximizing the benefit. If you are asking people to significantly change the way that they approach their work, you need to prepare them properly, give them training and support, and reward the new behaviors that you want to see.

On the technical side, if you are not being proactive about your change management, you are costing your company money. Making changes to source content while it is being localized costs the company money and time, especially if the change is not vital. (Yes, I know everyone thinks their changes have to be done right now, but they are wrong.)

4. Watch Your Language!

English is a difficult and confusing language, even for native speakers.  Homonyms and false friends abound, the grammar is inconsistent, and often has more exceptions than rules…and then there’s the fact that “English doesn’t just borrow from other languages, it drags them down dark alleys, knocks them over the head and rifles their pocket for loose grammar and vocabulary.” (from a t-shirt I saw at a gaming con).

According to Global Language Monitor, there are ~1,025,109 words in the English language as of 1 January 2014 (up from 1,009,753 in 2011). This statistic includes all words (jargon, idioms, variations of a word, neologisms, etc.).

The reality is that most dictionaries contain about 200,000-250,000 English words that are used most commonly. The unabridged Oxford English dictionary contains about 650,000 words.

When you consider that most other languages have fewer than 500,000 words, this difference has significant implications for how we write for localization, for terminology management, and is a strong argument for controlled language initiatives like Simplified Technical English. It is also one of the reasons for text expansion.

5. Be Excellent

Last, but certainly not least, do your best and produce excellent work in everything that you do, no matter how small.

Localization is a garbage in/garbage out process. If you have crappy source content, you are going to have crappy localized content and those issues will increase your costs, increase liability, and decrease usability and customer satisfaction. Make sure your source content is as error-free and high quality as possible with the project constraints. And, this is where an effective QA process comes in as well.

If you are in the habit of excellence and you have good QA processes, you will improve your chances of quality localized content.


getting started in tech comm, global communication, localization

5 Things You Need to Know about Global-Ready Content, Part 1

September 22, 2014

A couple of weeks ago, I spoke to one of Dr. Pam Brewer’s classes at Mercer University via web cam. We had a great conversation about global-ready content and why it’s important. Here’s a summary of what I told them:

Global-Ready Content Defined

Global-Ready content means applying technical communication best practices stringently and consistently. Localization adds a layer of complexity to your content development process. In the traditional process, 50% or more of your localization costs are associated with DTP. And, anything you do to help alleviate these costs also helps the audience of your source English content.

Global-ready content has these characteristics:

  • Active
  • Consistent
  • Culturally neutral
  • Simple
  • Structured
  • Well-written and well-edited

1. Plan for the Future

Always design with the world in mind, even if you aren’t yet translating your content. It’s a lot easier to design it right in the first place than it is to retrofit it. If your company has a website, it’s potentially a global company.

Content Strategy

The Language of Content Strategy defines it as, “The analysis and planning required to develop a repeatable system that governs the management of content throughout the content lifecycle.” What this means is that you have to look at your content holistically, and that includes localization. Your strategy and architecture should support and facilitate localization.

Information Architecture and Design

The Language of Content Strategy defines it as, “The art and science of structuring content to support findability and usability.”  The information architecture is the technical side of the content strategy. It is what allows you to actually implement your strategy effectively.

If you only remember one thing, make it this: Design with the world in mind. That means making sure that all your structures, processes, models, etc. all support and facilitate both source content development and localization (and I’m including visual content in this…)

2. Build a Solid Structure

Build a solid structure/architecture, one that won’t collapse under its own weight or get blown away with the first problem that arises. Make it flexible and scalable.


Think about how your workflow supports these things:

  • Multiple users
  • Status tracking
  • Version control
  • Multiple output formats
  • Process efficiency
  • Localization
  • Content chunking
Shows the Author-IT CMS workflow at high-level. Multiple authors contribute to database and then output content in multiple formats

Courtesy of Author-IT Software Corporation

Content Modeling

Creating content ‘chunks’/components/modules allows you to send only the untranslated content to the vendor, which saves 10% or more of your localization costs because vendors charge you even for 100% matches. This charge is because the human translator has to do context verification. Sending only new or modified content eliminates this.

Reuse facilitates consistency. Instead of rewriting a note, caution, or warning every time it’s needed, you write once and reuse. Same thing with graphics, tables, regulatory information, and other content that’s used in multiple places. It bears mention, however, that consistency doesn’t equal quality. You also need to also spend time internationalizing the content to ensure that it is clear, concise, and accurate. But, that’s a whole other discussion.

Shows the text, graphics, and tables as separate content chunks that can be re-combined in multiple ways for different output formats

Courtesy of Author-IT Software Corporation

Structured Authoring for Intelligent Content

Once you have identified how to properly chunk your content, you need to structure it well so that it can be more intelligent. The structure of your XML needs to facilitate flexibility and scalability, as well as support localization. Yves Savourel’s book, XML Internationalization and Localization is a deep dive into the technical aspects of structuring your content for localization.

Good Metadata

Metadata is the key to happiness in a content management environment. It’s what allows you to find, manage, and use your content. When you add localization, suddenly you need to think about which metadata needs to be translated and how you are going to expose it to the translators.

Make this the 2nd thing you remember: Hard-coded strings are bad. Metadata needs to stored in such a way that you can easily identify and extract the strings that need to be localized.

Stay tuned for Part 2, where I will share items 3-5 on the list of 5 things you need to know about global-ready content.



localization, Vendor Management

11 Things You Didn’t Know About Your Localization Vendor

March 6, 2014

Day 5 of the 31-Day Blogging Challenge #31dbc

I work with a lot of clients who are just getting started in localization. To many of them, localization is a black hole into which they pour their source content, then magic occurs and Presto! out comes a language product.

Let’s take a peek inside the box:

  1. The pool of translators is finite and the vendors all fish from the same pool. Most translators work freelance for several localization vendors, and the good ones are in high demand. Vendors hire translators for jobs based on language combination and industry expertise.
  2. A couple of large localization companies make most of the tools used in the localization industry. This means that many vendors are competing for work with the vendors that also create the tools that the industry depends on. Naturally, this doesn’t always sit well, and many vendors are looking for ways to reduce this dependency.
  3. Process and customer service matter more than cost per word. See #1 above. Working with a localization vendor is a long-term relationship. Focusing on cost/word is the wrong way to look at things, particularly if quality is important. Look at the value-added services the vendor provides, how they treat you as a customer, and how they treat their employees and contractors.
  4. For most customers, the mid-sized localization vendors will be the best fit. Unless you are a Fortune 500 company, the mid-sized vendors will generally be a better fit for you. They are small enough to be hungry for your business and big enough to scale with you. The big boys in the localization industry focus on enterprise level projects (large volumes, many languages, complex designs). The single language vendors can’t scale with you.
  5. When you fail to pay on time, a translator might go hungry. Localization is a people-intensive process, even with support of translation memory and machine translation. Many vendors have difficulty paying their translators and other contractors on time if they have big customers who don’t pay them on time. While 60 days isn’t a long turnaround for a big public company or one that is well-funded, that time frame causes major cash flow issues for a small sole proprietor (aka most translators). Be a good customer and pay on time (If you pay net 30, your vendors will love you).
  6. Pushing your source content drop date without pushing the product release schedule significantly affects the quality of your language product and increases your costs. Localization takes about 80% of the time that the initial content development takes, so expecting 50,000 words in 30 languages in 2 weeks is really unrealistic and undoable with any sort of quality. Consistently abusing your vendor will result in lower quality, significantly increase your costs, and potentially, will get you fired by the vendor. Fixing your upstream processes for product and content development, having good QA, editing, and change management processes helps to prevent this issue.
  7. DTP/engineering is ~50% of your localization costs if you are using traditional content publishing methods. First, the content gets pulled into the translation memory tool, where the translators do their thing. Then, the translated content gets put back into the final output format via desktop publishing (DTP) or web/help engineering. If you are not using XML and XSLTs, reformatting is a manual process that must be done separately for every language. Template problems, content issues, graphics issues grow exponentially with the number of languages. If you have 10 errors in the English and are translating into 30 languages, suddenly you have 300 errors that are likely to get perpetuated.
  8. Your in-country reviewers cause some of the biggest headaches for the localization vendor and increase your costs. In-country reviewers are typically subject matter experts (SMEs) who have product knowledge and fluency in both the source and target language. However, if you do not train the reviewers properly, or if you do not make the language review part of their job responsibilities, they can completely bollox up the process with preferential/spurious changes, delayed responses, and so on. Create effective review processes and train your people! If you have a relatively large volume, t’s a good idea to have a localization manager who can vet the comments before passing them on to the vendor.
  9. You, the client, own your translation memory files. Just like you might hire a contractor to develop the source content, you are hiring the localization vendor to create the language product. In both cases, this is considered “work for hire”. You own the copyright (after you’ve paid your bill, of course).
  10. Lack of re-use and poor terminology management are costing you big money. If you aren’t reusing your content and managing your terminology, you are paying multiple times for translation of the same content. If you think you don’t have re-use, think again. Notes, cautions, warnings, product specifications, warranty, trademark, and copyright information, UI field names, glossary terms, etc. get used in multiple places in your content. In the translation memory, the translator must review every fuzzy match to make sure that it is contextually correct, so randomly changing the wording of a sentence requires it to be re-translated.
  11. Your localization vendor has a list of issues with your content, but they might not have shared it with you. If you have done a couple of projects with the same vendor, they will likely know what the issues are with your templates and content. Unless you have a mechanism (e.g., bug/change tracking database) for sharing that information with your content development team, the feedback loop isn’t being closed and the mistakes are being promulgated with every language and iteration. Ask your vendor for the information. If your team needs training on creating global-ready content, make sure that they get it. It will save you big money in the long-term.

There are, of course, many other things that you need to know when you are localizing your content. But, being aware of these things and fixing issues in the source will get you a long way toward improving your quality and global customer satisfaction.