MIIS - Advanced Translation Technology Portfolio
This mini-portfolio highlights selected work from my Advanced Translation Technology course at the Middlebury Institute of International Studies at Monterey. The projects below reflect my hands-on experience with machine translation training, translation technology evaluation, data preparation, post-editing workflows, and translation management systems.Rather than treating translation technology as a black box, these projects helped me understand how language data, domain fit, quality evaluation, workflow design, and human review all work together in a real localization environment. My focus throughout the course was practical: how to use translation technology responsibly, how to measure whether it is actually useful, and how to design workflows that improve quality, productivity, and cost efficiency at the same time.This portfolio includes two major projects:A custom machine translation training project using Microsoft Azure Custom TranslatorA translation management system evaluation and selection case study comparing XTM and WXRKSTogether, these projects show how I approach translation technology from both a technical and operational perspective: building, testing, evaluating, and recommending solutions that can support real localization teams at scale.Project 1: Custom MT Training with Microsoft Azure Custom TranslatorProject type: Machine Translation training and evaluationLanguage pair: Chinese to EnglishDomain: Chinese government work reports and official documentationPlatform: Microsoft Azure Custom TranslatorTraining dataset: Google Drive folder: Azure MT Training DatasetProject OverviewFor this project, my team built and evaluated a custom-trained machine translation engine using Microsoft Azure Custom Translator. The goal was to test whether a domain-specific MT engine could support the translation of Chinese government work documents into English in a way that was faster and more cost-effective than fully human translation, while still meeting the quality expectations required for official and politically sensitive content.The project was designed as a pilot, not just a technical experiment. We wanted to answer a practical business question: Can a custom MT engine produce output that is stable enough for post-editing and review in a real government-document translation workflow?To evaluate that, we looked at three major dimensions: quality, productivity, and cost.WorkflowThe project started with data preparation. We collected Chinese-English government-related texts, extracted usable content, aligned source and target segments, and cleaned the training data before uploading it into Azure Custom Translator. The preparation process included tools such as Trados Studio, memoQ, Olifant, VS Code, and AI-assisted cleanup methods.After preparing the training, tuning, and testing datasets, we completed multiple rounds of MT training. Across the pilot, we ran six training rounds in Azure Custom Translator and tracked BLEU score changes after each round. The BLEU scores moved from 25.7 to 27.7, with later rounds staying around the high-27 range. While the improvement was moderate, the results gave us a useful view into how training data quality, alignment consistency, and domain relevance affected MT performance.The team also planned additional training rounds, with a target BLEU range of 35–50 for a more production-ready engine. This helped frame the pilot as an early-stage feasibility test rather than a final production deployment.Quality EvaluationBecause the content involved government documents, quality could not be evaluated only by automatic metrics. BLEU scores were useful for tracking relative changes across training rounds, but they were not enough to determine whether the output was acceptable for official use.To address this, we designed human evaluation criteria based on practical risk. The expected post-edited output needed to avoid critical mistranslations, politically risky wording, factual inaccuracies, and terminology errors that could affect policy meaning. Minor style issues were acceptable, but critical meaning errors were not.We also used an MQM-style quality framework to define pass, borderline, fail, and automatic fail scenarios. For example, a strong pass would allow a limited number of minor issues and no critical errors, while any critical issue would trigger an automatic fail. This helped connect quality evaluation to real-world decision-making instead of relying only on a single score.Productivity and Cost AnalysisOne of the most useful parts of this project was comparing post-edited machine translation with fully human translation.For a 2,000-word sample, the pilot estimated that post-editing took about 4.69 hours, while fully human translation was estimated at around 15.5 hours. Based on this comparison, PEMT was about 70% faster than human translation in the pilot setting.The cost comparison showed a similar pattern. The estimated PEMT cost was $253.80, including post-editing and review. The estimated human translation cost for the same volume was $780, including translation and review. Based on these numbers, PEMT was estimated to be about 67% cheaper for the pilot sample.At the same time, we treated these numbers carefully. The pilot showed strong productivity and cost potential, but a real production workflow would still need to account for training setup, data cleaning, quality evaluation, engine maintenance, and human review.Key TakeawaysThis project helped me understand that MT quality is not only about the engine. It depends heavily on the quality of the training data, the consistency of the domain, the clarity of evaluation criteria, and the design of the human review workflow.A few lessons stood out to me.First, data preparation matters as much as model training. Poorly aligned or noisy segments can limit MT performance even when the platform itself is strong.Second, automatic metrics are useful, but they need to be paired with human evaluation. For sensitive content, a higher BLEU score does not automatically mean the output is safe to publish.Third, PEMT can create meaningful productivity and cost gains, but only when the output is stable enough to support efficient review. If the MT output requires heavy rewriting, the workflow can quickly lose its advantage.Finally, this project gave me a more realistic view of how translation technology should be implemented in production. The goal is not to replace human judgment, but to build a workflow where technology handles repeatable translation work more efficiently and humans focus on accuracy, nuance, risk, and final quality.Skills DemonstratedThrough this project, I practiced:Custom MT training with Microsoft Azure Custom TranslatorChinese-English government-domain data preparationSource-target alignment and dataset cleanupBLEU score tracking and interpretationPEMT productivity and cost analysisMQM-style human quality evaluationTranslation technology workflow designRisk-aware evaluation for official and sensitive contentThis project strengthened my understanding of how translation systems can be evaluated and operationalized in a real localization environment. It also reinforced a key principle I would bring to future localization and translation technology work: AI is most valuable when it is connected to clear workflows, measurable outcomes, and responsible human review.Project 2: TMS Evaluation and Selection Case StudyProject type: Translation Management System evaluation and selectionScenario: ByteDance-style high-volume localization operationsSystems compared: XTM vs. WXRKSPresentation video: TMS Evaluation and Selection Final PresentationProject OverviewFor the second project, my team designed a TMS evaluation and selection case study for a large-scale, fast-moving localization environment. The scenario was built around a ByteDance-style organization with large volumes of multilingual content, current and future localization needs, and multiple stakeholder groups involved in daily localization operations.The main business question was: Should the organization continue using XTM, a mature enterprise TMS, or adopt WXRKS, a more modern workflow-oriented platform, for future localization operations?Instead of comparing the two systems only by feature lists, we built an evaluation framework based on real business requirements, stakeholder pain points, pilot testing, and weighted scoring. The goal was to make a recommendation that reflected actual localization operations, not just tool preference.Evaluation MethodologyWe structured the evaluation around five steps:Identify key business requirements by stakeholderBuild a weighted scorecardDefine a pilot projectScore XTM and WXRKSPresent a final recommendationThis structure helped us move from a subjective tool comparison to a more business-driven decision model. It also made the evaluation easier to explain to both technical and non-technical stakeholders.The project considered the needs of six major stakeholder groups: Localization Program Managers, Localization Operations/PMs, Linguists/Reviewers/Vendors, Product and Content Teams, Engineering/System Teams, and Leadership/Procurement/Finance. Each group had different concerns, including workflow design, project setup, editor usability, launch readiness, integration capability, reporting visibility, cost, and long-term business value.Business RequirementsFrom the stakeholder analysis, we identified several key business requirements that a future-ready TMS should support:Workflow flexibility for different project types and approval pathsEasy project setup for daily localization operationsScalability for high-volume multilingual workStrong editor usability for linguists and reviewersCollaboration support for comments, issues, and decisionsFast turnaround time for product and content launchesQA and consistency controls to protect brand voice and user experienceIntegration capability to reduce manual handoff and system frictionReporting and visibility for status tracking and performance managementReasonable total cost of ownershipThis part of the project was especially useful because it showed that TMS selection is not only a localization tooling decision. It is also an operations, engineering, finance, and stakeholder-management decision.Weighted Scorecard DesignTo make the comparison more objective, we created a weighted scorecard. Each TMS was scored on a 1–5 scale, where 1 represented poor performance and 5 represented excellent support for the requirement. The final weighted score was calculated by multiplying the raw score by the requirement weight.The category-level weights reflected business priorities. Workflow and project management carried the highest weight at 20%, followed by scalability and performance, linguist and reviewer experience, quality and consistency, and integration and technical fit. Reporting and visibility, as well as cost and implementation risk, were also included in the final evaluation.This scorecard approach helped translate workflow pain points into measurable decision criteria. It also made the recommendation more transparent because stakeholders could see not only which system scored higher, but also why certain areas mattered more than others.Pilot Project DesignTo test the systems in a realistic workflow, we designed a pilot around a product launch localization package. The pilot included a marketing page, UI strings, and a Help Center article, with English as the source language, 3–5 target locales, and an estimated scope of 2,000–5,000 words.The pilot participants included one PM, one reviewer, one engineering observer, and one to two linguists or simulated vendors. The tasks tested in both systems included project creation and setup, user permissions, file ingestion, translation editor usability, translation memory and terminology support, review and comment workflow, QA checks, status tracking, export/delivery, and API or integration feasibility.This pilot design was important because it tested the TMS where it actually matters: daily operations. Instead of asking whether a platform technically had a feature, we looked at whether that feature supported a smoother and more scalable localization workflow.Evidence CollectedThe evaluation was based on multiple types of evidence, including task completion observations, time-to-complete comparisons, friction points and blockers, PM and linguist feedback, reviewer and engineering feedback, QA effectiveness, workflow clarity, scorecard ratings, and screenshots for visual comparison.This made the evaluation more practical and defensible. A TMS can look strong in a demo, but the real test is whether PMs can set up projects quickly, linguists can work efficiently, reviewers can leave clear feedback, engineers can support integrations, and leadership can get enough visibility into project status and operational risk.Comparative FindingsThe comparison showed a clear trade-off between XTM and WXRKS.XTM was positioned as a mature enterprise platform with broad feature coverage, proven standard workflows, and familiarity for current users. However, it could feel heavy and complex in fast-moving daily operations.WXRKS was positioned as a more modern workflow experience with stronger daily usability, better collaboration flow, and a better fit for fast-moving content. The main risk was migration and onboarding, especially if the organization needed to move from an established system to a newer platform.This comparison helped us avoid an overly simplistic recommendation. XTM had strong enterprise credibility, while WXRKS appeared better aligned with the future-state workflow we were designing.Final RecommendationOur final recommendation was to adopt WXRKS as the preferred TMS for future localization operations, using a phased rollout instead of a full immediate migration.The reasoning was that WXRKS offered stronger workflow flexibility, better PM and linguist usability, clearer collaboration and review flows, better operational visibility, and a stronger fit for high-speed, high-volume localization work.At the same time, we recommended risk controls for implementation. The rollout should begin with one product area, train PMs, reviewers, and linguists, validate integrations before full migration, and expand gradually after pilot success.Key TakeawaysThis project helped me understand how to evaluate translation technology from a business and operations perspective. A good TMS is not just the one with the longest feature list. It is the one that best supports the organization’s actual workflows, stakeholder needs, scalability requirements, and long-term localization strategy.The biggest takeaway for me was that TMS selection should be evidence-based. Strong evaluation requires stakeholder analysis, weighted requirements, realistic pilot tasks, and a clear understanding of implementation risk. It also requires balancing short-term operational familiarity with long-term workflow improvement.This project also strengthened my ability to communicate technical and operational recommendations to different audiences. For localization teams, the focus is daily usability and quality. For engineering, the focus is integration and maintainability. For leadership and procurement, the focus is cost, risk, and long-term business value. A strong recommendation needs to connect all of these perspectives.Skills DemonstratedThrough this project, I practiced:TMS evaluation and selectionStakeholder requirement analysisWeighted scorecard designLocalization workflow assessmentPilot project planningTool comparison across business, linguistic, technical, and financial criteriaRisk-aware implementation planningExecutive-style recommendation writingLocalization operations strategyThis project reinforced one of the most important lessons from the course: translation technology decisions should be driven by workflow reality, not tool demos. A system only creates value when it helps real teams move faster, collaborate better, reduce friction, and maintain quality at scale.ReflectionAcross both projects, this course gave me a more complete view of translation technology as a real-world localization function. The Azure MT project focused on how to train, evaluate, and operationalize a custom machine translation engine. The TMS evaluation project focused on how to assess localization platforms from a stakeholder, workflow, and business-value perspective.Together, they helped me connect technical experimentation with practical implementation.The biggest lesson I took away is that translation technology is never only about the tool itself. A strong MT engine still needs clean data, clear evaluation standards, and responsible human review. A strong TMS still needs well-defined workflows, stakeholder alignment, implementation planning, and measurable success criteria.In future localization and translation technology work, I would bring this same mindset: start with the business problem, understand the workflow, define what quality means, measure performance with the right evidence, and recommend solutions that are scalable, practical, and responsible.These projects also align closely with the type of work I want to keep doing: localization program management, translation technology operations, AI-assisted workflow design, quality evaluation, and cross-functional localization strategy. My goal is to help global teams use technology not just to move faster, but to build localization systems that are easier to manage, easier to measure, and better for users across languages and markets.
MIIS - Translation Technology Final Project
This blog documents my final project for Translation Technology, a core course in my first semester at the MIIS. The final project was a team CAT project centered on professional workflows in SDL Trados Studio, covering the full lifecycle from project setup to delivery.Project OverviewOur team worked on a simulated client project for the Monterey Bay Aquarium, translating five English articles into Simplified Chinese. The scope included proposal drafting, tool setup, translation and review, QA, and final delivery. The goal was not only to produce translations, but to demonstrate how a real-world localization project is planned, executed, and delivered using industry-standard tools and documentation.All work followed a structured Statement of Work (SOW) and a clearly defined workflow, including terminology preparation, TM setup, QA checks, and deliverable packaging, reflecting professional vendor-side practicesTools and WorkflowSDL Trados Studio was the primary working platform throughout the project. We applied CAT best practices such as:Translation Memory and term base managementMatch analysis and rate-based quotingBuilt-in QA checks and regex validationConsistent file preparation and final exportSupporting tools such as AntConc were used for terminology extraction, reinforcing the importance of preparation before production.Deliverables and ReflectionThe final deliverables included translated target files, a TMX file, a term base, a style guide, and pseudo-translated files. Beyond the outputs themselves, this project reinforced several key lessons:CAT tools are not just translation aids, but project management and quality control systemsClear documentation and upfront planning significantly reduce downstream reworkConsistency, traceability, and reproducibility matter as much as linguistic qualityFor reference, the full set of project files and deliverables can be accessed here:Deliverables folder: https://drive.google.com/drive/folders/10ttBxM4P0-KWLlHiC9J06JIuIigGB-Y_?usp=drive_linkOur group's Statement of Work can be found here:https://drive.google.com/file/d/1tCoeXyyYxHGnkYgc1cfkxF5Tn5zPSqaE/view?usp=sharingA recorded presentation summarizing our lessons learned from using Trados is also available:Presentation recording: https://midd.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=822a077a-a1ac-4cdb-9f42-b3ad006a730fTo Wrap UpThis project served as a practical introduction to professional CAT-based localization workflows and laid a solid foundation for more advanced tool usage and automation in future coursework.Although I had prior exposure to multiple CAT tools through both coursework and professional experience, I particularly appreciated the opportunity to study Trados in a systematic and structured way. Going through the full workflow helped me uncover several features and capabilities that I had not actively used before, and it deepened my understanding of how CAT tools support not just translation, but consistency, quality control, and scalable localization operations.Overall, the project clarified what it means to approach translation technology work with structure, accountability, and strong industry awareness.
为什么你网页中的日文看起来像中文？
在多语言网站开发或者本地化过程中，许多产品经理或开发者可能都遇见过这样一种神奇的情况：明明页面语言设定是日文，内容也是标准的日文文本，但展现在用户眼前的，却是中文。比如，下面这段话（上）中的“新”字在不懂日语的人看来，好像没什么问题，但其实真正正确的写法应该是这样（下）：在比如下面这些汉字，相信如果对于只懂得汉语或日语一种语言，或是显示屏分辨率较低（bushi）的工程师看来，好像真的很难去分清楚哪些是中文，哪些又是日文。这些差异十分细微且不易察觉，但在母语用户眼中却格外刺眼，仿佛在日文网页里混入了一段“伪装过的中文”。用更简单形象的英语来解释的话，在他们看起来可能会是这样From a native Japanese eye, yѳur ҭєxҭ lѳѳκs κιnd ѳf lικє ҭЋιs. 这种“第一眼看上去没啥问题，但仔细看一看就能发现严重错误”的问题，其根源并不在文本内容本身，或者说大部分原因都不在与文本内容本身，而是在于浏览器和操作系统在渲染这些“统一码”汉字时，选择了错误的字体风格，从而导致视觉效果严重偏离原意。这种视觉违和感很容易就会被目标语用户所发现，尤其是对于母语为日语的本地用户来说，他们看到后的最为直观的感受一定是这个网站或者产品的开发者或者本地化团队是“不专业”且“不地道”的，甚至令人产生对产品本身质量的质疑。这种现象在中日混合字符集（CJK Unified Ideographs）背景下并不罕见。看似是前端开发中一个微不足道的字体选择问题，实则牵涉到语言编码规范、操作系统字体回退机制、浏览器渲染策略和本地化工程等多个维度。本篇博客，笔者将深入拆解这一技术迷宫。一、问题的根源：Unicode的汉字统一与字体的语言特性直接上结论，这一问题的技术根源，其实可以追溯到Unicode最初设计时所采用的“汉字统一（Han Unification）”策略。在20世纪80年代末至90年代初，随着全球计算机网络和多语言系统的兴起，字符编码的碎片化问题日益严重。彼时，中文（包括简体与繁体）、日文、韩文各自采用不同的编码体系，例如中国大陆有GB2312、香港有Big5-HKSCS、日本有Shift-JIS、韩国有EUC-KR等。这种割裂使得跨国文本传输异常困难，也导致了国际软件开发和本地化成本居高不下。为了统一全球字符集，ISO和Unicode联盟提出了一个宏伟的目标：为所有语言制定一个统一的编码体系。在这一愿景下，中日韩三种语言中大量笔形相似、意义相同的汉字成了技术上的重大挑战。如果为每一个变体分别分配独立编码，编码空间将急剧膨胀，Unicode原本设计的16位（65,536个字符）空间将根本无法容纳。为了避免编码爆炸，同时保持基本语义一致性Unicode决定采取“汉字统一（Han Unification）”策略，即只要字义基本相同、形状相近，就归并为一个统一编码点。比如，“直”这个字，在中文、日文和韩文中，笔画细节略有不同（如笔画的曲直、收笔的方式、间架结构的紧凑程度），但在 Unicode中都统一编码为U+76F4。从编码的角度看，无论是中文的“直”、日文的「直」、韩文使用的“直”，本质上都被视为同一个字符。然而，统一编码解决了存储和传输的问题，却将“形”的区分责任转移给了字体文件和渲染系统。也就是说，从编码来看，"直"就是"直"，但从字体设计和最终渲染来看，"直"可以有多种不同的视觉表现，具体呈现哪个版本，取决于浏览器或操作系统选择了哪套字体，以及该字体中为该字符提供的具体字形（glyph）。正因如此，当网页虽然正确地声明了“语言是日语”，但浏览器选用了中文字体来渲染时，本应呈现的日本风格汉字被错误地替换成了中文风格，从而导致“页面展示的虽是日文内容，但透着一股微妙的中文味”这种问题的出现。而这个选择背后，则是一个复杂的“字体回退机制”（Font Fallback Mechanism）和“语言优先规则”（Language Priority Rules）在发挥作用。如果开发者没有显式指定使用日文字体或标注语言为日文（如 lang="ja"），浏览器就会退回到操作系统的默认字体回退逻辑。对于中文系统用户而言，常常就会优先加载中文字体，如“思源黑体 SC”、“Microsoft YaHei”等，结果就是日文页面的汉字部分被“错配”成了中文样式。更令人头疼的是，即便你设置了常见的字体族（如"sans-serif"），不同浏览器和操作系统解析这个族的方式也千差万别，有时甚至会在渲染过程中动态替换字体，这就进一步加剧了视觉的不一致性。二、语言属性的缺失很多开发者在构建静态网页或使用框架生成的页面时，往往忽视了HTML的语言标记。若 标签中未指定 lang="ja"，浏览器就无法知晓当前内容是日文，自然也就不会优先使用日文字体。部分现代框架（如 Next.js）默认使用 lang="en" 或完全省略了应有的lang 属性，除非开发者手动覆写，否则就会自动沿用，无疑使得上述提到的错配问题频繁出现。这个细节在字体选择过程中会产生“蝴蝶效应”：操作系统在无法获知语言上下文的前提下，会以“最安全”的方式回退到系统默认字体。而对于使用中文系统或中文浏览器的开发者来说，这个“默认”往往就是中文字体。所以你在本地预览时看不出问题，部署上线给日本用户访问时，问题却暴露无遗。三、从产品本地化视角审视：字体也是用户体验我们常说内容为王，但在本地化流程中，字体其实也是内容体验的一部分。很多产品经理或工程师往往将字体问题归为“样式层”的技术实现细节，但从语言文化适配的角度来看，字体风格同样承载着语言的文化属性。简而言之，字体不仅影响可读性，更影响用户的心理预期与信任感。在日本市场尤为明显。日本用户对排版美学的要求极高，行距、字距、笔触风格都可能影响其对网站专业性的判断。你可以将网页内容翻译得天衣无缝、逻辑清晰，但若字体“出戏”，就如同在高档日料餐厅用塑料碗上菜，极具违和感。对于面向B端或高净值C端客户的产品，字体错配等同于重大公关事务，更会影响企业及其旗下产品本身的形象。四、解决方案的设计解决这个问题并不复杂，关键在于开发团队与本地化团队协同意识的提升。首先，应从HTML层级入手，明确标注页面语言。设置lang="ja"不仅有助于屏幕阅读器等无障碍工具正确识别语言，同时也是浏览器进行字体回退策略判断的重要依据。现代浏览器在解析页面时，会根据 lang 属性优先匹配合适的字体子集，缺失这一标注极易导致浏览器默认选择系统字体，进而出现汉字显示偏差。其次，在CSS层级明确指定日文字体族，如"Hiragino Kaku Gothic ProN", "Meiryo", "Noto Sans JP"等，并将这些字体置于字体栈（font-family stack）的靠前位置。仅仅指定"sans-serif"或"serif"等通用族名往往是不够的，因为在没有明确指定字体的情况下，不同系统、不同地区用户的浏览器会调用本地默认字体，而对于中文用户来说，这通常是中文字体，如微软雅黑、苹方等。此外，应充分考虑不同平台（macOS、Windows、Android、iOS）对字体的支持情况。例如，"Hiragino"系列在macOS上广泛存在，但在Windows设备上并非默认，需合理添加"Meiryo"等Windows常见日文字体作为备选，并确保回退链合理有序，避免因缺字而降级到错误的字体。进一步的优化策略是，根据用户浏览器的 Accept-Language 头或地区设置（locale information），动态载入对应语言的字体和样式表。这种方案能够在保持页面整洁的同时，显著提升多语言界面的本地化体验。比如，针对设置了日文优先的用户浏览器，优先加载ja.css，其中覆盖字体设置，以确保文本渲染符合日文母语者的视觉习惯。除了常规做法之外，也可以利用CSS本身的unicode-range属性，结合自定义字体子集。可以通过字体制作工具（如FontForge、Glyphs）切割出针对日文字形优化的小型字体包，只为特定字符范围提供专属字形，从而兼顾性能和展示一致性。这种方法在字体加载资源受限、但追求完美的网站中尤其常见。从开发流程角度出发，也应强调在前端开发阶段引入多语种环境测试。开发者不应仅依赖本机环境进行验证，而应在真实的日文系统或模拟器（如macOS日文版、Windows日文区域设置）下进行全面测试。必要时，还可以引入自动化测试脚本，验证不同语言环境下字体渲染是否符合预期，以避免落入“本地看似一切正常，实际目标环境问题频发”的典型陷阱之中。五、写在最后本地化的深度，体现在对用户文化的尊重。从技术视角来看，“日文被渲染成中文”的问题看似是一行 CSS 或一个lang属性的事，但从本地化视角来看，它折射的是产品对于本地文化的敏感度与尊重程度。真正成熟的国际化产品，并非只是语言的替换或功能的上线，更是对每一个细节的精雕细琢。因为用户从来不会单独评价你的翻译质量，而是从每一个界面像不像“自己国家的产品”来判断你是否真正用心去做了。字体问题虽小，但体现了本地化的深度。也正是在这些细微之处，产品体验的专业度与用户好感的积累，才得以悄然发生。Referencehttps://en.wikipedia.org/wiki/Han_unificationhttps://en.wikipedia.org/wiki/Variant_Chinese_charactershttps://modelviewculture.com/pieces/i-can-text-you-a-pile-of-poo-but-i-cant-write-my-name
Multilingual Machine Translation with Large Language Models: Empirical Results and Analysis
基于大语言模型的多语言机器翻译：实证结果与分析pre主要讲研究的一些理论和方法，还有和机器翻译、大模型、预训练、数据集等相关的概念和实际产品，论文中提到的一些具体的数据结果可以应用到涉及到gpt翻译的毕业设计中。Abstract：大语言模型 (LLM) 在处理多语言机器翻译 (MMT) 方面表现出了巨大的潜力。在本文中，我们通过回答两个问题系统地研究了 LLM 在 MMT 方面的优势和挑战：1）LLM 在翻译大量语言方面的表现如何？2）哪些因素影响 LLM 在翻译中的表现？我们仔细评估了八种流行的 LLM，包括 ChatGPT 和 GPT-4。我们的实证结果表明，LLM 的翻译能力正在不断提高。GPT-4 在 40.91% 的翻译方向上击败了强监督基线 NLLB，但与谷歌翻译等商业翻译系统仍存在很大差距，尤其是在低资源语言上。通过进一步分析，我们发现 LLM 在用于 MMT 时表现出了新的工作模式。首先，LLM 可以以资源高效的方式获得翻译能力，即使在零资源语言上也能生成适度的翻译。其次，当给出上下文样本时，指令语义令人惊讶地可以被忽略。第三，跨语言范例可以为低资源翻译提供比同一语言对中的范例更好的任务指导。引言（Introduction）这部分概述研究背景和动机，强调当前多语言翻译领域的挑战，尤其是在零样本（zero-shot）和少样本（few-shot）情况下的难点。Previous studies have shown the surprising performance of LLMs on high-resource bilingual translation, such as English-German translation (Vilar et al., 2022; Zhang et al., 2022), even if these models are not particularly optimized on multilingual data.未解决的问题：MMT is a challenging task that involves translating text among different languages and requires semantic alignment between languages (Fan et al., 2021; Team, 2022; Yuan et al., 2023). It is also unclear that how LLM acquires translation ability and which factors affect LLM’s translation ability. 要解决的问题：In this paper, we follow ICL paradigm and focus on studying LLMs in multilingual machine translation by answering two questions:1) How LLMs perform MMT over massive languages?Compared with the widely-used supervised MMT system NLLB (Team, 2022), GPT-4 achieves higher performance on 40.91% English-centric translation directions. But compared with the commercial translation system (Google Translate), LLMs still have a long way to go, particularly when it comes to low-resource languages. 2) Which factors affect the performance of LLMs?First, we discover that LLM can acquire translation ability in a resource-efficient way and generate moderate translation even on zeroresource languages. Second, LLMs are able to perform translation even with unreasonable instructions if in-context learning exemplars are given. However, if given mismatched translation pairs as in-context exemplars, LLMs fail to translate, which is similar to observations from concurrent studies (Wei et al., 2023). This shows the importance of exemplars in ICL for machine translation. Third, we find that cross-lingual translation pairs can be surprisingly good exemplars for low-resource translation, even better than exemplars in the same language. 零样本（zero-shot）或少样本（few-shot）条件下，通过调整输入的示例数量，快速适应新任务。依赖提示词设计：提示词的质量和示例的选择对模型输出质量有很大影响，尤其是在复杂任务或低资源语言环境中。ICL 在多语言机器翻译中的应用：在多语言翻译任务中，ICL 能通过提供多语言示例来引导模型进行高质量的翻译。例如，用户可以为模型提供英语到法语的翻译示例，接着输入英语到另一种语言（如德语）的句子，模型可以根据上下文自动生成德语翻译。ICL 的优势在于它可以利用少量示例提升模型在低资源语言对上的翻译效果，尤其是在少样本（few-shot）翻译场景中，这种方法已被证明有效提升翻译质量。 近年来，随着大语言模型（LLMs）的出现，多语言机器翻译技术得到了显著提升。然而，在多语言环境中，这些模型在应对高资源语言和低资源语言的平衡方面仍存在不足。零样本和少样本翻译能力的有效性是当前研究的焦点。因此，本研究旨在通过实证分析，评估大语言模型在多语言机器翻译中的表现，并探讨提升翻译性能的方法。Background(1) LLM:a casual decoder-only language model can be a multi-task learner with merely unsupervised training corpus. Radford et al. (2019)scaling the language model also brings astonishing emergent abilities, e.g., in-context learning, which is only present in large models. Wei et al. (2022b) (2) Emergent Ability: In-context Learning假设我们要利用上下文学习(ICL)来完成英语到法语的机器翻译任务。 1. 提示词构造： * 示例对 (Xi, Yi)： * X1 = "Hello, how are you?" * Y1 = "Bonjour, comment ça va?" * X2 = "Thank you for your help." * Y2 = "Merci pour votre aide." * 模板 T： 人类撰写的指令，如："Translate the following sentence: " 2. 生成提示词 P： 将模板 T 和示例对结合，形成最终提示词 P： Translate the following sentence: Hello, how are you? -> Bonjour, comment ça va? Translate the following sentence: Thank you for your help. -> Merci pour votre aide. 3. 推理阶段： 假设测试输入为： Translate the following sentence: I am very happy. -> 模型在提示词 P 的引导下，会基于之前的示例学习翻译模式，预测输出为： Je suis très heureux/heureuse. 生成方式：标签预测任务（如情感分析）：模型只需一次生成输出。序列生成任务（如机器翻译）：可以通过贪婪搜索或束搜索生成更符合上下文的翻译。 例如，使用束搜索可能会生成多个候选翻译，并选取最佳的那一项。这个例子展示了如何通过少量示例和模板引导模型完成特定任务，提高零样本或少样本条件下的输出质量。 3、Experiment Setup(1) 数据集（Dataset）实验使用了FLORES-101数据集，旨在评估模型在多语言翻译任务中的表现。FLORES-101包含多种语言，可以全面反映模型在高资源和低资源语言上的翻译能力。（LORES-101 (Facebook Low-Resource Language Open-Source Evaluation Set) 是一个由 Meta 开发的多语言翻译数据集，专门用于评估机器翻译系统在不同语言对上的性能，尤其是低资源语言。该数据集覆盖了101种语言，包含跨102种语言方向的翻译任务，旨在解决传统数据集中非英语中心化的偏差，提升多语言翻译的公平性和广泛性。评估数据选择：为了控制API成本，基准测试只使用了每个翻译方向测试集中前100个句子。在分析实验中，则使用了完整测试集。 (2) 模型（LLMs）实验中评估了八个主流的大语言模型（LLMs）的翻译性能：XGLM-7.5BOPT-175BBLOOMZ-7.1BFalcon-7BLLaMA2-7B 和 LLaMA2-7B-chatChatGPT（GPT-3.5-Turbo-0301，2023年4月评估）GPT-4（GPT-4-0613，2023年8月评估）这些模型涵盖了不同规模和架构，从开源到商用模型均有涉及，确保实验的广泛适用性。(3) ICL策略（In-Context Learning Strategy）使用了ICL（In-Context Learning）策略来提升翻译性能。具体方法包括：示例选择：从开发集中随机挑选8对翻译示例作为上下文参考。模板设计：使用“=”格式，其中和分别代表源语言和目标语言的句子。拼接符号：以换行符作为示例之间的连接符。效果分析：实验表明，这种简单的ICL策略在实际应用中表现出色，所有实现基于OpenICL框架。(4) 监督学习基线模型（Supervised Baselines）指通过传统的有监督学习方法训练的机器翻译模型。如：Transformer，还有一些神经机器翻译的框架，这些模型通常依赖大规模平行语料库，通过明确的输入-输出对（源语言到目标语言）进行训练。相比于大语言模型（LLM）的少样本学习或上下文学习（ICL），监督学习基线模型具备数据依赖性强：需要大量高质量的平行语料来训练模型，尤其是在低资源语言上的表现可能受限于语料稀缺。训练目标明确：模型通过最大化源语言句子与目标语言句子之间的对齐概率来学习翻译能力。基准性能稳定：在已知语言对上，监督学习模型通常表现稳定，是评估新模型性能的重要参考。 为了对比LLMs的翻译效果，论文报告了以下基线模型的性能：M2M-100-12B：一个支持多语言之间翻译的大规模监督模型。（由 Facebook AI 开发的一款多语言翻译模型，具备 120 亿参数，旨在支持 100 种语言之间的直接翻译，而不依赖英语作为中介语言。这一模型通过大规模平行语料库训练，使得不同语言之间的翻译更加精准和自然，特别是在处理低资源语言时表现出色。M2M-100-12B 的出现标志着跨语言翻译技术的进步，为全球化交流、本地化服务、语言研究等领域提供了强大的工具。）NLLB-1.3B（蒸馏版）：专为低资源语言优化的模型。（NLLB-1.3B 是 Meta（原 Facebook）推出的“No Language Left Behind”（NLLB）项目中的一种小型模型，旨在提升低资源语言的机器翻译能力。这个模型基于改进的 Transformer 架构，专注于支持资源匮乏的语言，针对低资源语言，如非洲、中东和南亚的少数语言，实现更加精准和广泛的多语言翻译。）Google Translate：商用翻译系统，广泛应用于实际场景。（5）评估指标（Metrics）使用了以下评估指标：SentencePiece BLEU（spBLEU）：适用于所有语言的BLEU评分方法，能更准确地反映多语言翻译质量。（SentencePiece分词：由Google 开发，主要用于自然语言处理（NLP）任务中的文本预处理。将句子拆解为较小的子词单元，如单个字母、音节或词干，而非完整的单词。这种方法特别适用于低资源语言或具有复杂词形变化的语言。COMET：通过语言模型计算语义匹配，表现出与人工评估高度相关。SEScore：一种新兴指标，与人类判断有较强相关性。 BLEU ｜ spBLEU分词方式 ｜依赖人工分词或词典 ｜ 使用 SentencePiece 自动分词适用性 ｜ 对高资源语言表现良好，对低资源语言较弱 ｜ 对所有语言更具一致性和公平性精确度 ｜ 词级别评估，可能忽略词形变化 ｜ 子词级别评估，捕捉更多语言细节SEScore 是一种基于语义匹配的新兴机器翻译评估指标，主要依赖预训练语言模型来计算源句和译文之间的语义相似度。它具有以下优势：高人类相关性：相比 BLEU 和 spBLEU，SEScore 在多项研究中被证明与人类评价有更高的相关性。灵活性：可用于更复杂的语言现象评估，例如同义词替换、句式变换等，而不仅仅局限于词级匹配。4、 Benchmarking LLMs for Massively Multilingual Machine Translation（1） 多语言机器翻译能力LLMs 的翻译能力不断进化：LLMs 在多语言机器翻译中的表现逐步提升，尤其是最新的 LLMs，例如 LLaMA2-7B 超越了早期开源模型，而 GPT-4 的性能优于 ChatGPT，在大多数语言方向上取得了最高的 BLEU 和 COMET 分数。单语预训练模型的多语言能力：单语模型也展示了强大的多语言翻译能力，甚至在无监督数据情况下也能有效对齐多语言（Garcia et al., 2023）。（2） 语言间翻译能力的不平衡翻译英文效果优于非英文：表1显示，各语言模型在翻译成英语时效果最佳，非英语翻译的表现较弱。对于与英语相近的语言（如印欧-日耳曼语族），LLMs 表现突出，而对于与英语差异较大的语言（如汉藏语族），效果较差。非英语中心翻译的挑战：GPT-4 在法语和中文为中心的翻译任务中，面临比英语为中心更大的挑战，表明其跨语言能力存在不平衡。（3） 与强监督基线的差距低资源语言上的不足：虽然 GPT-4 在40.91%的翻译方向上 BLEU 分数高于 NLLB，显示了新的翻译范式的潜力，但在低资源语言上仍落后于 NLLB 和 Google Translate。（4） 数据泄露问题的影响公共数据集评估的局限性：BLOOMZ 模型在 FLORES-101 数据集上的表现未被纳入，因为它使用了包含 FLORES-200 的 XP3 数据集进行微调，可能导致数据泄露。新数据集验证：通过使用 2023年8月至10月的最新新闻构建无泄露评估集 NEWS2023，测试显示 BLOOMZ 在无泄露数据集上的表现明显下降，而其他模型保持稳定。这表明在评估 LLMs 时，应考虑潜在的数据泄露问题。5、Analyzing Factors That Influence LLM’s Translation Performance第五部分：深入分析 LLM 翻译能力的影响因素5.1 预训练语料规模的影响资源效率高：LLM 通过极少的非英语语料即可构建英语与非英语间的双语映射。以 XGLM-7.5B 为例，低资源语言如加泰罗尼亚语（Catalan）和斯瓦希里语（Swahili），在其语料占比不到英语的1%的情况下，仍能生成中等水平的翻译。无监督语言翻译：即使对于未见过的语言，如奥克西坦语（Occitan）和阿斯图里亚斯语（Asturian），XGLM 也能通过上下文学习（ICL）进行翻译，展示了这种新型翻译模式在资源有限环境下的潜力（见图3）。为什么用XGLM？（1）XGLM 以多语言为重点，涵盖多种语言，可以看作是多语言 LLM 的代表。（2）XGLM-7.5B 是一个开源的中型 LLM，使用它进行实验比其他 LLM 或闭源 LLM 更经济实惠。（3）XGLM 的预训练语料组成清晰，可以让我们分析翻译能力与语料规模之间的关系。 5.2 上下文模板的影响模板设计至关重要：模板的选择显著影响翻译性能。不同模板的平均 BLEU 分数差异高达 16 分。其中，“=”模板的表现最佳，而“[SRC]: \n [TGT]: ”模板表现最差，尽管后者在其他模型（如 PaLM 和 GLM）中常用（见表4）。非合理模板也有效：即使使用如“ can be summarized as ”这样的非翻译任务模板，LLM 仍能生成准确的翻译。这表明，目前对上下文模板在 ICL 中的作用机制仍缺乏深入理解。(For example, the template like “ can be summarized as ” can also instruct LLM to generate translation, rather than guiding it to generate summarization. Given the fact that these unreasonable template are also effective, the community may not fully understand the role of in-context-template5.3 上下文示例的影响跨语言示例（cross-lingual exemplars）是指一种用于上下文学习（In-Context Learning, ICL）的策略，通过在提示中引入不同语言对的翻译示例，来引导大语言模型（LLM）完成翻译任务。其核心思想是，尽管示例语言与当前翻译任务的语言对不完全匹配，但这些示例仍然可以为模型提供有效的翻译模式或任务指令。跨语言示例的潜力：对于低资源语言的翻译，跨语言示例有助于提升表现。例如，使用跨语言示例进行中英翻译，性能往往显著提高，但在德英翻译中则有所退步。这表明跨语言示例在特定翻译方向上具有潜在优势。语义相关性并不显著：通过随机选取与语义相关示例相比，翻译性能几乎无差异。即使是高质量示例池，随机选择的效果也与“理想选择”相当，说明 LLM 能从示例中学习翻译任务的核心特征，而非依赖于语义相似性（见图6）。ICL示例对翻译任务核心特征的影响语义一致性至关重要：当上下文学习（ICL）示例使用不匹配的翻译时，LLM无法正确完成翻译任务，说明模型需要从示例中学习如何保持源语言和目标语言句子的语义一致性。翻译粒度的影响：使用词级别或文档级别的翻译示例会降低模型性能，表明示例的翻译粒度对于任务效果有显著影响。粒度过大或过小都可能导致信息过载或不足。多样性的重要性：重复的示例会导致模型表现变差，表明多样化的示例能更有效地引导模型学习翻译任务的本质。示例位置对 LLM 的影响：翻转提示尾部的示例顺序对 LLM 影响更大，性能下降更明显，表明尾部示例对 LLM 行为的影响力更大（见表6）多样性对性能的影响：重复示例会降低翻译性能，因此确保示例的多样性同样至关重要。（When more exemplars are added, e.g., 32 exemplars, the BLEU score usually starts to decline, shows an opposite phenomenon against the observation in natural language understanding tasks (Li et al., 2023).）LLM 的翻译能力受语料规模、上下文模板与示例选择等多方面影响，尤其是模板与示例的合理设计对于提升翻译性能至关重要。 7、 结论本文评估了包括 ChatGPT 和 GPT-4 在内的主流 LLM 在102 种语言和 606 个翻译方向上的多语言翻译能力，总结出其在多语言机器翻译（MMT）中的优势与挑战。优势：GPT-4 在翻译性能上达到了新的高度，尤其在高资源语言翻译中表现优异。挑战：即使是 GPT-4，在低资源语言上的表现仍存在不足。新模式：LLM 在 MMT 中表现出新的工作模式，例如：在上下文学习中可能忽略指令语义。跨语言示例对于低资源语言的翻译任务指导效果更好。资源效率高：LLM 能以较少的资源获得翻译能力，表明其在多语言机器翻译中的未来潜力。8、此次研究的局限性主要评估了以英语、法语和中文为中心的翻译能力。未来计划扩展到其他翻译方向，如俄语和阿拉伯语为中心的翻译，以进一步探索 LLM 在不同语言环境中的翻译能力，期待更多发现。
明德大学蒙特雷国际研究学院（MIIS TLM）申请过程记录
申请时间线： 2023.12 - 2024.2 小米实习 2024.4 开始准备托福、完善个人项目、丰富简历、找下一段实习 2024.5 - 2024.11 百度实习，2024.6 托福考试（105: 阅读30/听力27/口语24/写作24） 2024.8 开始准备网申材料 2024.9.3 网申通道开启，9.30通道关闭，9.28提交相关材料，提交后收到LST（语言能力测试）链接 2024.10.3 完成LST Part 1，10.4 完成LST Part 2和Part 3 2024.10.12 收到面试邀约，10.17 00:30 - 00:45 面试 2024.10.18 邮件通知申请通过，advisor再次询问track选择意见 2024.10.22 收到offer，一年制Advanced Entry + 奖学金 $14,000 2024.11 字节实习，这个申请的时候只是提了一下已经拿到了入职offer，用没用上不太清楚接下来是之前收到学弟学妹的提问频率较高的一些问题，单独列个板块解释一下，供大家参考：1、托福备考相关（因为对之后申请任何一个学校都有帮助，所以这部分就详写一下，分享下自己的一些备考策略，仅作参考）写在前面：强烈建议先约考试，可以督促自己学习:)我正式开始刷题大概是在3月底，感觉留4个月时间准备差不多就足够了，战线可以不用拉的太长，不然对身心其实都是一种折磨……相较于写作和口语，阅读和听力感觉咱们专业的同学底子都挺好，可以不刻意去花大量时间放在这部分的训练上，每天刷几篇真题磨磨耳朵，保持下做题的手感和速度即可。写作和口语的话个人感觉可能会是很多本专业同学的薄弱点，需要耐心准备下。首先是写作，在2024年托福改革后，写作部分改为学术讨论和综合写作两个部分，学术讨论个人感觉其实主要还是难在对时间的把控上，如果不进行针对性的训练，10分钟完成一篇约150字左右的观点陈述类文章，并且能够用清晰的逻辑去完整地表达出自己的想法，其实是不太容易的，所以在平常练习时可以着重记忆一些常用的句型及表达方式，还有一些万用的逻辑联结词。他们可以让自己在真正考试的时候很快地将观点和逻辑梳理成型，做到在短时间内就能写出一篇观点鲜明且逻辑清晰的应试文章。对比学术写作的分秒必争，综合写作在时间上就稍显宽裕许多了，30分钟内完成一篇约300字左右的文章即可，而且基本上考察的要点和观点叙述的方式都是固定的，所以可以以不变应万变，大家做几套真题自己就有体会了。口语的话是机考，共4道题，每道的主题和考试的题型其实都是固定的，但每个题目都有其要求的作答时间，30s-60s不等，个人感觉口语部分的关键在于是否能够快速构思并组织出尽可能流畅的语言，同时完整表达出自己的观点，可通过多练习常用表达和句型来提升流畅度。哦对了，听力口语这两个部分也会涉及到很多要求对文章或讲座要点进行观点复述这样的题型，可以适当研究下口译笔记的速记法，或者整理一套自己能看得懂的符号笔记体系，进可能在短时间内记下来较多的信息。这里po几个自己备考时用过的好用的免费工具：免费真题库： （1）新东方托福 （2）www.toefl100.cn （注：新东方托福因为版权原因前30套不能做了，在备考初期可以先从最新的往前刷，这个阶段用新东方的好处是可以研究一下参考答案及解析的解题技巧和表达方式，起到定个方向的作用；熟悉了题型和答题技巧之后，用toefl100里较全的真题库再刷题，感觉效果会更好。）写作： （1）B站Vince9120 （给的题型解析很细致，整理的一些表达模版和思路很值得学一学）（2）一些AI帮评分和润色修改的网站（大多数都是订阅制，不想交智商税的话可以自己diy，写几个prompt交给gpt 类似于“打分+挑语法错误+修改建议+参考范文”这种流程）阅读/听力： 这两个部分短时间内感觉不太好提上去，除了在学校期间上语言类课时好好听课，跟着老师练习以外，还是需要在私底下里坚持大量输入输出吧，平时可以在上课摸鱼、通勤或者其他碎片时间背背单词、听听听力磨磨耳朵这样，在决定开始准备托福考试的时候就可以开始坚持一直这样做了，当然了，这些基础的不能再基础的训练，越早开始越好，从大一开始坚持，受益终生（bushi）。2、网申材料准备相关：网申通道开启后，要提交以下几种材料，强烈建议好好花时间认真准备下：CV (确保能突出你在翻译和本地化领域的经历)本科成绩单PS/Career Objectives Essay (阐明为什么选择TLM以及如何与职业目标契合)推荐信：两封推荐信（赞美伟大的韩老师和尼老师！！！）Scholarship Application EssayFinancial Situation Statement3、LST考试相关（凭记忆复盘一下考试的题型，不全）Part 1: 听力阅读B-Language自我介绍很基础的听力和阅读测试（都是中和英各2篇），难度和托福考试差不多，很友好。Part 2：同语复述 + 写作 + 即兴演讲（最烧脑的一集 :sweat_smile:）听听力（约2min）+复述（英2篇，中1篇）阅读文章复述（英2篇，中1篇）写作（30min）英中各1篇，英400词，中500字前，英文给题目会很离谱，我抽到的是简述你认为“一个国家如何从内战中复苏”。即兴演讲 （英2个，中1个），准备2min，说3minPart 3: 口笔译（最最最烧脑的一集 :sweat_smile:）笔译：E - C 2篇，20分钟左右；C - E 2篇，15分钟左右交传：E - C 2篇 + C - E 2篇，15分钟左右；都是听3min，口译3min考试总时长大概5h左右，每个Part之间可以退出，建议分2-3次考，有益于身心健康。4、 面试相关：收到面试邀请，基本上可以松口气了，offer已经稳了一大半了。面试前准备下自我介绍和一些基础的礼节性的small talk，再熟悉一下自己之前提交过去的项目经历和未来规划，基本上就够用了。面试是以聊天的形式进行，非常友好，会穿插问几个问题（问了我“未来职业的规划“、”选择MIIS的原因”、“阐述你的三个优势”这三个问题）面试官很nice，整个过程也很轻松，最后会给反问问题的机会，我当时问的好像是有关之后就业学校可以提供的资源还有往届毕业生去向等相关问题。5、网申AE时要回答的一些额外问题（部分）：工作和项目经历：详细列出你曾在本地化行业内担任过的角色、平时工作涉及到的内容及工具使用，如果有翻译经历的话还会让你统计自己的翻译量、处理的需求、以及工作时长等。工作中遇到的印象深刻的问题：围绕你的行业内经历，分享你在工作中遇到的挑战和有趣的故事，可以突出你的应变能力和解决问题的技巧。CAT或CMS工具优化：提供一些关于如何优化翻译工具的创意和建议，会问“如果让你来设计一个相关工具，你会额外考虑增添或删改哪些功能？”之类的问题。注：这里很反人类的一点是每个text box都有字符数限制，准备答案的时候语言表达要近可能简练直接一点，要不然反复修改答案会很浪费时间。写在后面：最后还是想感谢一路以来老师及学长学姐们的帮助，没有你们的帮助和耐心解惑，我肯定不会这么顺利的走完这段旅途的。感谢韩老师、尼老师平日里的指点以及分量十足的推荐信，也感谢彦霖学姐、昊洋学长、槟源学姐、刘文韬老师给过的帮助！特别喜欢高翻大家互帮互助的氛围，写这篇经验贴也是想把之前自己受到过的点滴帮助给传递下去，希望学弟学妹们都能申到自己心仪的学校，也希望咱们的高翻越来越好！！！
首先是对字幕所参考译本的判断，因为之前读过朱生豪先生译的《莎士比亚悲剧集》，于是这次便被“所以留心吧，戒惧是最安全的方策；即使没有旁人的诱惑，少年的血气也要向他自己叛变”这句经典的台词唤起了尘封许久的记忆。重温了一遍后，又一次被莎翁文字中的流出的激情和浪漫所深深打动。不过既然是翻译鉴赏，那就还是要聚焦在语言本身。我们先从格式入手，从字幕的格式上来看，电影对原著文本的改动无疑是颠覆性的，就比如开头首字母不再大写，添加标点符号以对句意进行再次分割等。从方便观众理解这一层面上讲，虽然相较于原剧本可能缺少了一些年代感和风格美，但这是可以理解的。因为在莎翁那个时代，这种写作的风格被视为一种正式的、尊重的表达方式，它强调每个字母在组成句子中所具有的重要性，也给整部剧本带来一定的规范性和整洁度。但一旦将剧本搬至舞台，故事传达和情感传递的精准与否就变得更为重要了。而朱生豪先生的译本，同样也打破了这种写作格式的限制，并取代之以中文写作中常见的排比、对仗等修辞技巧，从而绝大程度上保留了原剧本的节奏感和韵律感。这种翻译的技巧是值得我们去反复品味的。接下来着眼于内容，我将分别把部分译文字幕同朱生豪先生的原译本内容进行对比，列举几例，并尝试在其中寻求合理之处和自认为略有瑕疵的地方。For nature crescent does not grow aloneIn thews and bulk, but as this temple waxes,The inward service of the mind and soulGrows wide withal.字幕：一个人成长的过程，不仅是肌肉和体格的增强，而且随着身体的发展，精神和心灵也同时扩大。朱：因为像新月一样逐渐饱满的人生，不仅是……此处的差别在对crescent一词的处理上。从译文对原文的忠实度和来看，显然后者更胜一筹，而从内容上来看，前者的优点无疑在便于理解且更为通俗。但就莎翁戏剧的语言特点来说，过分的通俗实际上会破坏其语言的美感，及其文字背后所潜藏的丰沛的情感。Then if he says he loves you, It fits your wisdom so far to believe itAs he, in his particular sect and place,May give his saying deed, which is no furtherThan the main voice of Denmark goes withal.字幕：所以要是他说，他爱你，你不可贸然相信。照他的身份地位说来，他要想把自己的话付诸实现，绝不能越出丹麦国内普遍舆论所同意的范围。朱：所以要是他说，他爱你，你应当想一想，以他王子之尊究竟能做到几分，那必须以丹麦的公意给他的赞同为限的前者行文过于拖沓与生硬，且“把自己的话付诸实践”和“绝不能越出……舆论所能同意的范围”也不太符合汉语的表达习惯。相比较而言朱生豪先生的表述就显得更自然一点，而且前文所点出的“王子之尊”也使后文对民意的描述不再突兀。A double blessing is a double grace.字幕：两度的祝福是双倍的福分。朱：两度的祝福是双倍的恩荣。汉典中关于“恩荣”一词的释义这样写道：谓受皇帝恩宠的荣耀。倘若从这一角度出发，后者处理的方式似乎有些许不妥，同雷欧提斯的父亲波洛涅斯是御前大臣这一事实相违背。但如果结合后文中雷欧提斯称父亲为“my lord”，处理为“恩荣”又有其相对应的道理。故此处存疑。最后想赏析一下自己认为朱生豪先生译得很棒的一句。Be wary then, best safety lies in fear; Youth to itself rebels, though none else near.所以留心吧，戒惧是最安全的方策；即使没有旁人的诱惑，少年的血气也要向他自己叛变。除去“信达雅”兼具以外，此句译法的闪光点自认为还有三处。首先是对“fear”的处理，并未简单译作“恐惧”，而是“戒惧”，一个“戒”字把雷欧提斯对妹妹的控制欲表现得淋漓尽致；其次是增译的“诱惑”一词，暗示雷欧提斯心中对于哈姆雷特的厌恶和反感，丰富了人物的心理活动与态度；最后是将“youth”处理为“少年的血气”，将抽象概念所表达的含义范围进一步缩小，并且还强调出少年所独有的一种精神上的特质。参考:·https://myshakespeare.com/hamlet/act-1-scene-3·《莎士比亚悲剧集》（上） 朱生豪译 作家出版社 2018年6月重印·The Language of Capitalization in Shakespeare's First FolioTritt, Carleton S. Visible Language; Detroit, Mich.. etc. Vol. 7, Iss. 1, (Winter 1973): 41-50.·https://www.zdic.net/