Localization Reader
Bug Reporting in Localization Projects
By Edward Watts, Retek
Less than a year after graduating from high school, I jetted off to Argentina for 2 years. It was a life-changing experience in at least two important ways: becoming fluent in Castellano (how Argentines refer to their language), which helped me land a career in localization; and falling in love with alfajores, essentially stuffed-and-coated cookies. The best are the ones stuffed with dulce de leche (a caramel) and smothered in chocolate (ah, one of those universal words!).
An Argentine friend recently visited his mother country, and returned with a wonderful package for me--an assortment of alfajores! Oh, what rapture-it has been years since I delighted in that taste! But it needn't have been so long. Dogpiling (like Googling) alfajores recently, I found dozens of links for researching and ordering the treat, including http://www.havanna.com.ar/data/Productos/alfajores.htm, the home of one of my favorite brands, partially because I lived not far away from their main factory at one point.
The world economy is here to stay. In spite of the fears that English will crowd out all other languages, during my localization career I've seen an increase in the numbers of languages in which we need to deliver products. There is more than just FIGS (French, Italian, German, Spanish) in the 21st-century, high-tech world.
What gets translated in a software project often includes the software itself, the help system, and user documentation. When it comes time to test the quality of the translated materials, there are many things you can do without knowing the language. Translation is just one part of localization projects. Localization also may involve adjusting content for a target market.
When working on a localization project, it is quite common to work with a team of people separated by geography and time. Bugs always show up in these projects. Effectively and efficiently communicating these bugs to the people who can fix them is critical to the success of the project.
Bug reporting should be part of the project kickoff. The method to be used should be decided before beginning the project. Also important is ensuring that the parties involved agree on the principles of bug reporting, to make the process as smooth as possible.
Establish method
Various methods can be used in reporting bugs:
- Listing bugs in an email message
- Sending spreadsheets via email
- Using a spreadsheet on a shared network
- Using a database
- Using a dedicated bug-reporting software package
The choice of method depends on the needs of the project and the preferences of the project team. It is important to agree from the outset on which method will be used. Following are relative merits of the various methods.
Listing bugs in an email message: One of the easiest ways to report bugs is to send email to the person responsible for fixing the issue. If the project is very small or short, this can be a simple, effective means; however, it soon becomes difficult to track the status of issues on medium and large projects.
Sending spreadsheets via email: If more than a few issues are to be reported, spreadsheet software like Excel is useful. Spreadsheets help you organize the bug report in logical ways. For example, you can create a template with all the types of information (see "Information to include" below) indicated in column headings.
Use data, not colors, to mark issues in a spreadsheet. It is tempting to color a line green when it is complete, or red when critical. While it can be easy to quickly see a different colored bug, you can't use the filter feature to group similar bugs together. If instead you enter "Open" in the Status column and "1" in the Priority column, you can easily filter on all "Open Priority 1" issues in Excel.
Sending a spreadsheet via email is better than just sending bug reports in email messages. The status of the issue can be kept, and the issues easily organized based on criteria such as open issues. The spreadsheet can be sent back and forth as needed.
One problem with this method is keeping track of who has the master bug list. It can quickly get confusing if more than one person is adding information to the spreadsheet.
Using a spreadsheet on a shared network: To avoid the problem of keeping track of who owns the master bug list, the bug list spreadsheet can be kept on a shared network drive, either on a corporate network or on the Internet. This will work if the team is separated by geography and time, but all members of the team need access to the drive to make it work.
One issue with using a shared spreadsheet is that it is possible for members of the team to inadvertently overwrite each other's data. The most likely time to have problems is when multiple team members are starting a new issue at the same time. Two members may open the bug list at about the same time, and start entering a new bug on the next available line. When the first user saves the file, his bug will get saved on that line. But when the second user saves the file, the program will likely save the second user's report on the same line as the first user's, erasing it. With Excel, lost data can usually be recovered as long as the "Keep change history for…" checkbox is checked in the advanced tab of the Share Workbook dialog.
Using a database: Using database software avoids the issue of team members inadvertently overwriting each other's data. A database gives the team the flexibility to add lots of comments and feedback to a single bug record, while ensuring (when properly configured) that no information is lost or overwritten. Microsoft Access is a useful tool for creating a simple bug-tracking database. As needed, a snapshot of the data can be exported to a text or Excel file to send to team members who are not on the network.
A quick and easy way to get a database up and running, without the need for ongoing support, is to use Internet-based databases like QuickBase or Intranets.com. They feature templates designed for bug tracking, so you can be on your way in minutes. They will usually require a monthly fee, but also offer a free trial period. Note that not all of them support double-byte characters gracefully, so test carefully before you subscribe.
Dedicated bug-reporting software package: Large projects--or the prospect of many projects in the future--call for dedicated bug-reporting software. There are some good (and free!) options available, including Bugzilla: http://www.bugzilla.org/ and Reporting/Tracking System (RTS): leqa@nettuno.it. We were introduced to RTS by our localization vendor, and have used it on some of our larger localization projects.
Borrowing the in-house package: Every self-respecting software company has something in place for tracking engineering bugs. These can be adapted for localization projects.
One of the advantages to using an in-house package is that it is already adapted to your company's needs. Your in-house team will have a short learning curve, since they will likely already be familiar with it. There may be no extra cost for licenses, although there may be some internal cost for adapting it (for example, adding a new field labeled "Language").
A drawback to using the in-house system is that there may be issues with granting sensitive access to outsiders. Also, the team supporting the system may be unwilling to make any necessary modifications to handle localization projects, or may not want to bother with supporting special, multilingual needs.
Bare minimum system
Whatever you decide suits your situation best, be sure that the system:
- Supports accented and multibyte characters. You've got to be able to type the text in the language you are testing!
- Handles graphics for screenshots. If you're all on the same network, this isn't as important, because the screenshots can be stored in a shared folder to which all participants have access.
- Is usable and accessible to all project participants. If it takes to long to enter data, or you can't get reports out of it, it won't be worth the investment.
Information to include
Regardless of the method used for tracking issues, it is important to include the following information in bug reports:
- Unique issue number
- Priority-how important it is to fix it
- Type of issue (software crashes, string display truncation, missing punctuation, and so on)
- Person reporting the issue
- Date of report
- Summary of the issue
- Module of the program or document that contains the issue
- Complete steps to recreate the issue
- If a terminology or wording change, include how it should be
- Name of screenshot showing the issue
- Person assigned to fix the issue
- Status
- Resolution
- Date of resolution
Bug reporting principles
Regardless of the method used to report bugs, certain principles will always apply.
Repeatability
Make sure the issue is easy to find and repeat in software, and easy to find in documentation. If the persons assigned to fix the issue can't find or duplicate the issue, they can't fix it. They need to be able to reproduce the problem to make sure the intended fix actually addresses the issue. It is frustrating to have the bug reporter and the fixer going back and forth with "I fixed it", "No, it still happens", "Ok, now I've got it", "No, you haven't."
Completeness
Be complete in describing the issue, and include all of the necessary steps to recreate the issue. Also, include any relevant environmental information, such as operating system and version number of the software or document. When reporting issues with documentation, be sure to describe clearly the incorrect content, as well as how it should read or function.
Screen shots
For software issues, take screen shots. A picture can be worth a thousand words! Not every issue needs a screen shot, but if you have any doubt, include a screen shot. Screen shots contain lots of information that you may not realize is relevant to resolving the issue. Screen shots often include information that is helpful in diagnosing the problem, such as exactly which screen has the problem, what information was typed in to get to it, other applications that might be running, exact wording of error messages, error IDs, parent screens, language of OS, and so on.
Screenshots can be fairly low-resolution for easy movement and storage. Give some thought to the file format of the screen shot. The file format could be of several common formats, including bitmap (*.bmp), JPEG (*.jpg or .jpeg), TIFF (*.tif), or GIF. For instance, on my machine, a bitmap of my desktop saved with Microsoft Paint takes up 3841KB, which may be larger than can be attached to an email message. The same image stored in a Microsoft Word document takes about 220KB-less than 10% the size of the bitmap. The bitmap file could also be compressed with something like WinZip. My desktop image compresses down to 164KB.
Screen shot software such as SnagIt (www.techsmith.com), ScreenHunter () and ClipMate (www.thornsoft.com) are valuable tools for efficiently creating and saving screen shots.
Screen shots can be especially important when you are working with characters that are difficult to enter from the keyboard, such as Asian or Middle-Eastern languages.
Screen recorders
Want to remove all doubt when reporting software issues? Record the screen with screen recorders. WebEx (Windows), Screen Recordster (www.code-it.com), Snapz Pro X 2 (Macintosh, http://www.ambrosiasw.com/utilities/snapzprox/).
One issue in one record
Stick to the rule of only one issue per record or line. Don't put all the issues with one screen or document into a single bug record. Different issues will require different resolutions, and maybe even work by different people. Grouping things together means a bug can't be closed out until all parts of the bug are resolved, creating confusion about just what needs to be done.
Conclusion
Don't turn down a project just because part of it requires work in another language. With a little forethought, you'll see that it's not "rocket science" after all, and that it's not so different from testing the original version of the product. In fact, the quality assurance team that works on the original version of the product is the one best suited to testing the localized versions.
Links
RTS (Windows): leqa@nettuno.it
Bugzilla: http://www.bugzilla.org/
QuickBase: https://www.quickbase.com/, monthly subscription service
Intranets: http://www.intranets.com/: monthly subscription service
SnagIt: http://www.techsmith.com/
ScreenHunter: http://www.wisdom-soft.com/
ClipMate: http://www.thornsoft.com/
WebEx: http://www.webex.com/
Recordster: http://www.code-it.com
Ed Watts (MA Linguistics, BYU), a Software Localization Engineer at Retek, Inc., has been in localization since moving from software testing in 1990. He has dabbled in programming since a floppy drive was a luxury. His favorite project: WordPerfect for Mac in Japanese. Fluent in Spanish, passable in French, he can embarrass himself with a few phrases in many languages, including Finnish, Russian, Italian, Dutch, and ASL.
