Building Quality: The LISA QA Model 3.0

“One man’s trash is another man’s treasure” – so goes the old saying. Perhaps nowhere is this more evident than in globalization, internationalization, localization and translation (GILT), where everyone seems to have differing ideas of what constitutes a good localization. Ask two different translators to evaluate a translation and you’ll get three opinions. Beyond the notion that things have to be translated, and translated correctly, various ideas of how to evaluate translations vary wildly. What one person finds a fine localization another may find barely serviceable, but your company is routinely evaluated on the quality of the localizations you put on the market.

The LISA QA Model is currently used by over 250 companies.

Given the difficulty of coming to any objective evaluation of localization quality, how are companies supposed to know that the localizations they are using are accurate and represent good quality? Without any sort of formal quantifiable metric for evaluation of translation quality, there is no way to escape inherently subjective notions of quality. To address this, LISA released the first version of the LISA QA Model in 1995, with a second version in 1999. According to LISA survey data, approximately 20% of all companies involved in GILT use the QA Model in some way, making it the most widely-used QA metric in the industry.

The extensively revised LISA QA Model 3.0 can be used as a stand-alone application or integrated with almost any database system.

LISA felt the need to revamp it to meet current needs, and is now proud to announce the release of the LISA QA Model 3.0, an entirely revised version built on a standard database framework. This new version of the QA Model can either function as a stand-alone application, or can be easily be integrated into any system that supports ODBC database connectivity, meaning that almost any database application can now interact directly with the LISA QA Model to automate QA checking and decisions based on checking.

The LISA QA Model is designed to help you manage the quality assurance process for all the components in a localized product, including functionality, documentation and language issues. The quality metrics and procedures in the QA Model result from a collaboration between LISA members, localization services providers, software and hardware developers, and end-users. Their “best practices and recommendations,” along with a basic statistics model, have been compiled to help you streamline your company's product localization quality assurance process.

Who should use the LISA QA Model 3.0?

Content creators who need to verify the quality of their localized materials
Localization service providers who need to certify the quality of their localizations
Translators who want to check their quality prior to 3rd-party review
Reviewers who need to evaluate translated text
Project managers who need to validate localization quality
Anyone who needs an objective measure of localization quality

What are the features of the LISA QA Model 3.0?

A list of all ISO 639 3-Letter language codes and language names
An extensive list of GILT error categories, and severity levels and weights
Predefined metrics to define PASS/FAIL
List of tasks that are performed by testers/translators/reviewers on localization projects
Customizable forms and reports
Example data to help users in their implementation
User-definable and extensible error categories, severity levels, severity level, weights, tasks, etc.
Metrics to measure/compare the performance of individual vendors
Metrics for evaluation of source documents
Users-portable database schema can be implemented in user’s own database engine
Checklists for testing localized user interface (GUI)
Objective measures of error severity can automatically trigger appropriate business decisions.
Compatible with LISA QA Model version 2.0. Easy upgrade from version 2.0
Can be used as a stand-alone application or integrated with other tools.
Implemented using Microsoft Access 2002. Access export and reporting features may be used.
Security can be defined on a per-user level. QA data can be protected against deletion and alteration