 |
 |
 |
 |
|
|
Home | More Articles | Join as a Member! | Post Your Job - Free! | All Translation Agencies | |
|
|||||||
|
|
|
|
Outlining a Translation Requirements Specification
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. QA 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
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:
Further (support) information When available, further information should be passed over to the translators to allow them better fulfill their job:
Specified apart in contract If necessary, the following information can be detailed separately in contract:
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 Universita 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
E-mail this article to your colleague! Need more translation jobs? Click here! Translation agencies are welcome to register here - Free! Freelance translators are welcome to register here - Free! |
|
|
|
|
|
|
| |||
Legal Disclaimer Site Map |
