典型的翻译和本地化项目模式
　　如上所述，客户往往无法提供清晰、正确、全面的翻译和本地化项目要求规范，表明增量方法和迭代方法比线性模型更适合于这种类型的项目。然而，采用增量方法和增量
　　方法似乎只是特殊情况，而非翻译和本地化项目管理的常用规范。
　　翻译、编辑和校对 (TEP) 是传统翻译项目模式的核心。Beninatto 和 DePalma 指出：“TEP 基于古腾堡的印刷要求，作者提交稿件，一人将其排版，其他人根据需要多次检查长条校样，以确保没有错别字，使其成为最终印刷的版本”。当创作和出版分别独立进行时，线性 TEP 方法是有很意义的，且文本采用平板印刷方式出版。然而，在二十一世纪初，这种线性方法越来越落伍。Kasdorf 指出：“今天，几乎所有的出版都是数字化的，无论其内容是以电子方式还是印刷方式呈现。”
　　尽管由于数字革命和桌面排版的出现，创作和出版在过去二十五年间经历了巨大的转变，但翻译项目管理却并未受到多大的影响。今天，TEP 仍然是典型的翻译和本地化项目模式的核心，它包括以下阶段 (Beninatto和DePalma 2007：2-3，5；ForeignExchange Translations 2011；Jonckers 2008：7；Leary and Nock 2009：18；Lionbridge 2009：9；Shaefer and Koh 2010：19，21)：
　　- 项目规划，包括以下流程：
　　- 范围定义
　　- 需求开发
　　- 文件准备（从源文件中提取可翻译文本，如果可用，则进行预翻译；有时称为“预处理”或“预生产”）
　　- 翻译
　　- 编辑
　　- 将翻译好的文本整合到文件中（根据所涉及的文件类型也称为“格式化”，“桌面排版”或“排版设计”）- 最终布局校对（也称为“测试”、“语言测试”或“核验”；包括校正所有识别出的问题）
　　- 最终布局中的客户审查（包括实现所有要求的后续更改）
　　- 生成最终目标文件（有时称为“最终产品”）
　　- 交稿
　　这些项目阶段倾向于以明确的顺序呈现、讨论和绘制。此外，通常不引用迭代和反馈环节的内容。这些观察结果表明，典型的项目模型主要为线性模型（见图10）。“多数翻译机构仍以这种方式运作”，Beninatto 和 DePalma 指出，他们将顺序过程模型比作“本地化泰勒主义”。
　　在当今的 TEP 翻译环境中，企业采用的顺序过程中最简单的方式是由客户交付工作给项目经理，然后项目经理将其转交给译员，后者将完成后的工作呈交给项目经理，项目经理再将其发送给编辑，编辑处理后将其返回给项目经理，最后项目经理将其交付给客户。
　　国际化专家和行业资深人士 Tex Texin 同意 Beninatto 和 DePalma 的观点，并指出“本地化行业（专注于适应性和个性化的行业）一直坚持其现有的流程模式，并未发生改变”。

　　图 10. 包含典型的翻译或项目本地化的活动是按顺序进行的。
　　线性翻译和本地化模式的主要问题是最后阶段是客户审核（即验证，见图 4），而非交稿。因此，在所有语言工作完成之前，都不会收到客户的反馈意见，而语言工作完成后将反馈整合到翻译和编辑过程中为时已晚。因为客户审查往往侧重于后期项目检查检测或纠正错误 (QC)，而不是预防错误发生 (QA)，这种方法会增加返工及预算超支的风险。换句话说，在线性翻译和本地化模式中，语言服务提供商为客户提供一整套可交付成果，然后执行一轮或多轮返工，直到客户满意为止，就像之前提到的“一半黑色、一半黄色“的汽车一样。因此，典型的语言行业产品模式反映了“改进的瀑布模式”或两步增量方法（见图11）。

　　图 11. 改良版瀑布型项目模型。生成验证的目标文件，即构成第一增量，客户审核（即验证）之后再次实现的更改则构成了第二增量。
　　客户审核揭示并放大了质量管理问题
　　客户往往缺乏评估翻译和本地化可交付成果所需的专业知识和/或人力资源。Txabarriaga (2009：4) 指出：“除了某些特例，一般的语言服务买方仍处于本地化成熟的早期阶段”。不希望将工作质量视为理所当然，或将产品上市，并向最终用户承担发现可能的质量问题的责任，客户通常会将翻译评估任务
　　交给国内工作人员或国内分销商或外部服务提供商等第三方。理论上，审核应该是协作完成的，旨在确保产品满足客户的需求和期望。实际上，审核过程往往是不明确、令人抗拒和浪费时间的。Bass 指出：“遗憾的是，在许多情况下，这个过程是对立的而不是协作的。质量预期才是这个问题的核心”。
　　例如，假设给定项目的范围不包括客户审核，在这种情况下，语言服务提供商 (LSP) 交稿时便认为该项目完成。在交付后的某个时间，客户（或其代表）对材料进行单方面审阅，发现“问题”并将其提交给 LSP。如果缺乏将质量要求期待以及确保产品符合要求的正式流程，交付后审核并提出更改请求，轻则会使得客户与 LSP 之间的关系变得紧张， 重则可能会引发诉讼。如果合同仅仅规定 LSP 提供翻译，没有提出除关于目标语言和可能的目标区域以外的要求，LSP 可以一如既往地要求按照规范完成工作， 从而解除 LSP 免费返工的责任。另一方面，客户可能有无数的理由不接受译文。例如，客户可能会认为文本过于直译 (或不够忠实原文)，或是不同意翻译中采用的术语或风格，即使它们本身并不算错。此外还有数不胜数的可能存在的分歧点。这种情况中，出现的问题是，虽然客户要什么，LSP 就为其提供什么，并按照项目规范进行，但是客户可能仍然表示不满意。这种情况，双方都没错，但证明自己是对的，并不代表就赢了。这就是典型的双输。
　　毫无疑问，项目范围中的客户审阅不一定能解决其自身出现或固有的问题。例如，翻译评估会预先假设审核者对源语和目标语及其文化、相关专题方面的知识都有适当的了解，并且对翻译、本地化过程、工具和方法等也有了解。如果审核者不具备这一系列必备的技能，那么事实上，他/她可能会增加错误而非改善翻译质量。同样，如果没有明确定义任务范围，则审核者通常会基于其个人术语和风格偏好来评估翻译。只要在项目规划阶段正式确定偏好，以偏好为衡量标准来评估译文是完全可以接受的。基于偏好评估翻译但事先未以规范数量的形式确定这些偏好，在翻译完成后又发现质量要求，如上所述， “这样会使得效率低下，不利于项目完成，一般认为理智的人不会这样做”。然而，这正是许多翻译和本地化项目经理正在做的事情。 客户并没有主动提出偏好反馈，语言服务提供商 (LSP) 通常是在翻译完成后在审核者的要求下进行一些“偏好”性更改时才发现它们。LSP 通常认为这种要求更改是不必要的甚至是过分的；然而，客户认为这可作为在项目早期阶段没有尽可能增加价值的证据。
　　从恶性循环到良性循环
　　那么，如何在翻译和本地化项目中管理和交付以客户为中心的高质量译文呢？我们所描述的恶性循环如何转变成良性循环？首先，项目质量管理的主要关注点必须是客户。客户需求和期望(可延伸至最终会使用翻译或本地化产品的目标受众) 决定了项目质量和要求。反过来，项目的具体细节，包括业务目标、目标受众的特征以及交付的时间、地点和媒介都决定了产品的质量和要求。最后，待生成的可交付产品的具体特性决定了管理项目产品的生产、核验和确认的过程质量管理要求。换句话说，以客户为中心的的项目质量管理要放弃传统的自下而上的办法。传统方法是从文章的语言表面结构到目标观众，最后到实际应用进行翻译 (Nord 1997)。现在真正需要的是一个自上而下的方法，从客户务实的目标到交流的语境和受众，并最终到形式上的语言结构或可交付成果的表面属性。质量管理自上而下的方法见图 12。

　　图 12. 以客户为中心的质量分解结构。
　　因为项目质量的概念取决于客户的要求，所以质量不能被普遍定义，必须为每个项目构建单独的模型。项目质量模型必须考虑翻译文本或者本地化产品的形式特征，以及决定其是否符合预期用途的文本或产品的特征。为了实现量化评估，必须在操作上定义包含质量模型的特性。正如 Heiman (2001:49) 所述，“操作型定义定义了用于测量操作的构造或变量。”最后，必须在项目产品方面和项目过程方面建立质量模型。项目质量管理过程模型应包括四个组成部分：(a) 质量要求分析；(b) 质量设计；(c) 质量衡量；(d) 持续质量改进。