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

使用者: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!

以上。