매뉴얼 만들기

지루하고 반복적인 일의 방식을 바꾸고자 많은 사람들이 혁신을 도모한다. 그러나 혁신은 떨어지는 사과에서 얻는 영감이 아니다.  영감만으로는 아무것도 바꿀 수 없다. 끊임없이 이어지는 사소한 물음에 대한 답이 쌓인 뒤에 비로소 혁신이 가능해진다. 하나의 제품 디자인이 쓸 만한 물건으로 나오기까지 수 많은 시험과 변경이 이루어지는 것과 비슷하게, 유용한 매뉴얼을 만들려면 상당히 많은 문제들을 갖고 고민해야 한다. 디테일이 없는 계획은 환상에 불과하고,  덜 마무리된 제품은 팔 수 없는 견본에 지나지 않으며, 문서의 요건을 갖추지 않은 매뉴얼은 전단지에 불과하다.

보통 사람들의 바람과는 달리, 타자기에 종이를 끼우고 글쇠를 두드리는 것만으로는 매뉴얼이 만들어지지 않는다. 아래 그림은 우리가 매뉴얼 개발에 착수하면서 갖게 되는 수 많은 물음들 가운데 일부를 보여준다.  이것들 가운데 아무 문제나 집어올리면 수십 또는 수백 가지의 연관 질문들이 딸려 올라올 것이다. 이 블로그는 앞으로 그 질문들을 하나씩 다룰 것이다.

CreatingManuals

매뉴얼을 만드는 전문가들이 있다.  그들 가운데 테크니컬 라이터(technical writer)가 이 분야를 대표한다. 테크니컬 라이터는 technical communicator 또는 information developer라고도 불린다. 매뉴얼 개발을 비전문가에게 맡기는 것은 결코 현명한 결정이 될 수 없다. 매뉴얼 개발이 필요한 기업들은 테크니컬 라이터를 채용해야 한다. 그러나 한두 명의 테크니컬 라이터가 매뉴얼 개발에 동원되는 모든 지식과 기술을 갖추고 있기를 기대할 수 없다. 경험 있는 테크니컬 라이터를 구하는 것조차 어려울 것이다. 매뉴얼 전문가 집단으로부터 그들의 노하우를 배우는 것이 매뉴얼 개발에 필요한 유능한 인적 자산을 확보하는 지름길이다.

Five Ways to Prepare your Software for Localization

Today’s tech market encompasses far more than just North America and Europe. Emerging economies in South America, Asia, and Africa have changed the landscape of both software development and sales, and consumers now expect and demand products and services tailored to their linguistic and cultural needs. Failure to meet these needs harms the competitiveness of your product and, in many cases, allows other companies to clone your product and reap the customers you deserve.

Proper localization helps your product fulfill these needs. However, localization involves more than just hiring a good translation company – it involves thorough planning throughout the development cycle of your product, careful consideration of design elements, and a concerted effort from the entire development team. The following five tips will help you keep your localization efforts on track and ensure that the process is as painless as possible.

Start early

Start preparing to localize your product as soon as you identify its core features and target markets. Even if you haven’t clearly identified where you plan to release the product, it’s still a good idea to ensure that the development and design teams consider localization when creating the user interface. For example, text in other languages may be up to 50% longer or shorter when translated, so elements such as text boxes, dialog windows, and menus should be sized to accommodate both the longest and shortest strings in this spectrum.

Leaving the localization process until the last minute may also lengthen your development time and localization costs. Whether you’re using an agile or waterfall workflow, a good localization partner can work with your schedule to provide incremental support for text translation and localization. In fact, involving a localization company early in the development process often improves the end result because the company has time to get to know your team and understand your product. In addition, many localization companies charge a premium – sometimes even double the cost – for quick turnaround times and same day service. So, if you wait until your product is finished before beginning the localization process, then your project may come in past the deadline and over budget.

Develop your own style

After all the time invested into developing the focus and feel of your product, there’s no reason that the text in your software shouldn’t also convey these attributes. Issues such as inconsistent capitalization or syntax can be distracting to users and may even cause them to misunderstand the content. To achieve a uniform style throughout your software, you need to outline the rules governing things like capitalization and syntax choice in a style guide.

Luckily, many of the rules outlined in a style guide can be applied to multiple languages. Some languages may render certain rules moot, for example, languages such as Korean, Japanese, and Chinese do not require capitalization guidelines. When you initially consult a localization provider, confirm that they have the resources necessary to create style guides for all of your target languages.

In addition to text, designers must also consider the icons and images to ensure cultural sensitivity and relevance. For example, some user may not be comfortable with excessive flesh or be familiar with the mailboxes used in North America. This comes with a slight caveat. Accepted icons such as the hamburger icon and save icon have achieved cross-cultural relevance, so these and other similar icons may be used.

Format and isolate text

You should ensure that all text strings use Unicode character encoding. Unicode allows the easiest transfer into languages that don’t use Roman characters, and it handles most of the world’s writing systems. Implementing Unicode after writing the code is a difficult and time consuming task, so it’s a good idea to establish this in your programming best practices before you write the first line of code. In the rare instance that the product cannot support Unicode, then you may need to find a work around using DBCS enabling, bi-directional (BiDi) enabling, code page switching, or text tagging.

In addition to using Unicode encoding, you should also isolate all target text strings from the source code of the project. Programmers should place all target strings in resource files, message files, or a private database. However, these resource files should not include any strings that will not be localized. Any strings that do not require localization should remain as string constants in the source code. Isolating the localization strings in this way ensures that all text is localized according to your company’s style guidelines and allows your software to transition between languages more easily.

Minimize formatting issues

When creating your software, you should consider the range of formatting issues that may arise due to differences in the conventions used for information such as addresses, currency, dates, and telephone numbers. To improve usability, the input fields in which users enter this kind of information need to accommodate various input lengths and characters. For example, postal codes in Canada are a mixture of six letters and numbers, whereas those in the United States use only five numbers. Thus, an input field in a product intended for both countries must either accommodate the relevant lengths and character types in its validity check or separate input fields must be provided. Implementing such changes after releasing the software requires extra investment in development and bug testing and may require resources, such as the original programmer, that are no longer available.

Developers must also consider formatting when writing routines. Some countries, such as Japan, use district and block divisions in addresses rather than street numbers. In software released in such countries, any routine that parses addresses for storage in a database or printing on shipping labels must be able to process such addresses. Failure to do so may result in extra costs from shipping goods to incorrect addresses or customers who are unhappy due to receiving late shipments.

Reuse help content

Help content, whether in the form of tooltips, API documentation, or an old fashion manual, is integral to make your product easy to use and ensure early adopters are satisfied with their experience. However, help content can also quickly consume your localization budget if improperly managed. Most localization vendors charge by the word, so localizing complex sentences and redundant information costs far more than the information may be worth. Keep help content simple and short to get the most return on your localization investment.

In addition, most localization companies charge only for the first time a string is translated. So, whenever possible, developers should strive to recycle strings in order to increase information availability without increasing localization costs. For example, the sentence that introduces a feature in the manual can be used as the tooltip that appears when a user hovers over the icon for that feature, and the section from the manual can be reused in the web help. In essence, this allows you to provide help content in three places for the price of one without adversely affecting the information conveyed by the help content.

Implementing these five simple guidelines during the development of your software vastly decreases the timeframe and cost of localizing your software. Starting early and incorporating these guidelines also ensures that you deliver the best possible product to every target market. For more information about preparing your software for localization, consult the Microsoft Developer Network or your localization provider.