2023年政策修订增补工作正在进行中，欢迎参与！
  • Moegirl.ICU：萌娘百科流亡社群 581077156（QQ），欢迎对萌娘百科运营感到失望的编辑者加入！
  • Moegirl.ICU：账号认领正在试运行，有意者请参照账号认领流程。

User:GuoPC/编辑之见解

萌娘百科，万物皆可萌的百科全书！转载请标注来源页面的网页链接，并声明引自萌娘百科。内容不可商用。
跳转到导航 跳转到搜索

日文判断

Icon-info.png
此章节论述仅代表个人观点，同时向相关编辑者以个人名义提出建议。如有未列举完全或不足之处，欢迎补充指正。
与该话题相关的帮助文档，请参见Help:日语的处理和Help:在条目名中可用与不可用的日本汉字一览。

写在前面

应当明确，对日文进行后文所述处理并不只是为了防止错误的繁简转换，即便目标内容为纯假名或不受繁简转换影响的日文汉字，也建议进行后文所述处理。单纯防止繁简转换应使用-{}-，参见Help:繁简转换。

判断规则

上下文指明该段文字为日文则毋庸置疑，若未指明，按以下规则判断其为日文：

  1. 该段文字本身仅含有假名；
  2. 该段文字本身仅含有汉字，但不含有简繁体独有字(注)不具有普适性，需根据实际语境另行判断。；
  3. 该段文字本身同时含有汉字和假名，但不含有简繁体独有字；
  4. 其他易判定为日文的情形。

处理措施

存在混用混写现象的汉字，修正为对应日文写法，确认汉字书写无误后：

  • 若在{{ruby}}模板中，则对相应部分加上ja参数，同时视情形补全不同语言文字的参数；
  • 若在引用系列模板（如{{cite web}}）中，作标题则使用script-title=ja:，若标题中存在日文与其他文字混写情况，使用script-title=后对日文部分添加{{lj}}模板；其他部分直接添加{{lj}}模板；
  • 若使用如<span lang="ja"></span>等一般无法阻止繁简转换的代码，还需要添加-{}-防止错误的繁简转换，或者直接改用{{lj}}或{{ljd}}模板；
  • 其他一般文字直接添加{{lj}}或{{ljd}}模板。

注：

  1. 若条目中仅有纯假名未处理，一般亦不做处理；
  2. 在文本中有意使用“の”分别表示中文“的/之”含义等，且与上下文以中文解读能正常理解的，不做处理；
  3. 颜文字中含有日文汉字、假名的，一般不做处理。

拓展阅读

Ruby 系列模板相关

「格式」中含有「*」的参数为可选参数。

「标准」：{{Ruby}}

格式：{{ruby|正常文本内容 A|上方内容 B|A的语言* LA|B的语言* LB}}
代码：{{ruby|萌娘百科|万物皆可萌}}
   {{ruby|萌えっ娘百科事典|もえっこひゃっかじてん|ja}}
   {{ruby|萌娘百科|萌えっ娘百科事典|zh|ja}}
   {{ruby|萌娘百科|萌えっ娘百科事典||ja}}[rubyNote 1]
效果：萌娘百科（万物皆可萌）
   萌えっ娘百科事典（もえっこひゃっかじてん）
   萌娘百科（萌えっ娘百科事典）
注意：在{{Ruby}}内嵌套{{Lang}}或{{Lj}}也可实现类似效果，但个人不推荐
代码：{{ruby|萌娘百科|{{lj|萌えっ娘百科事典}}}}
效果：萌娘百科（萌えっ娘百科事典）
  1. ↑ {{Ruby}}模板文档：“标记zh在一些系统中会自动指定简体中文字体，干扰到其他地区用户的显示。”

「黑幕」：{{Rubyh}}

格式：{{rubyh|正常文本内容 A|上方黑幕内容 S|鼠标移至黑幕上方显示的文本* F|全局语言* L}}
代码：{{rubyh|萌娘百科|呐呐呐}}
   {{rubyh|萌娘百科|呐呐呐|声呐启动}}
   {{rubyh|萌えっ娘百科事典|ねぇねぇ|二次元です|ja}}
效果：萌娘百科（呐呐呐）
   萌娘百科（呐呐呐）
   萌えっ娘百科事典（ねぇねぇ）
提问：为什么{{Rubyh}}不能像{{Ruby}}那样分别限定上下文字的语言？
因为{{Rubyh}}调用了{{Ruby}}却没有提供B的语言 LB参数。{{Rubyh}}的结构：{{ruby|参数1|{{黑幕|参数2|参数3}}|参数4}}，参数4被解析成用于限定全局语言的参数。

「多行」：{{Ruby-begin}}{{Ruby-item}}{{Ruby-end}}

格式：
{{ruby-begin|class=Class*|id=Id*|style=Style*}}                         <!-- 标记 Ruby 部分开始 -->
{{ruby-item|正常文本|上方内容*|语言*|class=Class*|id=Id*|style=Style*}} <!-- 一般 Ruby -->
{{ruby-end}}                                                            <!-- 标记 Ruby 部分结束 -->

「单字」：{{Rubya}}

格式：{{rubya|正常文本内容 A1_上方内容 B1_样式* F1|正常文本内容* A2_上方内容* B2_样式* F2|…*|正常文本内容* An_上方内容* Bn_样式* Fn|lang=全局语言* L}}

{{RawRuby}}

格式：{{rawruby|正常文本内容 A|上方内容 B}}

歌词排版相关

在萌百上，有以下几种对歌词排版的形式：

<poem>排版

代码

<poem>
原文
翻译
原文
翻译
……
</poem>

效果

原文
翻译
原文
翻译
……

想法

  • 配色：直接使用{{color}}等，对于日文则用{{cj}}等。
  • 额外内容（如罗马字、拉丁化等）：直接插在原文和翻译之间。
  1. 优点：编辑简单；
  2. 缺点：会使页面右侧空出大量空间；同时对于歌词较长时，会使得所在页面冗长，见Special:固定链接/304372。
    当然，对于无需翻译的歌词另当别论，亦不在本章节讨论范围之内。

表格 +<poem>排版

代码

{|
|<poem>
原文
原文
原文
原文
……
</poem>
|<poem>
翻译
翻译
翻译
翻译
……
</poem>
|}

效果

原文
原文
原文
原文
……

翻译
翻译
翻译
翻译
……

想法

  • 配色：直接使用{{color}}等，对于日文则用{{cj}}等。
  • 额外内容（如罗马字、拉丁化等）：直接在各行原文下添加一行放置；或者改成三列表格，中间一列放置这些内容。
  1. 优点：这种排版将原文与翻译左右分隔开，同时又相互呼应，便于对照；缩短了歌词占用的页面长度。
  2. 缺点：当左右文字行距或字号不同（特别是使用了{{ruby}}，见Special:固定链接/376347）时，就会产生原文与翻译无法对齐的问题（前文例中即使两侧均使用{{ruby}}仍存在无法完全对齐的现象），一定程度上使显示效果变差。

{{Lyrics}}排版

代码

{{Lyrics
|lb-color:orange
|rb-color:lightblue
|lb-text1=原文
原文
原文
原文
|rb-text1=翻译
翻译
翻译
翻译
|lb-text2=原文
原文
原文
原文
……
|rb-text2=翻译
翻译
翻译
翻译
……
}}

效果

原文 原文 原文 原文

翻译 翻译 翻译 翻译

原文 原文 原文 原文 ……

翻译 翻译 翻译 翻译 ……

想法

  • 配色：直接在对应参数中限定；
  • 额外内容（如罗马字、拉丁化等）：直接在各行原文下添加一行放置，对应翻译空出一行。
  1. 优点：将原文与翻译左右分隔开，同时又相互呼应，便于对照；模板内可以直接限定文字颜色（当然，需要用到多种颜色还得用{{color}}等单独设置）和原文语言（最终体现为字体），同时一段原文对应一段翻译，方便发现可能存在的错误；缩短了歌词占用的页面长度，100%利用页面。
  2. 缺点：和之前的排版方式类似，会存在左右不对齐的情况，好在分段对应使得这种问题不那么明显了（可以直接参考模板页下方的例子）。

{{LyricsKai}}排版

代码

{{LyricsKai
|lstyle=color:orange;
|rstyle=color:lightblue;
|original=
原文
原文
原文
原文

原文
原文
原文
原文
……
|translated=
翻译
翻译
翻译
翻译

翻译
翻译
翻译
翻译
……
}}

效果

原文
翻译
原文
翻译
原文
翻译
原文
翻译
原文
翻译
原文
翻译
原文
翻译
原文
翻译
……
……

想法

  • 配色：直接在对应参数中限定；
  • 额外内容（如罗马字、拉丁化等）：直接在各行原文下添加一行放置，对应翻译空出一行，或者使用{{LyricsKai/multi}}将内容放在中间一列（虽然{{LyricsKai/multi}}的初衷是用于显示多种翻译版本）。
  1. 优点：将原文与翻译左右分隔开，同时又相互呼应，便于对照；模板内可以直接限定文字颜色（当然，需要用到多种颜色还得用{{color}}等单独设置）等文本样式、左右文字语言（最终体现为字体），直接提供整体样式（containerstyle）的关键字；缩短了歌词占用的页面长度；保证了左右完全对齐；
  2. 缺点：原文和翻译分离，降低了对照更改的效率（不过同时方便初建和大段修改歌词时单独处理原文和翻译）。

未曾设想的遭遇

主要是各种infobox占用页面右侧空间的问题。当infobox和歌词同时存在时，可能会出现歌词被挤到infobox下，歌词与之前内容之前存在空白的情况，存在以下几种解决方法：

  1. 在前文末尾、“歌词”章节前添加{{clear}}（能让章节名“歌词”和歌词一起到infobox下，解决章节名和歌词本身之间的空白）；
  2. 改用{{LyricsKai}}。

结语

总之，以上提及的四种方法各有适用对象，应根据实际编排情况权衡考虑。

个人消歧义相关意见

Icon-info.png
以下内容截取自本人于方针政策版的发言。与现有消歧义方针冲突之处以方针为准。

先说“是否需要消歧义”的问题：

  • 名称仅由一个单词组成的前提下：
    1. “Lorem”与“lorem”[fl-disa 1]这种仅首字母大写与全小写为同一情形，存在多个同名时需消歧义；
    2. 其他大小写不规则写法如“LoRem”“LoREm”，以及全大写“LOREM”互为不同情形，也与第一种情形互为不同情形。如果没有大小写完全一致名称的不同事物，则无需消歧义；
    3. 包含特殊符号的与上文所述不含符号的属于不同情形。
    即可以有：
    • “Lorem”消歧义页：Lorem(a)、lorem(b)→Lorem(b)、LoRem、LoREm、LOREM、Lorem!；
    • “Lorem”消歧义页：Lorem、LOREM(c)、LOREM(d)。
  • 名称由多个单词组成的前提下：
    1. 类似于第一种前提的第一种情形，“Lorem ipsum”与“lorem ipsum”[fl-disa 2]为同一情形，存在多个同名时需消歧义；
    2. 仅各单词首字母大写“Lorem Ipsum”，大小写不规则写法如“LoRem ipsum”“LoRem Ipsum”“LoRem iPSum”，以及全大写“LOREM IPSUM”互为不同情形，也与第一种情形互为不同情形。如果没有大小写完全一致名称的不同事物，则无需消歧义；
    3. 包含特殊符号的与上文所述不含符号的属于不同情形。
    即可以有：
    • “Lorem ipsum”消歧义页：Lorem ipsum(a)、lorem ipsum(b)→Lorem ipsum(b)、Lorem Ipsum、LoRem ipsum、LOREM IPSUM、Lorem ipsum!；
    • “Lorem ipsum”消歧义页：Lorem ipsum、LoRem ipsum(c)、LoRem ipsum(d)、LOREM IPSUM(e)、LOREM IPSUM(f)。
    • 包含特殊符号的与前文所述不含符号的属于不同情形。

再说“消歧义页命名”的问题：

  • 优先首字母大写且不含特殊符号形式作为消歧义页名称。例如站内存在“Lorem”“LoRem”“LOREM”“Lorem!”等时建立“Lorem”消歧义页，并将“Lorem”条目进行消歧义，其他条目不变；
    • 特别地，假设站内仅存在“LoRem”“LOREM”等而无“Lorem”，依然建立“Lorem”消歧义页。
  • 若站内仅存在某一种拼写的多个同名条目（不论是否有特殊符号），则仅建立该种拼写的不含特殊符号的消歧义页。例如存在多个“LoRem”而无其他拼写的L[Oo][Rr][Ee][Mm]形式及“LoRem!”时，建立“LoRem”消歧义页。
    • 特别地，假设有“Lorem”“LoRem(a)”“LoRem(b)”，则建立“Lorem”消歧义页，建立“LoRem”重定向至“Lorem”，“Lorem”消歧义页中列举形式同前所述。
  1. ↑ URL仍为“Lorem”，仅条目内标题利用{{小写标题}}显示为全小写。
  2. ↑ URL仍为“Lorem ipsum”，仅条目内标题利用{{小写标题}}显示为全小写。
1. Lorem
Lorem消 Lorem(a)
Lorem(b)
LoRem重
→Lorem		 LoRem(c)
LoRem(d)
LoRem?
LoREm
LOREM
Lorem!
2. LOREM
LOREM消 LOREM(a)
LOREM(b)
Lorem ipsum
Lorem ipsum消 Lorem ipsum(a)
Lorem ipsum(b)
Lorem Ipsum
LoRem Ipsum重
→Lorem ipsum		 LoRem Ipsum(c)
LoRem Ipsum(d)
LoRem ipsum
LoRem iPSum
LOREM IPSUM
Lorem ipsum!

以上。

取自“https://moegirl.icu/index.php?title=User:GuoPC/编辑之见解&oldid=7358512”