罗马尼亚语SEO和别的拉丁语族反着来，定冠词是接在词尾上的

摘要：罗马尼亚语用拉丁字母，属于罗曼语族，看着应该和西班牙语、意大利语一个路数。真做起来第一批选词就会错：这门语言的定冠词不写在名词前面，而是粘在词尾上，一个名词至少四种写法；它还留着格的残余、留着一类单复数换性别的中性名词；更麻烦的是ș和ț在Unicode里有两套码位，同一个词能存出四种字节序列。这篇把这些坑逐个拆开，给出选词表、模板规则和审校清单。

罗马尼亚语在拉丁语族里到底特殊在哪？

接手一个准备进罗马尼亚市场的灯具站时，最省事的判断是把西班牙语那套流程复制一遍。

字母表是拉丁的，词汇里有大量能一眼认出来的拉丁词根，连语法术语听着都熟。

然后你把第一版关键词表交给本地同事，对方圈出来的问题会集中在同一个位置：词尾。

罗曼语族里，法语、西班牙语、葡萄牙语、意大利语的定冠词都写在名词前面，是独立的一个词。

罗马尼亚语不是。它把定冠词接到名词后面，跟词根粘成一个词。

这一条不是语法课上的冷知识，它直接决定了你的关键词表要多准备几行，也决定了自动补全在这门语言上会怎么失灵。

除此之外还有格的残余、中性名词、两套码位的变音字符、一段反复过两次的正字法改革。这门语言在罗曼语族里像个走岔了路的亲戚。

语言学上把这一组特征叫巴尔干语言联盟，指的是几门亲缘关系不近的语言因为长期相邻而共享了同一批语法特征，后置定冠词就是其中最显眼的一条。

这条线索的实用价值在于：等你以后做保加利亚语或者阿尔巴尼亚语时，会发现词尾接冠词这套麻烦事又原封不动地回来了，处理方案可以直接搬。

为什么定冠词粘在词尾会改变整张选词表？

拿灯具站最常见的一个词举例：pantof是鞋，我们换成本行的bec，灯泡。

不带冠词的单数是bec，加了定冠词是becul；复数是becuri，带定冠词的复数是becurile。

四个形态里，词根bec只在前三个字符稳定，后面全在变。

用户在搜索框里打什么，取决于他脑子里那句话的语法位置，而不是取决于词典原形。

问“哪种灯泡好”，他打ce becuri；问“这个灯泡多少钱”，他打becul acesta。

这意味着单靠词典原形建的关键词表，天然接不住一大半真实查询。

更实际的影响是：同一个商品，标题里该用bec还是becul，取决于标题的句式，而不是取决于你的模板变量。

更彻底一点说，罗马尼亚语的名词根本没有一个可以脱离语境使用的中立形态，词典给的那个原形在真实句子里出现的频率其实并不算高。

所以选词表的第一列不该叫关键词，该叫词根，后面四列才是形态；这个改名不是文字游戏，它决定了下游的人会不会误以为第一列可以直接拿去写标题。

一个名词四种写法，前缀匹配会失效在哪一步？

搜索框的自动补全、站内搜索的前缀索引、商品筛选器的模糊匹配，绝大多数默认按前缀工作。

对英语这类词形稳定的语言，前缀匹配够用：打lam能带出lamp、lamps、lampshade。

罗马尼亚语的变化全在词尾，前缀匹配理论上应该更好使才对。

问题出在反方向：用户打的是带定冠词的形态，而你的索引里存的是原形。

打becuri匹配不到bec，因为bec比becuri短，前缀关系是反的。

补救办法有两条：给索引额外写入常见的带冠词形态，或者上一层轻量的词尾归并规则。

Snowball的罗马尼亚语词干算法专门处理了后置冠词与复数词尾，站内搜索接上它，能一次解决大部分匹配漏空。

顺带一提，这也是罗马尼亚语站的站内搜索零结果率普遍偏高的根本原因，很多团队查了半年前端和索引配置，问题其实全在词尾那两三个字符上。

不定冠词在前、定冠词在后，标题模板怎么拆？

罗马尼亚语的不定冠词是独立的词，写在名词前面：un bec，一个灯泡。

定冠词却在后面：becul，那个灯泡。

同一个名词，两种冠词跑到了句子的两头。

后果是标题模板不能只留一个占位符。你要么固定用无冠词形态，要么按句式分成两套模板。

实践里最稳的做法是：商品标题一律用无冠词形态，把冠词留给正文与元描述。

这样标题保持了关键词的检索形态，正文又能读得像人写的。

还有一种折中写法：标题主体用无冠词形态，句末补一个带定冠词的短语作为自然收尾，两种形态在同一个标题里各占一次，检索和可读性都不吃亏。

形容词要跟着名词改几次？

罗马尼亚语的形容词要和名词的性、数一致，这一点和意大利语同源，我在意大利语那篇里已经拆过一遍。

罗马尼亚语多了一层：形容词还会受定冠词位置影响。

bec economic是节能灯泡，becul economic是那个节能灯泡，形容词本身没变。

但当形容词提到名词前面时，定冠词会跑到形容词尾巴上：economicul bec。

这种语序在广告语和口号里很常见，在商品标题里很少见。

你需要知道它存在，是因为竞品的广告文案会用，而你的关键词工具会把它当成另一个词统计。

这类前置语序在罗马尼亚语里带有明显的文学腔和强调意味，商品页硬用会显得用力过猛，但在品牌slogan和促销活动名里反而是加分项。

中性名词是怎么回事？单数算阳性，复数算阴性

罗曼语族大多只有阳性和阴性两个性。

罗马尼亚语有第三类，语法书叫中性，也叫两可性名词。

它的规则很直白：单数时按阳性搭配形容词，复数时按阴性搭配。

bec就是一个中性名词。un bec economic，单数按阳性；două becuri economice，复数按阴性，形容词词尾跟着换。

这类词在商品名里的占比不低，桌子、灯、窗户、盒子、包装，全是中性。

如果你的标题模板只按“性别”字段拼形容词，中性名词一定会拼错一半。

这类词在语法书里的正式名称是两可性名词，意思是它并不真的存在第三种性，只是在单数和复数两个数上分别倒向了两边，这个理解方式比死记中性两个字有用。

商品属性字典要按几个维度建？

被中性名词坑过一次之后，正确的做法是把名词的性拆成两个字段。

一个字段记单数搭配用什么性，另一个记复数搭配用什么性。

阳性名词两个字段都是阳性，阴性名词两个都是阴性，中性名词是阳性加阴性。

形容词字典则要存四个形态：阳性单数、阴性单数、阳性复数、阴性复数。

拼装规则变成：按当前是单数还是复数，取对应字段的性，再去形容词字典里取词。

这个结构一开始看着啰嗦，但它是唯一能自动跑对中性名词的写法。

字典建好之后还要加一条校验：任何名词如果单数字段和复数字段的值不同，就必须被标记为两可性名词，这样新词入库时不会因为录入的人不了解语法而漏标。

再往前一步，这套字典还能顺手解决单位与量词的搭配问题，罗马尼亚语在计数时对某些名词有固定的搭配写法，一并存进去比事后打补丁划算。

复数有三条路线，选词表要覆盖到哪一档？

罗马尼亚语名词的复数词尾主要是三种：i、e、uri。

阳性名词大多走i，阴性名词大多走e，中性名词大多走uri。

“大多”这两个字里藏着全部的麻烦，例外多到不能靠规则推。

更麻烦的是复数化经常伴随词干内部的音变：mână到mâini，词根里的元音也变了。

选词表的处理办法只有一条：高频商品词逐个查词典确认复数，别让脚本猜。

dexonline的bec词条直接给出完整的变格表，包含四个形态，逐词核对比任何自动化都快。

另一个容易被忽略的细节是，同一个词在不同义项上可能走不同的复数路线，一个词既指实物又指抽象概念时，两个义项的复数形式经常分道扬镳。

uri这个词尾从哪来，为什么工具经常切错？

uri这个词尾来自拉丁语中性名词的复数形式，这条线在其他罗曼语族语言里基本断了。

它是罗马尼亚语独有的一条形态遗产，也是最容易被通用工具误判的一个词尾。

很多多语言分词器会把uri当成一个独立的后缀切掉，切完剩下的词根有时候不成词。

更常见的错误是把它和土耳其语借词的词尾搞混，罗马尼亚语里确实有一批土耳其语借词。

判断办法很土但有效：拿站内搜索日志里出现频次前两百的词，人工看一遍切分结果。

切错的那些通常集中在同一类词尾上，改一条规则能修一片。

从检索的角度看，uri结尾的词还有一个副作用：它让复数形式比单数长出三到四个字符，商品标题的字符预算要按复数形态来算，不能按单数估。

名词的格还剩多少？

拉丁语的格系统在罗曼语族里几乎全部消失，只有罗马尼亚语留下了残余。

今天的罗马尼亚语名词有主格宾格合一的形态，和属格与格合一的形态，语法书叫斜格。

阴性名词的斜格形式经常和复数形式长得一样：casă的属格是casei，复数是case。

这一点会让基于词形的统计工具把两类完全不同的用法合并成一条数据。

做俄语那种六格语言时，这个问题我在俄语那篇里讲过得更细。

罗马尼亚语的量级小得多，但方向一样：工具给你的数字是若干种形态加起来的和。

实际操作里最省事的判断是：只要你的文案里出现了表示所属关系的结构，那个名词八成就得换成斜格形态，而这类结构在商品描述里出现得相当频繁。

顺便说一句，罗马尼亚语的斜格在带定冠词时形态又不一样，所以真正要记的是格与冠词交叉出来的那张小表，而不是单独的格表。

呼格还活着吗？它出现在什么文案里

罗马尼亚语还保留着一个呼格，用来直接称呼人或物。

domnule是先生的呼格形式，比domn多了一个词尾。

商品词几乎用不到呼格，但客服话术、邮件开头、弹窗文案会用。

忽略它不会掉排名，但会让本地用户一眼看出这段文案是机器翻的。

把常用称呼词的呼格形态整理成一张十来行的小表，交给写文案的人，成本几乎是零。

呼格在现代罗马尼亚语里正在退化，年轻一代口语中经常直接用主格代替，所以文案里用不用它其实也是一个语气选择，正式场合用，轻松场合可以不用。

ș和ț有两套码位，你的站可能同时存着两种

这是罗马尼亚语技术侧最贵的一个坑，也是同类文章几乎不提的一个坑。

罗马尼亚语正确的字母是s和t底下加一个逗号，码位是U+0219与U+021B。

但Unicode早期版本里没有这两个字符，只有底下带下加符的U+015F与U+0163，那本来是土耳其语用的。

于是从九十年代到两千年代中期，绝大多数罗马尼亚语文本用的是土耳其语那两个字符。

带逗号的版本要到Unicode 3.0才补进去，Latin Extended-B码表里能直接查到这两组码位并排列着。

字体厂商跟进又晚了几年，早期Windows上带逗号的字符经常渲染成空白方框。

这段历史留下的直接后果是：今天罗马尼亚互联网上的存量内容，大约有相当一部分仍然用着土耳其语那两个码位，而它们看起来和正确写法几乎无法用肉眼区分。

同一个词能存出几种字节序列？

把两套码位再乘上组合字符的可能性，数量就上来了。

s加下加符可以是预组合的U+015F，也可以是基础字母s加组合下加符U+0327。

s加逗号可以是预组合的U+0219，也可以是s加组合逗号U+0326。

四种字节序列，屏幕上看着几乎一模一样。

结果是你的商品库里可能同时存在四份“同一个”商品名，去重脚本一条都发现不了。

URL里出现不同的字节序列时，问题会升级成两个不同的页面。

检验自己站上有没有这个问题的最快办法，是拿一段包含ș的商品名做十六进制转储，看看落在磁盘上的到底是哪一串字节，屏幕上是看不出来的。

规范化该选NFC还是NFD？

解决办法是在入库前做一次规范化，把所有形态统一到一种。

UAX #15定义的四种规范化形式里，做网页内容一般选NFC，把组合序列合成预组合字符。

但NFC只解决组合与预组合的差别，它不会把带下加符的U+015F变成带逗号的U+0219。

那两个是不同的字符，规范化管不着，得额外写一条映射。

顺序是：先做字符映射把下加符版换成逗号版，再做NFC。

数据库、搜索索引、URL生成器三处都要跑同一套流程，少一处就等于没做。

还有一个容易漏的地方是用户输入：搜索框、评论区、地址表单收到的内容同样要走这套流程，否则用户提交的数据会成为新的污染源，几个月后又是一片混乱。

用î还是â？这门语言改过两次主意

罗马尼亚语里有两个字母发同一个音：î和â。

1953年的改革规定除少数例外一律写î，于是有了cuvînt、român这种混合局面。

1993年罗马尼亚学院又改回来，规定词中一律写â，词首词尾写î。

今天的正式文本写cuvânt，而1993年之前受教育的人手打时经常还是cuvînt。

两个拼法在搜索日志里会同时出现，比例随人群年龄变化。

正文一律按现行规范写，选词表里把旧拼法当同义词收进来，这是成本最低的处理。

这场改动的背景是政治的：1953年那次改革要弱化罗马尼亚语与拉丁语的视觉联系，1993年恢复â则是要把这条联系重新亮出来，字母在这里承担了身份表达的功能。

用户到底打不打变音符号？

这个问题在带变音符号的语言里反复出现，越南语那篇里我按两拨人来分，罗马尼亚语的分法不太一样。

罗马尼亚语的变音字符有五个：ă、â、î、ș、ț。

前三个在标准键盘上相对好打，后两个要切布局或者长按。

所以现实中的分布不是二分的，而是部分打、部分不打：写mărime但写sosete而不是șosete。

这种半带半不带的形态，是罗马尼亚语搜索日志里占比最高的一类。

关键词表如果只做全带和全不带两版，中间那一大片就漏了。

更细一层的规律是：越靠近词根开头的变音符号越容易被打出来，越靠近词尾的越容易被省略，因为用户在打字过程中对后半段的注意力本来就在下降。

为什么移动端输入法决定了长尾的形态？

桌面端用户切一次键盘布局能一直用下去，移动端不是。

手机输入法默认的罗马尼亚语布局里，ș和ț要长按s和t才出得来。

打商品名时多按两次不算什么，打一整句长尾问题时没人愿意长按五次。

所以查询越长，带变音符号的比例越低，这个规律相当稳定。

反推到内容规划上：短的商品词按规范写，长尾问答的标题要额外准备不带变音的版本。

做法是在FAQ的问句里自然带上两种形态，别硬塞成关键词堆砌。

这也解释了一个反直觉的现象：商品短词的带变音比例反而比长尾问题高，很多团队按整站平均值做决策，结果给最该做变体的那批长尾页面配错了形态。

哪把尺子能量准变音符号的真实比例？

外部关键词工具在罗马尼亚语上给的数据经常已经做过归一化，带不带变音看不出来。

能看到真实分布的地方只有两个：站内搜索日志，和搜索引擎给站长的查询报表。

站内搜索日志最准，因为它记录的是用户一个字符一个字符打进去的原始串。

做法是把日志按是否含变音字符分桶，再按查询长度分段统计。

跑出来的表通常长这样：三个词以内带变音的占三成，五个词以上不到一成。

拿到这张表，你才知道该给哪些页面准备不带变音的变体。

这张表还有一个附带用途：它能反过来验证你的变音折叠层有没有真正生效，折叠正常时，两种形态的零结果率应该几乎一样，差得多就说明某一侧没接上。

斯拉夫借词层怎么影响选词？

罗马尼亚语被斯拉夫语言包围了一千多年，词汇里有一层厚厚的斯拉夫借词。

十九世纪的语言现代化运动又从法语和意大利语大量引进了拉丁词。

结果是很多概念有两个词：一个斯拉夫来的，一个拉丁来的。

两个词往往语域不同，斯拉夫来的偏日常口语，拉丁来的偏正式书面。

用户在搜索框里打的是口语那个，你的产品文案写的是书面那个。

这是罗马尼亚语站最常见的一类词不对路，而且从中文一侧完全看不出来。

这一层借词还带来一个隐蔽影响：斯拉夫来的词往往在构词能力上更强，能派生出更多复合表达，所以长尾词族的根节点经常落在口语那个词上而不是书面词上。

判断一个词是哪一层来的其实有个粗糙但好用的线索：读起来像意大利语的多半是拉丁层，辅音连缀比较密的多半是斯拉夫层。

同义词里该选口语词还是书面词？

判断标准是这个词出现在页面的哪个位置。

标题和H2用用户会打的那个词，也就是口语那个。

正文里两个都出现，让页面在两种表达上都有覆盖。

规格表和技术参数用书面词，因为那部分内容本来就偏正式。

这个分工不是罗马尼亚语特有的，但罗马尼亚语的两套词汇分层特别整齐，做起来收益也特别明显。

整理这类词对的最快办法，是让本地同事看一遍你的品类词表，逐个标注“这词我平时不会说”。

如果两个词的搜索量差距在三倍以内，通常值得各做一个页面并用内链区分意图；差距超过一个数量级时，弱的那个只做同义词覆盖就够了，别浪费页面预算。

摩尔多瓦那一半市场要不要单独做？

摩尔多瓦的官方语言和罗马尼亚语是同一门语言，宪法上的名称有过争议，语言本身没有分歧。

但两边的市场差别很大：货币不同，物流不同，购买力差一截。

从语言层看，两边的书面语几乎可以完全共用。

从市场层看，值不值得单开一套内容，取决于你的客单价和配送能力。

近亲语言要不要拆成两套内容，这个判断框架我在捷克语和斯洛伐克语那篇里给过三档判据，摩尔多瓦这一对属于最容易的那一档。

绝大多数情况下的正确答案是：内容共用一套，只把价格、货币和配送信息做成变量。

要注意的是，摩尔多瓦本地日常语言环境里俄语的占比不低，做付费投放和社媒时的语言选择跟做自然搜索并不是同一个答案，这两件事要分开评估。

西里尔时期留下的搜索长尾还剩多少？

摩尔多瓦在苏联时期用西里尔字母书写罗马尼亚语，1989年才改回拉丁字母。

三十多年过去，日常搜索里已经基本看不到西里尔形态的罗马尼亚语。

还能看到的地方是历史文献、地名的旧写法、以及德涅斯特河沿岸地区的部分内容。

对做电商的站来说，这块长尾的商业价值接近零。

提这一段是因为做市场调研时容易被历史资料带偏，以为要覆盖两套字母。

真正需要处理两套字母的是塞尔维亚语那种情况，那是另一门语言的另一个问题。

如果你的品类和历史、旅游、地名相关，那就是另一回事了，旧地名的西里尔写法在这类查询里还有真实体量，值得单独拉一份数据看看再决定。

字母排序该怎么排，A-Z导航会错在哪？

罗马尼亚语字母表在基本拉丁字母之外多了五个：ă、â、î、ș、ț。

排序时它们不合并到基础字母里，而是各自排在对应基础字母之后。

a、ă、â是三个位置，i、î是两个位置，s、ș和t、ț同理。

用默认的字节序排序，这五个字母会全部跑到z后面去。

品牌墙、品类字母导航、地区列表这三类页面最容易踩，因为它们直接把排序结果印在页面上。

解决办法是用支持区域设置的排序规则，LDML的排序规范里有罗马尼亚语的完整定义。

还有一个更细的坑：罗马尼亚语的排序把ă和â当成两个不同的字母分别排，而某些通用排序库会把它们都归到a下面，结果是导航顺序看着差不多但就是不对。

价格该怎么写才像本地人写的？

罗马尼亚的货币是列伊，代码RON，日常写作lei。

数字格式和大多数欧陆国家一样：小数点用逗号，千分位用点。

1.299,90 lei是一千二百九十九列伊九十巴尼，不是一点二九九。

货币符号写在数字后面，中间有一个空格。

这几条如果照搬英文格式，价格会显示成用户读不懂的样子，转化直接掉。

更隐蔽的是价格筛选器：前端解析用户输入时如果按英文规则读逗号，1,5会被读成15。

辅币叫巴尼，一百巴尼等于一列伊，标价时小数位一般都写满两位，写成整数不写小数会让价格显得像是估价而不是实价。

促销价的写法也有讲究，原价加删除线再写现价是通行做法，但折扣百分比的写法本地更常见的是写省了多少钱而不是打几折。

日期与尺寸格式还有哪些要改？

日期用日月年顺序，分隔符是点：11.06.2013。

星期从周一开始，日历组件要跟着调。

长度单位用厘米和米，重量用千克，这几项和国内一致。

灯具站要特别注意色温和光通量的写法：3000K和800 lm，单位前有空格。

电压是220V到230V，插座标准是欧标C和F型，这类信息写在商品页上能减少一大批售前咨询。

这些不属于关键词，但它们是页面本地化程度的直接信号，用户扫一眼就能判断这站是不是给他们做的。

灯具还有一个本地特有的信息点：欧盟的能效标签等级要标出来，这一项在罗马尼亚市场的商品页上属于用户会主动找的信息，缺了会明显影响信任。

标题模板的一致性规则要写成什么样？

把前面几节的结论合起来，罗马尼亚语的标题模板需要满足四条。

名词一律用无冠词形态，避免定冠词把检索形态改掉。

形容词按名词的性数字段取形态，中性名词按单复数分别取。

变音符号一律按现行规范写全，不在标题里做不带变音的版本。

数字与单位按本地格式，货币符号在后。

四条写成校验规则挂到发布流程上，比靠人记住可靠得多。

这四条最好写成发布前的自动校验而不是文档里的规范，因为规范只能约束读过它的人，而真正往库里塞商品的往往是脚本或者第三方数据源。

面包屑与分类名要不要带定冠词？

面包屑里的分类名建议用不带冠词的复数形态。

becuri而不是becurile，这是最接近用户检索形态的写法。

页面H1可以带定冠词，读起来更自然。

筛选器的选项标签一律用无冠词形态，因为它们要和后台的属性值对齐。

这套分工的原则是：给机器看的地方用检索形态，给人读的地方用自然形态。

混着用不会出致命问题，但会让站内搜索的匹配率低一截。

顺带说一句，导航里的分类名一旦定下来就别轻易改形态，这类文本会被大量内链的锚文本引用，改一次要连带更新的地方比想象中多得多。

URL里的变音字符该保留还是脱掉？

罗马尼亚语的URL主流做法是脱到基本拉丁字母。

ș变s，ț变t，ă和â变a，î变i。

这条转换要写死在slug生成器里，别指望通用的音译库，它们经常把ț转成ts。

ts这种转法是保加利亚语转写的规则，用在罗马尼亚语上是错的。

域名后缀用ro，这个后缀1993年就完成了委派，本地信任度很高。

多语言站要不要按国家分域名，那是架构层的题，这篇不展开。

脱变音的映射表还要处理一个特例：ș和ț在词尾时脱成s和t会让某些词的slug撞上另一个真实存在的词，遇到这种情况宁可加一个品类前缀来消歧。

锚文本会跟着格变形吗？

会，而且比你想的更频繁。

内链的锚文本嵌在句子里，句子的语法要求它用什么形态，它就得用什么形态。

硬把原形塞进句子里，读起来像外国人写的中文。

处理办法是给每个目标页准备三到四个锚文本变体，覆盖常见的语法位置。

变体之间的核心词根保持一致，变的只是词尾。

这样锚文本既读得通顺，主题信号也不会散掉。

检查锚文本质量的一个土办法：把站内所有指向同一页面的锚文本导出来，如果它们的前四个字符高度一致而词尾各不相同，那就说明变体做对了。

元描述被截断的位置和词长有什么关系？

罗马尼亚语的平均词长比英语长，比德语短。

加上定冠词之后，名词还会再长两到三个字符。

同样字数的元描述，罗马尼亚语版本的实际字符数会明显超过中文版本的译文长度估算。

实操上的经验是：按目标语言的字符数控制，别按源语言的字数控制。

把关键信息压到前面，让截断发生在补充说明那一段。

标题同理，长复合结构在罗马尼亚语里很常见，写之前先量一遍字符数。

另一个和词长相关的地方是移动端的商品卡片，罗马尼亚语商品名普遍偏长，两行截断的位置经常正好切在关键属性词上，这个要拿真机看，模拟器上看不出来。

机器翻译在罗马尼亚语上最常犯哪三类错？

第一类是定冠词处理不当，该带的时候不带，不该带的时候乱带。

第二类是中性名词的形容词一致性，单数对了复数错，或者反过来。

第三类是变音符号漏打，尤其是ș和ț，翻译引擎经常输出土耳其语那两个码位。

第三类最隐蔽，因为屏幕上看起来是对的，只有做字符审计时才发现。

解决办法是在发布前跑一遍字符白名单检查，把U+015F和U+0163列进告警。

这个检查五行代码，能挡掉一整类几年都发现不了的问题。

还有一类不算错但很致命的问题：机器翻译倾向于选择书面语域的那个同义词，于是整站文案读起来像政府公文，词也全落在用户不会搜的那一侧。

检验翻译质量有个便宜办法：把译文里所有带定冠词的名词挑出来，看比例是不是明显高于本地原生文本，机器翻译在这一项上几乎总是超标。

母语审校该盯哪几处？

审校清单不用长，六条就够。

定冠词该不该出现在这个位置，形容词的性数是不是跟着名词走。

斯拉夫词与拉丁词的选择，是不是符合这段文字的语域。

变音字符是不是全部用了带逗号的码位。

价格、日期、单位的格式是不是本地写法。

标题和H2里的名词是不是用了无冠词形态。

最后一条：让审校的人念一遍，念着别扭的地方一定有问题，这条比前五条加起来都管用。

审校的人最好找有电商或者营销背景的，纯语言学背景的审校经常会把口语词全改成书面词，改完语法完美，搜索覆盖反而变差了。

审校结果最好回流成规则而不是只改一遍稿子，同一类错误改到第三次还在出现，就说明它该进模板校验而不是继续靠人眼抓。

词典该怎么用才不浪费时间？

罗马尼亚语最实用的在线词典给的不只是释义，还给完整的变格表。

拿商品词逐个查，把四个形态一次抄进选词表，比事后补要快得多。

阴性名词要额外看斜格形式，那一栏经常和复数长得一样。

lampă的词条就是个标准例子，阴性名词的四个形态加斜格都在一张表里。

整个品类的核心词大概三五十个，一个下午能查完。

这三五十个词决定了你站上百分之八十的标题质量，这笔时间花得值。

查词时顺手把每个词的语域标注也记下来，哪个是口语哪个是书面，这一列在后面写标题和正文时的价值不比形态那几列低。

站内搜索该怎么配才接得住词尾变化？

最低配置是接一个罗马尼亚语词干器，把词尾归并掉。

中配是词干器加同义词表，把口语词和书面词、新旧拼法映射到一起。

高配再加一层变音符号折叠，让带不带变音的查询都能命中。

三层里最划算的是变音折叠，代码最少，覆盖的查询最多。

词干器要注意别过度归并，罗马尼亚语有些短词被词干器切完只剩两个字母。

配完之后拿真实日志跑一遍回归，看零结果率有没有降下来。

配完之后还要留一个人工干预的口子，罗马尼亚语里总有一小撮词是任何算法都处理不好的，直接写死映射比反复调参数省心。

还有一件容易忘的事：搜索结果页的高亮逻辑也要跟着折叠规则走，否则用户搜不带变音的词，命中了却看不到高亮，会以为搜错了。

字符集遗留问题在老站上会怎么冒出来？

罗马尼亚语在UTF-8普及之前用过好几种字符集。

ISO 8859-2是中欧通用的那一套，但它里面只有带下加符的ș ț。

后来专门为罗马尼亚语等语言做了ISO 8859-16，才把带逗号的版本收进去。

Windows平台上更常见的是windows-1250，同样只有下加符版本。

这些字符集都登记在IANA的字符集清单里，接手老站时先查页面声明的是哪一种。

声明和实际编码不一致，是老罗马尼亚语站上乱码的头号原因。

判断老站真实编码有一个不太优雅但很可靠的办法：找一个已知含ș的页面，直接看原始字节，单字节说明是老字符集，双字节才是UTF-8。

迁移老内容时怎么把编码问题一次清干净？

顺序很重要，走错顺序会把问题固化下来。

第一步是确认原始文件的真实编码，别信页面上声明的那个。

第二步转成UTF-8，转的时候记下有多少字符转换失败。

第三步做码位映射，把下加符版本换成逗号版本。

第四步做NFC规范化，第五步重新生成URL与索引。

每一步之后都存一份快照，出问题能回退到具体哪一步，这个习惯救过我不止一次。

转换失败的那批字符千万别直接丢掉或者替换成问号，要单独导出来人工看，里面经常混着引号、破折号和货币符号这类同样有历史包袱的字符。

结构化数据里的语言标记该怎么写？

语言代码用ro，这是ISO 639-1的两字母代码。

需要区分地区时用ro-RO和ro-MD，格式遵循RFC 5646的语言标签规则。

页面上的lang属性、结构化数据里的语言字段、以及站点地图，三处要一致。

价格字段的货币代码用RON，不要写lei，那是显示用的写法。

地址字段里国家代码用RO，邮编是六位数字。

这几项写对了，本地搜索结果里的展现会明显完整一些。

顺带提醒一句，罗马尼亚使用的时区在夏令时期间会切换，商品的配送时效和限时促销的截止时间如果写死了偏移量，一年里有半年是错的。

灯具站的罗马尼亚语选词表长什么样？

核心品类词先列无冠词单数和无冠词复数两列。

再加两列带定冠词的形态，供正文和元描述取用。

然后是变音符号列：全带、部分带、全不带，三种。

接着是同义词列，斯拉夫词和拉丁词各占一格。

最后是旧拼法列，î和â那一对差异只影响少数词，但那些词往往是高频词。

一个品类的完整表大概二百到三百行，这是罗马尼亚语站的地基。

这张表建议用版本管理存起来而不是放在共享表格里，因为它会被标题模板、站内搜索同义词表和内链锚文本三处同时引用，改动需要能追溯。

这张表该怎么排优先级？

不是每一行都值得单独做页面。

无冠词复数形态优先级最高，它是商品列表页的主关键词形态。

无冠词单数次之，用在商品详情页。

带定冠词的形态不单独做页面，只作为正文里的自然表达。

变音符号的变体也不单独做页面，靠站内搜索的折叠层接住。

真正需要单独规划的，是同义词那一列里语义差别较大的那些词。

排完优先级之后再做一次交叉检查：把高优先级的形态拿到搜索框里实际打一遍，看自动补全给出的建议词是不是你预期的那一批，不是就说明形态选错了。

竞品分析在罗马尼亚语上要多看一层什么？

常规的竞品分析看对方做了哪些词、页面结构怎么排。

罗马尼亚语要多看一层：对方用的是哪一套变音码位。

方法很简单，把对方页面的HTML抓下来，统计U+015F和U+0219各出现多少次。

用下加符版本的站，通常是多年前建的老站，内容更新频率低。

全部用逗号版本的站，一般是近几年重做过的，技术侧更值得警惕。

这个指标不写在任何工具的报表里，但它能帮你判断对手的技术底子。

同样值得看的还有对方的slug生成规则，把几十个商品页的URL排在一起，很容易看出对方用的是哪种脱变音映射，以及有没有处理撞词的问题。

把这两项加进竞品清单之后，你对一个罗马尼亚语站的技术判断通常比看外链数据准得多，因为字符处理骗不了人。

引擎那一半的功课为什么不在这篇里？

这篇从头到尾讲的是语言本身：词形、字符、编码、格式。

某个搜索引擎在罗马尼亚市场怎么排名，那是引擎层的题，和这门语言的语法没有关系。

把语言层和引擎层混在一篇里写，结果通常是两边都讲不透。

多语言站要按国家还是按语言分域名，那是架构层的题，同样不在这里。

你可以把这篇当成罗马尼亚语市场的语言侧清单，引擎侧和架构侧另有专篇。

分开做的好处是每一层的结论都能独立复用到下一个市场。

分层的另一个好处是排查问题时不容易误判：流量掉了先看是语言层的词形没覆盖，还是架构层的地区定向出了问题，两条路的排查动作完全不同。

从零开始做罗马尼亚语，推荐什么顺序？

第一步跑字符审计，确认站上用的是哪套码位，统一到带逗号的版本。

第二步建商品属性字典，把名词的性拆成单数搭配和复数搭配两个字段。

第三步查词典补齐核心品类词的四个形态。

第四步改标题模板，按前面那四条规则重写。

第五步配站内搜索的变音折叠和词干器。

第六步才是内容规划，这时候你手里的选词表已经能用了。

这六步的顺序不能随便调，尤其是字符审计必须在最前面，否则后面几步产出的所有数据都会带着两套码位的污染，到时候要重做的不是一步而是全部。

做完这六步，能看到什么变化？

最先动的是站内搜索的零结果率，通常一周内就能看到明显下降。

其次是商品页的展现量，因为标题终于用对了检索形态。

再往后是长尾流量，这一块要等内容规划落地才有。

字符审计那一步的收益不会直接体现在报表上，它防的是几年后的一次大清理。

保哥见过一个站因为两套码位混存，三年后做商品去重时发现两万条重复数据。

那次清理花掉的时间，够把前面六步全做完两遍。

如果你的站还在筹备期，那这六步的顺序可以直接当成排期表用，前三步是数据准备，第四五步是工程改造，第六步才需要内容团队入场。

常见问题解答

罗马尼亚语用拉丁字母，能不能直接套西班牙语的SEO流程？

字母表相同不代表词法相同。罗马尼亚语的定冠词接在词尾，一个名词至少四种写法，而西班牙语的冠词是独立的词，名词形态稳定得多。直接套流程，你的关键词表会漏掉带定冠词的那一大批查询，标题模板也会在中性名词上拼错形容词。语族相近能省的是词汇理解的成本，省不了形态处理的成本。建议把西班牙语流程里的选词和标题模板两步单独重做，其他环节可以复用。另外提醒一点，罗马尼亚语里有大量看起来像西班牙语但意思不同的词，直接凭语感理解词义在这门语言上翻车的概率相当高。

ș和ț的两套码位到底该怎么统一？

目标形态是带逗号的U+0219和U+021B，这是罗马尼亚语的正确字符。处理顺序是先做字符映射把带下加符的U+015F和U+0163换掉，再做NFC规范化把组合序列合成预组合字符。两步顺序不能反，因为规范化不会跨字符做转换。数据库、搜索索引、URL生成器三个地方都要跑同一套流程。做完之后加一条发布前检查，把下加符版本列进告警，防止新内容再混进来。如果站上已经积累了大量混存数据，转换前务必先做一次全量快照，因为字符映射是不可逆的，转错了没有原始数据就只能重新采集。

选词表要不要把带定冠词的形态也做成独立页面？

不要。带定冠词的形态是自然语言里的语法变体，不是独立的搜索意图，为它单独建页面会造成内部竞争。正确做法是让这些形态自然出现在正文、元描述和内链锚文本里，同时在站内搜索层面接一个词干器把它们归并到原形上。商品列表页用无冠词复数，详情页用无冠词单数，这两个形态才值得单独规划。唯一的例外是那些已经固化成专有名词的带冠词形态，比如某些品牌名或者行政区名，这类词本身就带着冠词，按普通词处理反而会出错。

用户不打变音符号，我是不是该把标题也写成不带变音的？

不该。标题按现行正字法写全，这是页面专业度的直接信号，本地用户对拼写错误相当敏感。不带变音的查询靠两条路接住：站内搜索加一层变音折叠，让两种输入都能命中；内容侧在FAQ的问句里自然使用较口语的写法。真实的输入分布不是全带和全不带的二分，而是短查询带得多、长查询带得少，所以变体覆盖要按查询长度分层考虑。还有一个折中做法是在页面上同时提供两种写法：标题按规范写，而商品的别名字段里存不带变音的版本，让站内搜索和结构化数据都能用上。

î和â的旧拼法还需要覆盖吗？

需要，但只覆盖高频词。1993年之前受教育的用户手打时仍会用旧拼法，这批人的购买力通常还不低。做法是把受影响的高频词整理成同义词表，接到站内搜索里，不必为旧拼法单独建页面。正文和标题一律按现行规范写词中用â、词首词尾用î。受影响的词其实不多，整个品类里通常也就十几个，一次整理长期有效。整理这张表时可以顺手把两种拼法在你的站内搜索日志里的实际比例记下来，几年之后再看这个比例，能直观看出用户结构有没有变化。

摩尔多瓦市场值得单独做一套内容吗？

绝大多数情况下不值得。两边是同一门语言，书面语几乎可以完全共用，真正的差别在货币、物流和购买力这些非语言字段上。正确做法是内容共用一套，把价格、货币代码、配送时效和支付方式做成变量。只有当你在摩尔多瓦有独立仓储或者本地化服务时，才值得考虑做独立的地区版本。语言层面的重写成本在这一对上几乎为零，这是相当省事的一种情况。如果决定共用，记得把两个地区的语言标签分开写，这样搜索引擎至少知道你在服务两个市场，而内容维护成本几乎没有增加。

罗马尼亚语的字母排序为什么会让A-Z导航出错？

因为ă、â、î、ș、ț在字母表里各占独立位置，排在对应基础字母之后，而不是合并进去。用默认的字节顺序排序，这五个字母会全部跑到z之后，品牌墙和字母导航就会出现一个诡异的尾巴。解决办法是使用支持区域设置的排序规则，指定罗马尼亚语的排序定义。受影响的主要是三类页面：品牌列表、品类字母索引、地区或城市列表，这几类页面把排序结果直接印在页面上，错了一眼就能看出来。排序库选定之后还要写一个小测试用例，把五个变音字母和它们的基础字母打乱顺序丢进去排一遍，升级依赖时跑一次就能发现排序规则有没有被改掉。

权威参考资料