Outlining a Translation Requirements Specification

Outlining a Translation Requirements Specification

By Luigi Muzii,
Italian association for terminology,
Gruppo L10N

Get the List of 4,700+ Translation Agencies Now!
No Recurring Membership Fees!

The success of a translation project depends on its preparation, and this includes the identification of service needs, and then a requirements specification. A specification is defined by ASTM as an explicit set of requirements to be satisfied by a material, product, or service.

In a project, a (requirements) specification is a document providing an adequate and unambiguous description of the task load, together with a description of the desired results, the essential conditions to which the service must conform and the characteristics or features of each deliverable.

Its purpose is to present vendors with a clear, accurate and full description of the customer’s needs, and so enable them to propose a solution to meet those needs, which subsequently become incorporated in the contract.

The specific goal of a good translation requirements specification (TRS) is to establish the basis for agreement between the customers and the vendors, to determine if the translation specified meets their needs, and help the vendor select the most appropriate resources and prepare a realistic schedule.

There is a lot of great stuff on the Web about writing good specifications. The problem is not lack of knowledge about how to create a correctly formatted specification. The problem is what should go into the specification, especially a TRS.

If the request for proposal is the genesis of the client translation process, the TRS is the client tool to draw up the boundaries of the translation project, and establish a sound base for a positive working relationship to provide smooth operations allowing for cost effectiveness and respect of schedule.

TRS and Quality

The ISO 9000 series of standards introduced the notion that quality is a relative concept, which makes sense only when compared to a set of specifications. Today, quality broadly corresponds to product suitability meaning that the product meets the user’s requirements. To appraise quality in the sense of qualification to meet requirements, general criteria are necessary.

To this end, a TRS should also include information for the vendor about the project assessment such as metrics and scorecards for quality assessment. The scorecard in particular is critical to track and justify the requirements, and should provide for

Outlining a Translation Requirements Specification

Criteria (key performance indicators)
Weights (the mean used to resolve any differences in assessment)
Measures (the scale unit for scoring, e.g. low/ medium/high, 0-5)
Scoring (ranking with respect to benchmarks)
Comments

Criteria could cover the following:

Specification adherence (e.g. none to full, 0-5)
Meaning correspondence (rewriting required, e.g. none to full, 0-5)
Naming conventions
Terminology consistency
Timing.

Quality expectations/thresholds should be specified together with the size and type of samples for inspections.

Elicitation

Requirements are necessary also to determine what buyers and vendors find most important in the procurement process, and tailor requests and proposals respectively.

Gathering requirements is not always a straightforward task. On the other hand, if you can’t collect requirements you don’t know your client, and if you don’t know your client you can hardly please him.

Gathering requirements involves interaction with the so-called information sources, individuals, organizations or documents, in most cases in the form of eliciting. Eliciting is active questioning to negotiate priorities, and define expectations. The focus should be on defining the customer’s goals, and agreeing on ways to test whether the project meets those goals.

The LSP is the translation expert and should guide the buyer through the process by asking questions that are part of a checklist.

Project requirements

The TRS should be part of a translation kit and serve as a basis for the statement of work detailing “what is to be done.”

Project requirements must be concise and straightforward to be read and followed. It is not bizarre that an experienced translator, typically willing to follow the instructions as close as possible, is annoyed by pages and pages of guidelines requiring a long time to read and possibly many readings during the job.

Be sure that the translators read and sign the TRS in the translation kit for approval, and fill all relevant items in the query sheet carefully after translation with the commonly used or fixed vocabularies/expressions. Have the query sheet sent back. This will help to refine the TRS for future use.

Refer to style guide for conventions in handling place names, person names and proper nouns, capitalization, and punctuation. Ask for translation to be spell-checked before delivery.

Translation parameters

Translation parameters come with the answers to the questions that should be asked, and form the actual set of specifications.

The basic issues that shall be addressed are the following:

Languages and regional variations of the source text
Languages and regional variations of the target text
Subject matter
Type of source text
Purpose of the source text
Purpose of the target text
Intended audience of the source text
Intended audience of the target text
Culture-binding
Adherence to target-language conventions
Spatial and temporal correspondence
Terminology and terminology management
Use of controlled language
Style and editorial guides
Rewriting
Format
Encoding
Reference materials
Number of graphics
Amount of text in graphics
Translation technology
Naming conventions

Further (support) information

When available, further information should be passed over to the translators to allow them better fulfill their job:

Origin of source text
Author(s) of source text, with contact information
Creation date of source text

Specified apart in contract

If necessary, the following information can be detailed separately in contract:

Importance (priority for the customer, e.g. low, medium and high)
Data control and confidentiality
Volume
Method of computing volume
Deliverables and deadlines
Communication methods and procedures
Medium and method of delivery
Change management procedures
Billing procedures
Legal, ethical, and financial considerations
General dispute-resolution procedures (e.g. storage, handling, and ownership of TM’s, delays, quality of deliverables, etc.)

Conclusion

Just like the translation kit it belongs to, a TRS is never really done: it is an iterative document that reflects the plans and intentions of an organization as to translation. As those change, so must the TRS change. A (possibly Webbased) form could be arranged to store all details in a database for job tickets and facilitate periodic reviews to help shape the TRS.

Thanks to Fiorenza Mileto for her invaluable comments.

Suggested readings

Muzii L., Building a Localization Kit, ClientSide News Special Supplement, December 2005

About the Author

Luigi Muzii has been working in the language industry for 25 years as a translator, localizer, technical writer and consultant. He is visiting professor of localization at the Libera Università degli Studi “S. Pio V” in Rome, Italy, the author of a book on technical writing, and of many papers and articles on translation, and localization. He has been one of the founders of the Italian association for terminology and of Gruppo L10N.

Published - May 2008

ClientSide News Magazine - www.clientsidenews.com