Iimplementing translation standards can be complex, like entering an Escher’s labyrinth.   As the ISO website points out, “standards are the distilled wisdom of people with expertise in their subject matter and who know the needs of the organizations they represent.”  We use standards every day, in all aspects of our lives. Some standards have been around for hundreds or even thousands of years. Think, for example, of weights and measures and how their differences and similarities affect us all. Think of electric plugs and outlets and the need to have a universal plug adapter on hand when traveling.    Translation Standards for Processes and Products We can roughly divide standards into two categories: process standards and product standards. Translation-related standards are generally process standards, the most popular being ISO 17100 (that sets the requirements for translation services). A more recently popular standard is ISO 18587 (on post-editing of machine translation). There are also national standards, like the US ASTM F2575 – 14 and the Canadian CAN/CGSB-131.10-2017, which are largely equivalent to ISO 17100.  Technical product (or system) standards refer mainly to information-exchange formats, such as TBX (TermBase Exchange), TMX (Translation Memory Exchange) and XLIFF (XML Localization Interchange File Format). Standards can be issued by a recognized organization (ISO, ASTM, etc.) and, therefore, formally ratified (de jure). There are also market-driven standards (or de facto standards) related to commercial products and solutions developed by major organizations. One example for all will suffice: Microsoft Office.   It is interesting to note that most translation management systems (TMS) make use of de jure standards. This is necessary, for example, for connectivity or for APIs (almost all developed with de jure standards as a starting point). Also, when addressing tasks on the user-side, like the processing of files available in proprietary formats (like Adobe PDF), it’s important to refer to existing de jure standards. Why? Well, one reason is that royalties usually apply on de facto standards. (Of course, there are also de facto standards, like Linux, which are open and free, but let’s stick to the essential facts for now.) From Translation Standard Certification to the Selection of a TMS Turning to the implementation of a TMS, the first questions to ask are: What does your organization need in terms of formats or functionalities? Are these essentials already present in the platform or do they need to be developed ad hoc? How will the TMS be used?   If you decide to rely on a commercial SaaS solution (which is the easiest and fastest solution offering serious benefits), you’ll need to familiarize yourself with the building blocks and the basic architecture of the platform in question, and, of course, with the standards it is built upon.   It’s important to make sure that the platform can evolve without encountering legal, technical, or other problems. Technology must adapt to processes and not the other way around. In order to obtain a certification for a process standard (for example, the above mentioned IS0 17100), a translation company must first define the processes, then certify them and, finally, find a TMS that is adaptable and flexible enough to put those processes into practice. To this end, the flexibility of a TMS is vital. Some elements and aspects of a TMS can help on the path to certification. The main criteria for a standard certification are: being able to document your organization’s process writing the quality manual producing the technical documentation of the platform to be used Every single item indicated in the quality manual has to be associated to an element in the TMS. For example: a job ticket or project ID described in the quality manual will have to be associated with a similar item present in the TMS. Again, the QA settings described in the quality manual will have to be implemented step by step in the QA functionalities of the chosen TMS. Every future variation in the translation process must be replicated in the TMS, without requiring structural interventions, so that when the audit takes place, processes and technology are harmonized. But what if your organization already has a TMS in use and wants to apply for certification? In this case, your TMS can be used as a template for writing the quality manual and describing the translation workflow implemented inside your company. One final thing to keep in mind: for the ISO 9000 certification, the documentation to be provided must also include all software documentation. Every system/platform (including any CRM, vendor management software, financial system and so on) adopted by your organization becomes an integral part of your quality system. Some TMSs, like Wordbee, offer the option to manage suppliers, quotes and invoices on the platform itself, becoming the core of the translation workflow.