More Related Content


Global Audit

  1. Conducting a Global Audit Making your content global-ready. Leah Guren Cow TC © 2016 Leah Guren
  2. Agenda  The what and why of global audits  Best practices  Using the audit results  Conclusion and discussion
  3. The What and Why  First, some terms:  I18N = internationalization  L10N = localization  A global audit is reviewing content for:  potential I18N problems (content that is not appropriate for global release)  potential L10N problems (things that make translation difficult)  …and then developing:  your style guide (to be more global-ready)  your processes
  4. Why is it important?  We are in a global economy (I18N and L10N are mandatory).  Bad content means:  product rejection for I18N  more complicated, longer, costlier L10N  Tech Pubs should logically manage localization projects.  You can be the hero!
  5. A Case Study This is the DigiBelt (part of the DigiScan product). This is the DigiBelt insert. But for some bizarre historical reason, this is also the DigiBelt insert. IFU PDF
  6. This is a catheter. Oh, wait… it’s a probe. Or is it a sensor? Oh, &#*@#^!!
  7. Best Practices Conduct your global audit by focusing on these areas.
  8. Review the writing. Look for these problems:  Idiom, local expressions, slang, etc.  Long (> 13 words) babushka doll sentences.  One word, multiple meanings:  bad: Hose down the sidewalk with the hose.  better: Spray the sidewalk with the hose.  or: Use the hose to wash the sidewalk.  Inconsistency:  product names, features, interface elements  technical terms  verbs for all user actions
  9. Review global standards. Look for these problems:  No metric values.  Confusing time designations:  bad: AM or PM times with regional time zone  better: 24-hour time with UTC reference (18:00 UTC -3)  Confusing dates:  bad: number-only dates (08/05/16)  better: modified ISO date format (08 May 2016)  Unintentional lack of parity:  bad: Tony lives in Los Angeles, California, and Michelle lives in Paris, France.  better: Tony lives in Los Angeles, CA, USA, and Michelle lives in Paris, France.
  10. Review the examples. Look for these problems:  Use-case names that aren’t universally bland.  Culturally-specific examples:  local businesses  things only known in your area  Humor (it never translates well).
  11. Review the graphics. Look for these problems:  Hand icons:  gestures mean different things  cultural taboos vary  Metaphor icons (trash can, etc.).  Embedded (not linked) graphics.  Text in graphic, rather than separate layer.
  12. Review the tool usage. Look for these problems:  Local and illegal formatting:  screws up automation  requires manual fixes  leads to more sloppy errors  Messy source files:  extra tabs, soft returns, hard returns, extra spaces  manual page breaks  hard-coded variables  ASCII fonts instead of Unicode  Bad layout and design:  text “tweaked” to fit onto a page  tables or callouts designed for fixed sizes (no support for language bloat)  no thought for RTL (right-to-left) languages
  13. Using the Audit Results You did the audit. So now what?
  14. Fix the sources and the style guide.  Apply the changes.  Set a strategy for the future:  in-house style guide  training for other Help authors, content developers, editors, etc.
  15. Find a reputable L10N resource.  Get the right language!  there is no such thing as “French” or “Spanish”  mother-tongue for target, not source  Look for experience in your domain.  Make sure that they are tool-savvy.  Get references.  Give a short chapter or a few pages as a test.  Send the results to the client’s rep. Sie haben schöne Käse!
  16. Do usability testing.  Find users matching your target personas:  best: EFL  next best: ESL  Have them read and follow documentation:  can they read it?  do they understand it?  are they struggling?  are they confused?  First, learn the basics of documentation U-testing!
  17. Build in-house support.  Do your research:  what does your current localization cost?  how long does it take?  Identify stakeholders:  product managers  sales and marketing  developers  other technical authors  Find out what concerns them…
  18. They may not care about user benefits. The usability is terrible! I don’t care!
  19. They may not even care about money. You’re wasting money! I don’t care!!
  20. But they care about something!  The regulatory manager might care about compliance.  The product manager might care about TTM (time to market). I can shorten your TTM. Tell me more!!
  21. Start with a simple goal.  Try terminology and global notation.  Create a committee:  R&D  Regulatory  Marketing  TC  Created methodology to support it.  Give terms to L10N agency.  Test on one release.
  22. Lessons Learned  Obvious problems are not obvious to everyone.  Explain the pain based on the stakeholder’s POV.  Start small.  Have starting metrics to allow comparison.  Be prepared to be scrutinized.  Want more? The Global English Style Guide: Writing Clear, Translatable Documentation for a Global Market, John R. Kohl.
  23. Thank you! Leah Guren Cow TC technical communication training & consulting tel: (+972) 54-485-3473 email: website: A butter approach to TC…