Tame Wild Writers with a Style Guide

A writer’s room without a style guide is like the wild west: cowboys making their own rules, lawlessness and grammatical errors, and gunfights at the OK corral. Alright, the last one might be a bit of a stretch, but the other points still stand. This article discusses how to bring law and order to your writer’s room through a codified manual of style. This process might not be easy, and you may have a few showdowns at high noon, but in the end you’ll end up with a functional community of writers all working towards the same goal.

Finding Support

The most essential, and perhaps hardest, part of writing a style guide is receiving support from your company. Of course, your company would love a style guide to flash to clients and keep their writers in line, but they’re not likely to schedule time that could be spent doing billable work making a style guide. So, the first step in creating a style guide is convincing your managers of its worth. Thankfully, style guides offer a number of benefits that appeal to budget-conscious managers.

First, style guides save your team time in the long run. Style guides allow writers to concentrate on the content without being distracted by having to look up documentation and grammar conventions. Furthermore, they don’t need to be extensively briefed on matters of style when taking over a project from another writer. Finally, style guides cut down on debates between writers (at least the ones concerning grammar and punctuation), which saves everyone a lot of time and a little bit of tension in the office.

Second, style guides develop a brand that your company can leverage. Many companies, including Latis Global Communications, employ multiple writers at any given time. Often, there’s no guarantee that we can assign all of the projects from as client to a single writer, so the style used for a user’s guide may not match the one used for the accompanying administration manual. In fact, even the titling conventions may differ! A comprehensive style guide, well implemented, ensures that the style and voice of the writing remains consistent throughout all of a company’s projects.

Getting Started

After you’ve convinced your boss that a style guide is a valuable tool, you face another sizable challenge: the writer’s room. Writers – whether technical or not – hold fast to their views, especially with matters of grammar and punctuation. My first time implementing a style guide, I decided no harm could come from a simple open forum among the writers to start things off. Of course, the forum quickly dissolved into a generational battle about issues such as contractions in manuals and ending sentences with prepositions, so this was not the smartest option.

Instead, you should appoint someone to act as a style sheriff. The style sheriff is responsible for writing and maintaining the style guide as well as settling disputes regarding style issues. The style sheriff should have an eye for details and a genuine interest in matters of style. Look for the writer with the most well-worn copy of Struck and White. It also helps if the sheriff is appointed by someone in charge, such as a division head or team manager, in order to avoid some of the disputes that are bound to arise with one writer dictating matters of style to the others.

As their first action, the style sheriff should choose a base style guide to inform their decisions. The most popular style guides for the IT market are the IBM Style Guide: Conventions for Writers and Editors and the Microsoft Manual of Style for Technical Publications. The former advocates a tone similar to that used in academic writing, while the latter promotes a more conversational tone. Either style guide is acceptable. However, these style guides should only inform stylistic decisions. The lengths of these style guides (389 pages and 464 pages, respectively) make them difficult to memorize for new writers. 20-30 pages is a better length for an internal style guide because new writers can easily digest it in a night and master it in a week.

Depending on your industry, you may want to consider authoring a glossary in conjunction with the style guide. The Microsoft Manual of Style for Technical Publications contains a substantial glossary of user-facing technical terms. However, you may want to use a more technical glossary, such as the IEEE Standard Glossary of Software Engineering Terminology, or even a controlled language glossary, such as glossary found in the Aerospace and Defense Simplified Technical English standard. Whichever you choose, you should treat the glossary in much the same manner as the base style guide. That is, you should incorporate entries from the base glossary into an internal glossary that contains only those entries relevant to your company in order to enhance the usability of the glossary. Tips on how to create a glossary will be covered in a future blog entry.

Lists and Meetings

After selecting a base style guide, you can start considering what to include in your internal style guide. Include too many topics, and users won’t be able to effectively memorize the style guide. Include too few topics, and users won’t be able to find the answers they need.

A good strategy when first developing your style guide is to list all of the topics covered in the base style guide. Then, armed with this list, review three or four recent projects and check off any style topics that match aspects of the project. For example, if the projects contain tables, then, naturally, you should check off the topics related to tables in your list. Finally, create a new list that includes only the checked off topics.

Distribute this list among the writers at your company, and then organize a meeting at which the writers can propose new topics. You should also allow the writers to vote on grammar and style issues that may be particularly contentious, such as ending sentences with prepositions and the use of Oxford commas. At the conclusion of the meeting (or series of meetings) you should know the topics that your style guide will contain as well as your company’s stance on most style issues.

Writing the Style Guide

After determining what your style guide will cover, you can finally start the fun part: Making decisions about grammar and punctuation. If that doesn’t sound like fun, then you may want to step down as style sheriff or risk a showdown when you can’t justify not using the Oxford comma.

Each entry in an internal style guide should state a specific rule, outline some of the exceptions to that rule, and then provide an example highlighting the rule. As in the following:

Compound Nouns

Avoid using more than three nouns when creating compound nouns. Use prepositions to clarify noun clusters.


(O) Maintenance procedure for the operator area

(X) Operator area maintenance procedure

The style guide should abide by the same formatting and style that it recommends. This allows writers to infer answers to style questions while reading, which saves time when looking up multiple issues. Furthermore, your style guide should be just as readable as any other document that you produce. So, it needs an appropriate amount of white space, pages that readers can scan easily, and an intuitive structure. Finally, formatting your style guide in this way ensures that all of your company’s internal documents, such as standard operating procedures and employee handbooks, have a consistent style and appearance.

In addition, you should author your style guide using the software most often used by your company. For example, if your company uses Microsoft Word, then you shouldn’t author your style guide in Pages. Furthermore, you shouldn’t author your style guide using a tool or markup language that is unfamiliar to members of your team. For example, if your team regularly authors documents in XML, then it wouldn’t make sense to author your style guide in Markup.

Distributing the Style Guide

After writing the style guide, determine whether your writing team would benefit most from a physical copy of the style guide, an electronic copy of the style guide, or both. If publishing the style guide electronically, select a format that uses a program openly available to your writers, such as PDF. If publishing hard copies of the style guide, consider distributing the guides in small binders so that the information can be easily updated without incurring too many additional costs.

You should then distribute the style guide in conjunction with a kickoff meeting involving all of the writers and other personnel that will use the style guide. This meeting should instruct the personnel how to effectively apply the style guide to their writing and the scope to which it applies. For example, you should specify whether the style guide applies to all documents and written correspondences or only those that the customer will see. You should also specify who will update the style guide and how personnel will be notified of such updates.


A good style guide can help you bring law and order to an unruly community of writers. However, implementing a style guide requires tenacity, strength, and the support of your company. It also helps if you’re organized and have a plan of action. I’ve armed you with the plan, so it’s time for you to strap on that sheriff’s badge and set the town straight.

5 Content Management Strategies to Get the Most Out of Your Localization Vendors

Last December I had the pleasure of meeting Gearbox Software’s Micahel Weber at the Game QA and Localization Summit in San Francisco. During one of the discussion seminars he posed an encouraging question: with tight deadlines, and games often seeing last minute changes to text and art assets, how can developers help their localization vendor work efficiently to deliver a quality product?

It’s an encouraging question that shows localization is being considered in earlier phases of development, so in response we have crafted five content management strategies that can help your vendors ensure your game is a hit in whatever markets you explore.

1. Arrange your files into categories

Good content management begins with an organized file structure.  While it might seem like an obvious point, arranging files into clearly defined categories – such as, items, NPC names, location names, quest text, voice over text, etc. – is often overlooked under the pressure of a tight delivery schedule.  Taking the time to organize files into categories has a number of time and money saving benefits. First, it allows your vendor to easily create a glossary and style guide that will ultimately ensure consistency in translations, naming conventions, and overall tone. A well-organized file structure also makes it easier for automation during quality assurance checks, reducing the turnaround while still maintaining a high quality localization.

2. Clearly mark deprecated text or text susceptible to change

The last minute nature of the game development process, particularly where certification and submissions are concerned, means that text will often change or be entirely removed. Unfortunately this can lead to a lot of confusion in the translation process, and retroactive changes can be time consuming and costly.

To solve the problem, vulnerable text should be clearly marked or separated from text that has received the final stamp of approval. This can be done by color coding the text, leaving comments, or using translation software, such as TRADOS or MemoQ, to lock vulnerable strings until they are ready for translation and review.

3. Use easily manageable file formats and include meta-data

The file format you choose to deliver your content to your vendor has a significant impact on project scheduling. Delivering files in a difficult format, such as Excel, can create delays as the data must then be extracted and re-engineered into a format that translation software can read.

As a rule, it is best to discuss with your vendor which file type is most ideal, but when in doubt either plain text or XML is the best option. Both allow for easy formatting that can cut out hours, and sometimes days, of work. These formats also allow for the easy addition of meta-data, a helpful, and often ignored, tool in providing information to translators. This can include speaker information, such as gender and age, quest information such as objectives and location, or other useful information to help clarify the context of any particular string.

4. Organize text chronologically

The larger the volume of text you have, the more frequently your localization team is going to need to cross-reference information to ensure consistency throughout the project. Meta-data goes a long way to help here, but it is also best to organize your text in narrative blocks as it appears in the game. This will also help in the testing phase when editors may need to go back and change text, making it much easier to find.

5. Have an open Q&A platform to solve problems and answer questions

Lastly, and perhaps most importantly, keep an open dialogue with your vendor. Your localization team and translators should be asking questions (if they don’t, consider it a red flag), and they will need an easily accessible platform to manage their queries. Smartsheet, Google Docs, Bugzilla, and Redmine are all valuable tools for creating query boards and bug tracking. These should be supplemented with frequent face-to-face meetings (or video conferencing) to make sure that your project is on schedule and meeting quality expectations.

If you have any comments or questions about this post, feel free to comment below, or email Curtis File at curtis.file@latisglobal.com