Bridging language and technology

本地化工程:衔接语言和技术

2020-01-10 23:50 Lingua Greca

本文共2736个字,阅读需28分钟

阅读模式 切换至中文

Localization engineering bridges language and technology by making content available for translation and localization across digital platforms. Many localization solutions are available for fully or partly automating this process for mobile- and web-based applications and websites. If you understand the goals and processes of localization engineering, you can make a more informed choice for localizing your own digital product. Do you choose a subscription-based localization solution with the expectation of ongoing maintenance? Or do you make a one-time investment in hands-on engineering up front, then pay for updates on an ad hoc basis? This article explains what localization engineering is, what distinguishes the two approaches, and how to choose a method for localization engineering for software and websites. Hands-on localization engineering solutions The cost and efficiency of a hands-on solution depends on how difficult it is to distinguish the translatable content from the coding and/or formatting. Essentially, hands-on localization engineering isolates the source content for translation and provides it to linguists in a user-friendly format, while protecting the code from corruption. Processes such as "pseudo-translation" are used to ensure that all the content has been secured and all the code and formatting has been flagged and excluded. Once the translation is complete, the application or website is reassembled and delivered to the client. Most document translation projects require hardly any preparation because their formatting is common, standardized, and easily recognized. For example, translation management tools are fully compatible with Word documents, so no "localization engineering" is required to "find" the text. On the other hand, if you are looking to translate custom-built software in an unusual file format, quite a bit of extra effort can be required to sort out the content. Even commonly used file formats such as .json, .xml and .po can pose issues for industry standard translation tools. Translatable content can be missed, and tags can be corrupted in such a way that scripts and programs crash or do not run correctly after the application or website is re-assembled and delivered to the client. Localization management solutions If you have researched translation for multilingual websites and mobile apps, you’ve seen a wide range of solutions for translating and updating multilingual digital media. These are packaged as translation "platforms" or "proxies" or, more recently, "localization management solutions." Some are developed by startups focusing specifically on websites and mobile apps, while others are proprietary tools that have been developed by language service providers. In this article, we will refer to these as "automated solutions." In general, automated solutions establish a cloud-based framework to translate a website or app and, in some cases, for continuing translation updates on an ongoing basis. After the initial translation project, the client can use the interface to make updates, which trigger micro-translation projects for translators to fulfill almost in real time. Translators log in directly to the tool to translate the client’s changes. The leading platforms can handle an impressive array of file formats, even converting them on the fly. Many also provide the translators with an interface that "mirrors" the look of the source application or website. This helps the translators see the content in context and compensate for text expansion or contraction during translation (some languages use more characters than others, which impacts the "look" of the project). When an automated solution claims that it provides a seamless alternative to what they characterize as tedious "manual" processes, be skeptical. Translation project managers are already skilled in managing digital content, and industry-standard localization project management is NOT limited to cutting and pasting content to and from Excel worksheets. The translation industry has embraced content management technologies on pace with the field of technical communication in general. In fact, automated platforms offer many of the functionalities of translation tools that have been in use since the 1990s. Although we use the term "hands-on" processes to distinguish them from automated solutions, they are still a far cry from "manual." What tools are already in use? Like professional technical writers, professional translators use tools for structuring content, ensuring consistency of style and terminology, and performing quality assurance. Market leaders like MemoQ and SDL Studio (and a host of competitors) have been developing and refining their products for decades. Increasingly sophisticated CAT (computer aided translation) tools are available as both desktop applications and cloud-based collaborative platforms. Competition between brands is intense, but a certain amount of compatibility has developed between them. The industry standard XLIFF file (XML Localization Interchange File Format) allows for translation files to be shared between different tools, with only occasional issues caused by variations in implementation. Nowadays, being able to use these tools has become necessary for a successful translation career. Practically every reputable freelance technical translator and every professional language service partner or agency has expertise with one or more CAT tools. CAT tools break content down into segments and present them in a two-column source-target interface. The tools provide termbase management, controlled authoring, style guidance, and QA functionality. Translation memories (TMs) make pre-translated segments available for re-use across media platforms and over a lifetime of updates. Automated solutions have adopted these capabilities as well, albeit with varying levels of quality and degrees of success. From the translator’s point of view, years of subject matter expertise is codified in their own personal termbases and CAT tool customizations, in addition to investments in training time and licensing fees. Translators prefer to use their own tools (or combination of tools), and in-demand translators can be choosy in declining projects that require them to learn new tools. When quality is paramount (and it usually is), businesses should avoid automated solutions that very few translators are willing or able to use. Why is localization engineering necessary? In a sense, the purpose of CAT tools has always been "automated localization engineering" for digital content. Most file formats have become so commonplace that we hardly even consider them "digital" anymore. Twenty years ago, translation looked very different than it does today. Today, a translator can import a Word document or an InDesign file into a CAT tool, view the text without the distraction of markup/tags, translate it, and export a target document with the formatting intact. SDL Studio, for example, currently supports 70 different file types. For mobile apps, websites, technical drawings, and elearning modules, separating content from code is rarely as simple. Putting the application or module back together again after translation can also pose challenges, especially when multiple languages are involved. When code is mistaken for content and vice versa, problems occur. Recoding can be required to create a usable deliverable. As digital technologies multiply, technical translators face these problems:   CAT tools are compatible with many file formats. However, they are not compatible with ALL file formats. Even if the file formats are compatible, the export and import functions for the client’s authoring platforms will vary in quality. Authoring standards for the source content itself can also vary in quality. Custom coding, shortcuts, and workarounds can all interfere with the CAT tool’s ability to read and manage the content. When choosing a localization strategy, a client should not assume that "automating" the process is going to be more cost-effective. Instead, they should ask these questions:   How localization-friendly is the website or app? What is the expected frequency of changes and updates? What in-house resources can I devote to localization engineering? Regardless of whether you will use automated or hands-on solutions, the best way to reduce the costs of localization engineering is to follow best practices for internationalization from the start. Internationalization best practices What is the first step toward localization-friendly content for apps and websites? Protect the code. Keeping the content separate from the code makes it easier to isolate the content for translation.   Don’t hard-code dates, times, measurements, or currencies. Don’t concatenate strings to form sentences. Remember that grammar and word order vary across languages. Don’t embed text in graphics. Support different character sets by using Unicode. If certain features won’t be used internationally, make them easily disabled options. Store strings in resource files. If an app or website is not already internationalized, recoding will be necessary to accommodate the needs of a global audience. Some automated solutions promise to take the internationalization step out of the equation by creating a proxy site or replica to serve as the source for the localized sites. Automated solutions: upsides and downsides When an app or website is being localized, automated and hands-on solutions are two different methods for doing the same type of work: isolating content to facilitate translation while protecting the code. As we discussed above, there are lots of variables that impact how much time needs to be spent making sure all the content can be "found" and translated. On one hand, a client may prefer to involve his developer(s) in the process, taking on some of the tasks in partnership with a translation provider. For other clients, the value of the developers’ time may be greater than the savings from hands-on localization engineering. Automating the process may engage the development team to a lesser extent than a hands-on solution will. Costs The costs of automated solutions can be an important factor. Different localization platforms offer different fee structures. Some website translation platforms require a monthly or yearly fee. This will vary, depending on the number of languages hosted, the site traffic, the word count, additional services such as SEO, and the frequency of changes and updates. In exchange, the burden on your development team will be reduced, particularly if you expect a lot of updates. If you leverage a language service partner’s hands-on engineering, you pay once for the initial internationalization and localization engineering. Certain tasks can be assigned to your development resources to balance the workload and decrease the fee. Future updates occur on an ad hoc basis. It is not at all unusual for a client to use an automated solution in conjunction with their regular language service partner or translation team. For example, a client may decide to use an automated platform to manage the localization engineering, while drawing on their usual team of subject matter experts to do the translations. Either way, the translation of the content itself is generally billed separately. The price will be determined by:   The word count or volume. The linguistic skill and subject matter expertise of the translators, if human translation is used. The source-target language pairs, if machine translation is used. Machine translation generally works better for translating English into European languages than into Asian languages.     How can localization engineering methods impact quality? One of the upsides of an automated solution is reduced demand on your own development team. One of the downsides of an automated solution is a potential narrowing of the field with respect to translation talent. As we mentioned earlier, professional translators prefer to use their own tools rather than invest time in learning a new one. Some leading automated solutions have cultivated networks of translators who are expert users of the tool. More recently developed options can’t always make that guarantee. Others rely on crowd-sourcing, which can be fine for certain things, but completely inappropriate for any translation that requires specialized knowledge of the subject matter. A second downside to automated solutions is that their embedded termbase, translation memories, and QA tools generally cannot match the quality and reliability of the standard CAT tools used by professional translators. As we mentioned earlier, the purpose of a translation memory is to ensure consistency across all media (mobile app, website, documentation, sales materials). If an automated solution can give you access to the translation memory in an XLIFF format, this can help. But if the solution specializes in only apps or only websites, you will still need to translate your other materials. Language service partners who provide translation for all types of media may be in a better position to make sure the content of the website and app are consistent with the rest of your publications. How do I decide? Whether or not we recommend an automated solution depends on the estimated frequency of your updates and the complexity of the authoring process. These, in turn, correlate with your plans for using your multilingual website and mobile app. Is your website relatively static? If you distribute your products exclusively through a network of foreign distributors or maintain sales offices overseas, you may not need frequent updates. In this case, you might use your localized website primarily as a means for   Reputation management. A translated website demonstrates that a brand is committed to serving a region. It also builds authority with the search engines used by customers in that region. Access to local sales channels. Many multinationals use translated websites to provide contact information for local offices or distributors. Meeting legal requirements. Regulators may require you to make certain information available to the public on your corporate website (for example, the European Union Regulation on Medical Devices specifically refers to websites as resources for public information). If you expect relatively few updates, hands-on localization engineering could be performed without the use of an automated solution. The scope of work will depend on the site architecture and content management system (WordPress, Drupal, or a custom solution) that you are using, and whether you want your development team to take on some of the tasks. Do you use your website for advertising and content marketing? In this case, your localized site primarily serves as a gateway for:   Lead generation. A translated landing page attracts interested prospects and provides opportunities to engage them in your sales funnel. Establishing search authority. Even though your flagship website is available around the world to anyone specifically seeking it out, if it’s not optimized for search engines outside of the U.S. (including google.fr and so forth), it won’t be served to searchers. Content marketing. Your blog and thought leadership content are important assets for your flagship site and can serve the same purpose internationally. Light customer support. Depending on the subject domain and the language, FAQs or machine translation of chat interactions can suffice for answering questions from your customers. For this type of localized website, updates may be frequent, but they are also predictable. If you’ve chosen a hands-on solution, the same localization engineering workflow and team from the initial translation project can remain available. However, if you expect the size and scope of your digital property to grow significantly within the next few years, an ongoing contract with a localization platform or proxy solution may be more efficient in the long run. Do you provide e-commerce and SaaS? If you anticipate frequent changes to your website and applications, we would recommend a platform or proxy service. The platform communicates content changes directly from your source to the translation team.   Dynamic e-commerce. If you are selling products through your site, and you expect a lot of content changes over time, the platform allows translators to be "on call" to translate small "chunks" as needed. Lots of user-generated content. If your customer support strategy includes maintaining an online knowledge base (as for business software), or you invite reviews and other commentary that you want translated, a platform will be better able to accommodate an unpredictable, time-sensitive workload. As with customer support, machine translation might be a suitable option for this type of user-generated content. If localization will be included as part of an Agile software development process, the tools and workflows of automated solutions will help tremendously. If you expect frequent changes, an automated solution would make the ongoing maintenance of the website more cost-effective. However, an important question you’ll need to consider when selecting one is how much the content will vary across regional sites (e.g., will you highlight certain products in certain markets?) and whether the platform is flexible enough to handle differences across localized websites. As global markets mature, options will continue to multiply. Your localization management tactics should be viewed in the context of your global business strategy. Choosing the best fit for your team requires research, inquiry, and flexibility.    
通过本地化工程,内容可以跨不同数字平台进行翻译和本地化,从而将语言和技术衔接起来。目前已有许多本地化解决方案,可将基于 Web 的应用程序和网站的本地化过程完全或部分地自动化。如果您了解本地化工程的目标和流程,您可以为自己的数字产品本地化做出更明智的选择。您是否选择了基于订阅的本地化解决方案,并期望持续维护?或者你是一次性投资在前期的实际工程,然后支付更新的临时基础上?本文阐述了本地化工程是什么,区分了两种方法,以及如何选择软件和网站本地化工程的方法。 现成的本地化工程解决方案 实际解决方案的成本和效率取决于将可翻译内容与编码和/或格式化区分开来有多困难。实际上,手工本地化工程将源内容分离出来进行翻译,并以用户友好的格式提供给语言学家,同时保护代码免受腐败。使用诸如“伪翻译”之类的过程来确保所有内容都已得到保护,并且所有代码和格式都已标记和排除。翻译完成后,应用程序或网站将重新组装并交付给客户。 大多数文档翻译项目几乎不需要任何准备,因为它们的格式是通用的、标准化的和易于识别的。例如,翻译管理工具与 Word 文档完全兼容,因此不需要“本地化工程”来“查找”文本。另一方面,如果您希望以一种不寻常的文件格式翻译自定义构建的软件,则需要花费相当多的精力来整理内容。 甚至常用的文件格式如.json ,。xml 和。po 可以为行业标准翻译工具提出问题。可以忽略可翻译的内容,并且可以以这样的方式破坏标签,即脚本和程序在应用程序或网站重新组装并交付给客户端后崩溃或不正确运行。 本地化管理解决方案 如果您已经研究了多语言网站和移动应用程序的翻译,您已经看到了多种翻译和更新多语言数字媒体的解决方案。这些被打包为翻译“平台”或“代理”,或更近的“本地化管理解决方案”。有些是由专门关注网站和移动应用的初创公司开发的,而另一些则是由语言服务提供商开发的专有工具。在本文中,我们将把这些称为“自动化解决方案”。 通常,自动化解决方案建立了基于云的框架,用于翻译网站或应用程序,在某些情况下,用于持续不断地进行翻译更新。在初始翻译项目完成后,客户端可以使用该接口进行更新,从而触发译者的微翻译项目几乎实时完成。翻译器直接登录到该工具以翻译客户端的更改。领先的平台可以处理一系列令人印象深刻的文件格式,甚至可以马上转换它们。许多翻译人员还提供了一个界面,可以“反映”源应用程序或网站的外观。这有助于翻译人员了解上下文中的内容,并补偿翻译过程中的文本扩展或收缩(有些语言比其他语言使用更多的字符,这会影响项目的“外观”)。 当一个自动化的解决方案声称它提供了一个无缝的替代他们所描述的乏味的“手动”过程,持怀疑态度。翻译项目经理已经熟练地管理数字内容,行业标准本地化项目管理并不限于从 Excel 工作表中剪切和粘贴内容。翻译行业已经将内容管理技术与一般技术交流领域同步。事实上,自动化平台提供了许多翻译工具的功能,这些工具自20世纪90年代以来一直在使用。尽管我们使用术语“手持”过程来区分它们和自动化解决方案,但它们仍然与“手动”有很大区别。 哪些工具已经在使用? 与专业技术作家一样,专业翻译人员使用工具来构建内容,确保风格和术语的一致性,并执行质量保证。MemoQ 和 SDL Studio (以及众多竞争对手)等市场领导者数十年来一直在开发和完善他们的产品。越来越复杂的 CAT (计算机辅助翻译)工具既可作为桌面应用程序使用,也可作为基于云的协作平台使用。品牌之间的竞争非常激烈,但它们之间已形成一定的兼容性。行业标准 XLIFF 文件( XMLLocalizationExchangeFileFormat )允许在不同工具之间共享翻译文件,只有由于实现的变化而引起的偶然问题。现在,能够使用这些工具已经成为翻译事业成功的必要条件。实际上,每一个有声望的自由职业技术翻译人员和每一个专业语言服务合作伙伴或机构都拥有一个或多个 CAT 工具的专业知识。 CAT 工具将内容分解为段,并将它们呈现在两列源目标接口中。这些工具提供了术语库管理、受控创作、风格指导和 QA 功能。翻译记忆体( TMs )使预先翻译的片段可以在媒体平台上和整个更新周期内重新使用。自动化解决方案也采用了这些功能,尽管质量和成功程度各不相同。 从译者的角度来看,除了在培训时间和许可费用方面的投资外,多年的主题专业知识还被编入他们自己的个人术语和 CAT 工具定制中。翻译人员更愿意使用自己的工具(或工具的组合),在需求下降的项目中,翻译人员可以选择学习新的工具。当质量是最重要的(通常是这样的),企业应该避免自动化解决方案,很少有翻译者愿意或能够使用。 为什么本地化工程是必要的? 从某种意义上说, CAT 工具的目的一直是数字内容的“自动化本地化工程”。大多数文件格式变得如此普遍,以至于我们甚至不会再把它们视为“数字”了。二十年前,翻译看起来与今天截然不同。今天,翻译人员可以将 Word 文档或 InDesign 文件导入 CAT 工具,查看文本而不会分心标记/标记,翻译它,并导出完整格式的目标文档。例如, SDL Studio 目前支持70种不同的文件类型。 对于移动应用程序、网站、技术图纸和电子学习模块,从代码中分离内容很少简单。翻译后重新将应用程序或模块放在一起也会带来挑战,特别是在涉及多种语言时。当代码错误为内容时,反之亦然,就会出现问题。可以要求进行记录以创建可用的可交付成果。 随着数字技术的发展,技术翻译面临着以下问题: CAT 工具兼容许多文件格式。但是,它们与 ALL 文件格式不兼容。 即使文件格式兼容,客户端创作平台的导出和导入功能在质量上也会有所不同。 源内容本身的创作标准在质量上也可能有所不同。自定义编码、快捷方式和解决方案都会干扰 CAT 工具读取和管理内容的能力。 在选择本地化策略时,客户不应假定“自动化”流程将更具成本效益。相反,他们应该问这些问题: 网站或应用程序如何本地化? 更改和更新的预期频率是多少? 我能为本地化工程投入哪些内部资源? 无论您是否将使用自动化或动手解决方案,降低本地化工程成本的最佳方法是从一开始就遵循国际化的最佳实践。 国际化最佳做法 应用程序和网站的本地化内容的第一步是什么?保护代码。保持内容与代码分离使分离内容更容易进行翻译。 不要硬编码日期、时间、度量或货币。 不要将字符串连接成句子。记住,语法和单词顺序因语言而异。 不要在图形中嵌入文本。 使用 Unicode 支持不同的字符集。 如果某些特性不能在国际上使用,请使它们易于禁用选项。 将字符串存储在资源文件中。 如果应用程序或网站尚未国际化,则需要重新编码以适应全球受众的需求。一些自动化解决方案承诺,通过创建代理站点或副本来作为本地化站点的源,使国际化步骤走出方程。 自动化解决方案:高端和劣势 当应用程序或网站正在本地化时,自动化和实际操作解决方案是两种不同的方法,用于执行相同类型的工作:隔离内容以便于翻译,同时保护代码。 正如我们上面讨论的,有很多变量影响需要花费多少时间来确保所有内容都可以“找到”和翻译。一方面,客户可能更愿意让其开发人员参与该过程,与翻译提供商合作承担一些任务。对于其他客户而言,开发人员的时间价值可能大于从实际本地化工程中节省的时间。自动化流程可能会让开发团队参与到比实际解决方案更小的程度上。 成本 自动化解决方案的成本可能是一个重要因素。不同的本地化平台提供不同的费用结构。有些网站翻译平台需要每月或每年付费。这将根据托管的语言数量、站点流量、字数、附加服务(如 SEO )以及更改和更新的频率而有所不同。作为交换,开发团队的负担将会减少,特别是如果您期望大量的更新。 如果您利用语言服务合作伙伴的实际工程,您将一次性支付初始国际化和本地化工程费用。某些任务可以分配给您的开发资源,以平衡工作负载和降低费用。未来的更新是在临时的基础上发生的。 客户与其常规语言服务合作伙伴或翻译团队一起使用自动化解决方案并不罕见。例如,客户可以决定使用自动化平台来管理本地化工程,同时利用他们通常的主题专家团队来进行翻译。 不管怎么说,内容本身的翻译通常是分开计费的。价格将由: 单词 count 或 volume 。 如果使用人工翻译,译者的语言技能和专业知识. 如果使用机器翻译,源目标语言对。机器翻译通常比亚洲语言更适合将英语翻译成欧洲语言。 本地化工程方法如何影响质量? 自动化解决方案的一个优点是减少了您自己开发团队的需求。自动化解决方案的缺点之一是在翻译人才方面的领域可能会缩小。正如我们前面提到的,专业翻译更愿意使用自己的工具,而不是花时间学习新的工具。一些领先的自动化解决方案已经培养了翻译网络谁是该工具的专家用户。最近开发的选项并不总是能保证这一点。另一些人则依靠众包,这对于某些事情来说是很好的,但对于任何需要专门知识的翻译来说都是完全不合适的。 自动化解决方案的第二个缺点是,它们的嵌入式术语库、翻译记忆库和 QA 工具通常不能与专业翻译使用的标准 CAT 工具的质量和可靠性相匹配。正如我们前面提到的,翻译内存的目的是确保所有媒体(移动应用、网站、文档、销售材料)的一致性。如果一个自动化的解决方案可以让您以 XLIFF 格式访问翻译内存,这会有帮助。但是,如果该解决方案只专注于应用程序或网站,您仍然需要翻译您的其他材料。为所有类型的媒体提供翻译的语言服务合作伙伴可能处于更有利的位置,以确保网站和应用程序的内容与您的其他出版物一致。 我如何决定? 我们是否推荐自动化解决方案取决于更新的估计频率和编写过程的复杂性。这反过来又与您使用多语言网站和移动应用程序的计划相关。 你的网站比较静态吗? 如果您只通过外国经销商网络分销产品或在海外维持销售办事处,您可能不需要频繁更新。在这种情况下,您可能主要将本地化网站用作 信誉管理。翻译网站表明一个品牌致力于服务一个地区。它还与该地区客户使用的搜索引擎建立权威。 进入当地销售渠道。许多跨国公司使用翻译网站为当地办事处或分销商提供联系信息。 符合法律规定。监管机构可能会要求您在公司网站上向公众提供某些信息(例如,欧盟医疗器械法规特别提到网站作为公共信息的资源)。 如果您期望的更新相对较少,则可以在不使用自动化解决方案的情况下执行动手本地化工程。工作范围将取决于您正在使用的站点架构和内容管理系统( WordPress 、 Drupal 或自定义解决方案),以及您是否希望开发团队承担一些任务。 您是否使用您的网站进行广告和内容营销?在这种情况下,您的本地化站点主要用作以下方面的网关: 铅的产生.翻译的登陆页面吸引了有兴趣的潜在客户,并提供机会让他们参与您的销售渠道。 建立搜索权威.即使你的旗舰网站在世界各地都可供任何专门寻找它的人使用,如果它没有针对美国以外的搜索引擎进行优化(包括 google.fr 等),它也不会被提供给搜索者。 内容营销。你的博客和思想领导内容是你的旗舰网站的重要资产,可以在国际上服务同样的目的。 轻客户支持。根据主题领域和语言, FAQ 或聊天交互的机器翻译足以回答客户的问题。 对于这种类型的本地化网站,更新可能是频繁的,但它们也是可预测的。如果您选择了一个动手解决方案,那么最初翻译项目中相同的本地化工程工作流程和团队仍然可用。但是,如果您预计您的数字财产的规模和范围在未来几年内将显著增长,那么与本地化平台或代理解决方案的持续合同从长远来看可能会更有效。 你提供电子商务和 SaaS 吗? 如果您预期对您的网站和应用程序的频繁更改,我们将推荐一个平台或代理服务。平台将内容更改直接从源代码传送到翻译团队。 动态电子商务.如果您正在通过您的网站销售产品,并且您期望随着时间的推移会有很多内容的变化,该平台允许翻译员“按需”翻译小的“块”。 大量用户生成的内容。如果您的客户支持策略包括维护在线知识库(如业务软件),或者邀请您希望翻译的评论和其他评论,那么平台将能够更好地适应不可预测的、时间敏感的工作负载。与客户支持一样,机器翻译可能是此类用户生成内容的合适选项。 如果将本地化作为敏捷软件开发流程的一部分,自动化解决方案的工具和工作流程将会极大地帮助您。 如果您希望频繁更改,自动化解决方案将使网站的持续维护更具成本效益。然而,在选择一个内容时,您需要考虑的一个重要问题是,各区域站点的内容会有多少不同(例如,您是否会在某些市场中突出某些产品?)以及该平台是否足够灵活,足以处理各本地化网站之间的差异。 随着全球市场的成熟,期权将不断增多。应结合您的全球业务战略来看待您的本地化管理策略。选择最适合你的团队需要研究,调查和灵活性。

以上中文文本为机器翻译,存在不同程度偏差和错误,请理解并参考英文原文阅读。

阅读原文