将网站翻译成希伯来语：从右到左排版、性别与现代拼写规范

希伯来语网站本地化：从右到左（RTL）标记、不带元音点的拼写规范、区分性别的界面文案及 he 语言版本的 SEO。

Grant Davies更新于

将网站翻译成希伯来语：白色网格上，一张从右向左排列、带有 niqqud 元音点的希伯来字母方块卡片，配有 /he 标签

如果你的项目要求是“将网站翻译成希伯来语”，就别再把希伯来语当成只是换了字母的阿拉伯语。网页上的希伯来语涉及从右向左（RTL）布局与多文字体系混排的问题：页面必须从右向左排列，英文产品名称和数字必须作为从左向右排列的独立片段保持可读，而现代界面文案几乎都不标注元音点。

本文是一份希伯来语（he）网站版本上线指南，涵盖语言区域选择、排版方向与镜像布局、可抓取的 URL、结账流程质量检查（包括发票和电子邮件）、机器翻译译后编辑（MTPE）与人工审校的取舍、SEO 常见误区，以及一份可实际执行的检查清单。

将网站翻译成希伯来语，除了替换字符串，还需要做什么？

除了处理 CMS 字段，你还需要建立一套流程：通过标记设置文档方向，确保模板、电子邮件和 PDF 中的希伯来文字、拉丁文字与数字混排顺序正确，为状态文案中的动词和形容词制定性别表达规范，提供一个正文确实为希伯来语的独立 URL，并在任何人开始处理文件之前确定拼写规范（默认不标注元音点）。

本指南将解答的问题

  • 将网站翻译成希伯来语，除了替换字符串，还需要做什么？
  • 应该选择哪种希伯来语语言区域或地区变体？
  • 希伯来语有哪些特有的文字、字体排印和布局问题？
  • 希伯来语网站版本的 URL、hreflang 和索引应如何设置？
  • 希伯来语新用户引导和结账流程有哪些需要注意的细节？
  • 希伯来语应该采用 AI 翻译、机器翻译译后编辑，还是人工审校？
  • 哪些 SEO 错误会对希伯来语页面造成特别大的影响？
  • 如何上线希伯来语网站版本并衡量其表现？

快速解答：如何正确地将网站翻译成希伯来语

要让希伯来语版本稳定上线并便于长期维护，应做到以下几点：

  1. 在 HTML 中设置基础方向（在文档上使用 dir="rtl"，并在拉丁字母产品名称和连续数字上使用 dir="ltr"）。仅靠 CSS 实现镜像布局不能替代方向标记。
  2. 为 he（通常为 he-IL）提供独立、可抓取的网址，而不是仅靠 Cookie 切换语言。
  3. 使用真实的希伯来语文案制作导航、卡片、结账流程、电子邮件和发票原型，让文字截断、控件镜像和双向文字顺序错乱等问题在上线前就暴露出来。
  4. 界面文案默认使用不标注元音点的希伯来语。除非教学用途或品牌风格明确要求，否则不要为了“帮助学习者”而随意添加 niqqud 元音点。
  5. 在扩大规模前，先配置相互指向的 hreflang、指向同语言页面的 canonical，以及站点地图。
  6. 将产品名词、性别表达策略和“保留英文”的术语录入术语表，避免机器翻译译后编辑过程中在不知不觉间改变语体或语法性别。

CSA Research 对 29 个国家的 8,709 名消费者进行的调查发现，76% 的受访者更愿意在提供母语信息的情况下购买，40% 则从不在其他语言的网站上购物。即使许多以色列用户也能阅读英语，这一点依然成立：结账、发票和客服环节，正是纯英语体验容易导致订单流失的地方。Google 的实用内容指南提倡以用户为本的页面；只有导航翻成希伯来语、正文却仍是英语，并不是合格的本地化版本。关于市场与语言两种策略的区别，请阅读国际 SEO 与多语言 SEO 有何不同。

选择合适的希伯来语语言区域

如果以色列是首个商业目标市场，大多数团队应推出 he 版本，并采用面向以色列的 he-IL URL。这是合理的首发方案。但这并不意味着可以把带元音点的礼拜用希伯来语、充斥俚语的聊天用语，以及夹杂大量英语的初创企业式文案放进同一个文件，就称其为“希伯来语版本”。

现代以色列希伯来语采用统一的书面标准，但存在语体差异，例如日常产品文案与正式法律用语。你仍然可以从第一天起，就在架构设计上采用单一的 he 文案文件。但不要以为军队式的正式术语表自然适合面向消费者的结账流程，也不要把充满俚语的营销首页文风用在银行的错误提示中。

Niqqud（元音点）在现代界面中很少使用。不标注元音点的希伯来语才是网站、应用和电子邮件的常态。“为了清晰”而添加元音点，往往会显得古旧、杂乱，或像儿童读物。请在项目说明中明确这条规范：除非有明确列出的例外，否则不标注元音点（例如语言学习产品）。

还要确定如何处理姓名、地址和电话号码。即使文案看起来已经“翻译好了”，如果表单拒绝希伯来字符、强制姓名只能使用 ASCII 字符，或默认采用西方先名后姓的顺序，仍然会出问题。以色列的电话号码和邮政格式也应写入语言区域说明。

性别表达也是语言区域策略的一部分。希伯来语的动词和形容词往往带有语法性别。应在模板将阳性形式写死为默认值之前，与母语语言专家确定采用包容性措辞、同时列出两种性别形式，还是精心选择句式来处理。

希伯来语文字、字体排印与布局细节

希伯来语使用独立的文字体系，阅读方向为从右向左。W3C 建议通过 HTML 标记设置基础方向（在文档以及需要相反方向的独立片段上使用 dir），而不是仅靠 CSS 技巧。在 RTL 页面中，嵌入的英文产品名称、SKU 和许多数字字符串仍需从左向右排列。如果没有为这些片段单独设置方向，“GlotEO 2.0”和发票总额的顺序就可能错乱，看起来像数据损坏。

避免上线当周就被截图反馈问题的布局规则：

  • 使用真实的希伯来语文案制作关键页面原型，包括较长的复合词、不标注元音点的标题，以及混排的拉丁字母品牌名称。
  • 有意识地对交互模式进行镜像调整，包括分步向导、媒体轮播、返回控件、时间线、检查清单和表示“进度”的尖括号箭头。RTL 页面上的返回箭头如果指向左侧，那是产品缺陷，而不是风格选择。
  • 允许按钮文字换行，不要为了保留英语行动号召文案的单行布局而缩小字号。
  • 在界面、电子邮件和 PDF 中部署支持希伯来文字的正式字体。以拉丁文字为主的字体栈会回退到其他字体，让界面显得尚未完成。
  • 留意卡片标题、徽标和表格表头，这些地方最容易先暴露文字裁切和对齐方向错误的问题。
  • 将带有方向含义的图标（播放、分享、面包屑导航）视为语言版本的一部分，而不是“全站通用界面元素”。

日期和数字也是布局规范的一部分。以色列用户通常习惯在行文中使用日—月—年的日期顺序；面向当地销售时，应使用 ILS 货币格式，并让电话字段接受本地号码格式。按英语 ASCII 顺序排列希伯来语列表，并不能算作合理的排序规则。

带有性别变化的状态文案也会影响文字宽度。例如“你已受邀”这类文案，会因语法性别不同而变长。设计模板时应为较长的形式留出空间，不要假设同一条英语源文案对应的希伯来语宽度始终相同。

可抓取的 URL、hreflang 与索引

Google 建议为每个语言或地区版本提供不同且可抓取的 URL，而不是仅依赖 Cookie 或浏览器语言。Google 主要根据可见内容判断页面语言，因此，如果只有导航被翻译、正文仍为英语，就算不上完善的希伯来语版本。为希伯来语设置独立目录或主机名模式（/he/、/he-il/），并在模板、分析工具和内部链接中保持一致。如果希望这些 URL 能在希伯来语搜索中被识别为希伯来语版本，相应页面就需要可抓取的 URL，以及以希伯来语为主的主要内容。

你所声明的各替代版本之间，hreflang 标注必须相互对应。每个语言区域 URL 都应设置明确的 canonical；存在重复页面时，应优先指向同一语言的首选 URL。不要将希伯来语页面的 canonical 指向其英语对应页面。

Bing 网站管理员指南强调内容应可抓取、有用，且网站结构清晰。Google 建议不要根据推测的语言或位置自动重定向用户，而应提供醒目的语言选择器，链接到希伯来语 URL。通过 IP 猜测并执行“以色列 → /he”跳转，会给旅行者、VPN 用户和抓取工具造成困扰。

URL 规范和页面内容规范可以不同：出于运维需要，你可以对 URL 路径名进行百分号编码，或将其转写为 ASCII 字符，但页面标题、H1 标题和正文仍应使用希伯来文字。为方便运维而转写路径名，同时又在 /he/ 下发布英语正文，这并不算一个语言版本。如果转写路径名，就应统一设置重定向；不要在未设置 canonical 的情况下发布两个相互竞争的希伯来语 URL。

用目标语言做好新用户引导、信任建设和结账体验

希伯来语信任相关页面的作用，比一份翻译后的功能清单更大。面向以色列销售的网站，通常需要隐私政策、条款，以及适用时的付款和售后说明；这些内容应读起来像完整、正式的页面，而不是遗留下来的英语模板。这不是提升排名的技巧，而是用户判断结账流程是否可信时会查看的内容。请将这些页面列为本地化重点。

棘手的问题往往出现在站外。收据、PDF 发票、密码重置邮件和短信验证码中的双向文字混排，可能导致希伯来文字、数字和拉丁字母产品名称顺序错乱。用户验收测试应涵盖这些内容，而不只是营销首页。即使店铺页面显示正常，只要发票上的 ₪001.99 顺序出错，仍会损害用户对结账流程的信任。

提升希伯来语转化效果的实用检查项：

  • 首页、广告和产品界面的语体保持一致（日常用语或正式法律用语）。
  • 姓名和地址表单接受希伯来字符；如果必须使用拉丁字母，则说明原因。
  • 在实际横幅中审校 Cookie 和同意授权文案；这些文字通常较长，在 RTL 布局中容易出现换行问题。
  • 定价、发票和货币相关表述与您声称服务的市场相符。
  • 客服快捷回复和事务性邮件保留 RTL 标记，并使用不标注元音点的拼写形式；采用所谓“安全 ASCII”邮件模板会让本地化体验出现缺口。
  • 错误提示明确说明解决方法，而不是只有客气却空泛的道歉，同时遵守性别表达规范。
  • 混排的拉丁字母 SKU 和希伯来语原文输入，都需要在移动端进行质量检查。

你不必在上线第一天就翻译所有博客文章，但必须准备好首页、产品说明、身份验证、定价、结账、基本隐私说明、客服入口，以及当地市场所期待的法律页面。部分以色列用户会阅读英语文档，但仍有相当一部分用户不愿用英语完成结账或寻求支持，因此，纯英语体验仍会造成销售损失。

西班牙语的 AI 翻译、机器翻译译后编辑与人工审核

希伯来语应该采用 AI 翻译、机器翻译译后编辑，还是人工审校？应根据风险选择工作流程，而不是根据工具品牌：

  • 未经编辑的机器翻译：仅适合用作内部草稿。模型会擅自加入元音标记、混淆语法性别、用希伯来语词汇套用英语句法，还会打乱数字与名称混排字符串中的双向文本顺序。
  • MTPE（机器翻译＋译后编辑）：对于许多产品页和支持页面，这是稳妥的默认方案，前提是术语表已锁定产品名词及需保留英语的术语，并且设有语法性别和正字法检查。
  • 人工翻译／品牌文案编辑：适用于首页、价格页、营销活动、Cookie／同意授权内容，以及任何涉及法律事项的页面。

实用的希伯来语审核流程：依据术语表进行 MTPE（默认不加元音标记、明确语法性别策略、锁定英语产品名称）；由品牌编辑审核首页和定价页；由语言专家审核错误提示、账单及涉及语法性别的状态文本；最后在预发布环境中，以移动端屏幕宽度开展质量检查，涵盖双向混排的邮件和 PDF。发布前还应检查 he URL 下是否存在正文以英语为主的页面，以及界面字符串中是否出现了不应有的元音标记。

以用户为本、提供实用内容的要求适用于所有语言。仅靠机器翻译生成的希伯来语页面，在 CMS 中可能看似完整，却仍无法满足用户需求。

希伯来语 SEO 的特有误区

使用希伯来语搜索的用户需要的是自己能读懂的语言。请使用希伯来文字开展希伯来语关键词研究，再撰写符合希伯来语搜索结果表达习惯的标题和 H1 标题。为每个希伯来语 URL 分别本地化标题、元描述和各级标题，不要重复使用同一套英语元数据。

以下错误尤其会损害希伯来语页面的体验和表现：

  1. 仅支持从左到右（LTR）排版的模板，从未在标记中设置 dir="rtl"。
  2. 英语产品名称和连续数字缺少独立的 LTR 区域。
  3. 面向消费者的界面中使用元音标记，显得过时或杂乱。
  4. 忽略语法性别的模板，使所有状态文本都默认使用阳性形式。
  5. 页面其他内容已采用希伯来语，界面元素却未做镜像适配（返回、时间线、检查清单等）。
  6. 仅翻译通用模板内容——界面是希伯来语，正文仍是英语。
  7. 仅依赖 Cookie 切换语言，导致爬虫无法发现希伯来语 URL。
  8. hreflang 配置错误（缺少反向链接）。
  9. 基于地理位置的自动重定向，让用户和爬虫被困在特定版本中。
  10. 希伯来语 URL 上的规范链接指向英语页面。
  11. 将邮件、短信和 PDF 中的双向文本显示问题视为“不在处理范围内”。
  12. 仅靠机器翻译、内容单薄的地区版本，达不到实用内容要求。

在扩大内容规模之前，先解决文本方向、字体、语法性别策略和架构问题。工具应帮助落实流程，而不是凭空许下排名承诺。

上线检查清单

准备发布希伯来语版本时，请使用以下检查清单：

GlotEO 如何发挥作用

希伯来语非常适合使用翻译记忆库：产品名词会反复出现，英语保留列表中的术语必须保持拉丁字母形式，而语法性别和正字法规则也不应随着下一批英语内容的到来而发生偏移。网站本地化平台中的术语表和翻译记忆库，能让经过布局测试的字符串顺利发布，同时保持适配文本方向的文案、语体和功能名称一致。再配合多语言 SEO 工具，即可在扩展过程中持续审核希伯来语 URL、hreflang 和元数据。规划首个 he 版本的发布范围时，可以比较 GlotEO 的价格与套餐；如果你还在选择目标语言，也可以先从更全面的网站翻译工作流程入手。

当依赖 Cookie 的语言切换和未标注的机器翻译草稿已无法确保 he 安全发布时，不妨了解 GlotEO 网站本地化。

参考文献