Learn how to get your content ready for the world!

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: leah@cowtc.com
website: www.cowtc.com
A butter
approach to
TC…