kzg

日本語言語タグ

[16] 日本語を表す言語タグは、 ja です。

主要言語タグまとめ

日本語 (一般)
ja
日本語 平仮名表記 (よみがな等)
ja-Hira
日本語 片仮名表記 (ヨミガナ等)
ja-Kana
日本語 ローマ字表記
ja-Latn
やさしい日本語
ja-simple

[262] 大文字と小文字は区別しません (どちらでもいいです) が、 プロトコル等で特別に定めていることもあります。

基本値

ja (言語タグ)

[81] ja日本語を表す ISO 639 言語符号であり、 言語タグであります。

[82] 特に細かい指定が必要ないときはこれを使います。

ja-JP (言語タグ)

[21] 日本国で使われる日本語と特に明記する必要がある場合は、 言語タグ ja-JP を使うことができます。

[22] BCP 47 によれば、必要性がなければ省略できます。 言語部分タグと地域部分タグの組合せ

[59] 実際には、日本国以外で日本語が使われる場面は多くなく、 しかもの違いを明示する必要がある場面はその中でもわずかなので、 ja とだけ書くのが一般的です。

[60] 特定のプログラムの仕様等で地域部分タグが必須な場合や、他の言語タグとの統一性のため地域部分タグを明示したいような場合もあって、 ja-JP が使われることもままあります。 しかしそうした事情がなければ、短くて必要十分である ja が望ましいと考えられます。

ja_JP (POSIX ロケール識別子)

[58] POSIX locale ja_JP日本国日本語ロケールを表します。

[61] POSIX では言語符号国符号を組み合わせて両方明記するのが一般的です。


[62] 稀に誤って言語タグ ja_JP が使われることがあります。 (この誤りは日本語以外の言語タグでもみられます。) 言語タグの構文に違反しており、明確な誤りです。

[63] 言語タグの実装の多くはこれに対応しておらず、未知の言語とみなして処理します。 (_- と読み替える実装もあります。 言語タグ )

jp (言語タグ)

[7] jp は、 たまに使われる日本語を表しているらしい言語タグです。

[39] 言語タグ jp誤りです。正しくは ja です。

[64] 国符号JP なので、よく日本語も誤って jp と記述されるのです。

[65] 多くの実装は jp に対応しておらず、未知の言語とみなします。

[66] なお、日本語ja と表し jp と表さないのは ISO 639 言語符号の仕様に過ぎず、人間同士で便宜上用いる略号や、 ISO 639 以外の言語符号日本語を 「jp」「JP」 と表すことは必ずしも誤りではありません。

[67] ただ、紛らわしい表現であることは確かです。 また、日本語のことを人間同士で「JP」や「JA」と略すのは、 英語話者の間でも、日本語話者の間でも、 一般的な表現ではないので、伝わりやすいとはいえません。 確実に伝わるといえる場面以外では避けるべきです。


  • [48] 手元の WinIE 1.0〜3 は jp という間違った値を送ります。
[6] 正規表現による置換 ( 版) http://fstyle.ddo.jp/FT/JavaScrip/replace-match.html
<html lang="jp">
[5] 音声認識文法の作成方法 — OpenHRI Manual () http://openhri.readthedocs.io/en/latest/workingwithgrammar-ja.html

<lexicon version="1.0"

xmlns="http://www.w3.org/2005/01/pronunciation-lexicon"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.w3.org/2005/01/pronunciation-lexicon

http://www.w3.org/TR/2007/CR-pronunciation-lexicon-20071212/pls.xsd"

alphabet="x-KANA" xml:lang="jp">

[138] KinKi Kids オフィシャルサイト / Johnny's Entertainment () http://je-kinkikids.com/

<html lang="jp">

[8] TBS NEWS () https://news.tbs.co.jp/

<html class="gs-fontSmall" lang="jp">

[68] また、 Accept-Language: に相当する Webブラウザーの設定に自分で jp を追加している人も稀にいるようです。

[151] >>150

jpn

[87] jpn日本語ISO 639 3文字符号です。

[349] 言語タグとしては使うのは誤りですが、極めて稀に使われることがあります。

japanese (言語タグ)

[83] 極めて稀に言語タグ japanese が使われることがあります。

[84] 言語タグの構文に違反しており、誤りです。

[85] 対応している実装はみたことがありません。

日本語 (言語タグ)

[88] 極めて稀に言語タグ 日本語 が使われることがあります。

[89] 言語タグの構文に違反しており、誤りです。

[90] 対応している実装はみたことがありません。

jpx

[129] 日本語族を表すISO 639 言語符号 / IETF言語タグ jpx があります。

地域言語の識別子

津軽弁の識別子

[126] >>125津軽弁を追加しようとしたものの、言語タグがわからず、(おそらく)断念しています。

[127] 言語タグ体系が整備されていないことで自分の使いたい言語を自由に使えないという実害の1事例といえ、 由々しき事態です。

八丈語の識別子

[163] ISO 639-6八丈島弁に4字言語符号 hhjm を割り当てていました。

関西弁の識別子

[380] 関西弁現代日本語のうち標準語/共通語を除いて最もよく用いられ言及される方言で、 これを計算機システムで実装しようとした試み (商用システムで実戦投入されたものを含む。) もかなりあります。

[382] しかしその識別子は既成の標準規格がまったく対応できていないために安定性を欠いているのが実情です。

[381] 適切な標準の欠如が言語的多様性の実現の障害になっているとも考えられ憂慮される状況ですが、 打開の見通しも立たないのが現状です。


[2] ja_KS は、 Facebook関西弁を表すために使っている >>1 ロケール識別子です。

[3] 他の ja_JP などは POSIXロケールと同じですが、 ja_KSFacebook 独自のもので、 Facebook 以外のシステムでは使えません。

[11] POSIX では KS の部分は ISO 3166国符号を使うことになっています。 将来もし KS なる国符号がどこか新しいに割り当てられ、 そこで日本語が使われるようになると、衝突します。

[13] WebブラウザーVivaldi は、 ja-KS というロケール識別子を使っています。 >>12

[14] BCP 47 言語タグのような構文ですが、 BCP 47 言語タグとして使われることもあるのかどうか不明。

[15] Android 関連のファイルでは Androidロケール形式により ja-rKS となっています。 >>12

[20] 関西弁のネイティブスピーカー・ボランティア翻訳者、大募集(しました)! | Vivaldiブラウザ, https://jp.vivaldi.net/announcement/kansai_translator/


[4] BCP 47 言語タグとして、 ja-JP-kansai が使われることがあります。

[9] IANA登録簿には未登録です。 言語タグの古い仕様書では正当な言語タグだったのですが (当時は未登録でもOKだった)、 その後の仕様の非互換変更のせいで、本稿執筆時点では非妥当言語タグになってしまっています。

[10] といっても言語タグ妥当性を検証する実装は、適合性検査器以外では、 実在するのか怪しいレベルなので、実用には支障がありません。

[249] 大阪弁言語タグja-osaka があります。

[250] 古くから例文でよく使われています。大阪弁言語タグ事実上の標準といって良いでしょう。 実利用がどれだけあるかは不明です。

[107] lang=lang - 言語指定 ( 版) http://www.tohoho-web.com/html/attr/lang.htm

ja-osaka(大阪弁)

x- で始まるコードはプライベートに使用することが許されています。

x-uchuujin(宇宙人語)

[108] lang=lang - 言語指定ホームページ制作 京都|ホームページ作成のリュウム ( 版) http://www.ryuumu.co.jp/ryuumu/ain/webguide/html/attr/lang.htm

ja-osaka(大阪弁)

x- で始まるコードはプライベートに使用することが許されています。

x-uchuujin(宇宙人語)

[110] locale/test_tag.rb at master · mutoh/locale ( 版) https://github.com/mutoh/locale/blob/master/test/test_tag.rb

assert_equal Locale::Tag::Rfc.parse("ja-osaka"), lang.to_rfc

[248] 属性セレクタ(書いて理解する) #CSS - Qiita, https://qiita.com/Hamachan4242/items/5903a30bb4aedb583791
<blockquote lang="ja-osaka"><!-- ハイフンの後ろの言語のサブコードを含んでもok! -->

[326] Xユーザーのharo2さん: 「ぐぐったら ja-JP の派生で ja-OS で関西弁カルチャを定義しようとしてダメだったというブロク見つけたけど、ja-OS だと BCP-47 に準拠してないからダメだったのかも」 / X, , https://twitter.com/haro2beam/status/1331172345063456768

[328] C#のリソースの仕組みを使って多言語対応させようぜ☆(^~^) #C# - Qiita, https://qiita.com/muzudho1/items/8e55668b7c0914466fac

# 日本は ja-JP しかない。 大阪弁を追加しようと ja-OS(日本(大阪)) を作ろうとしたら
# 言語コードは OS(コンピューター)への登録制になっていて、管理者権限 が求められたので止めた。

琉球語の識別子

[86] 言語タグ ja-ryuukyuu平成時代中期頃に提案されていました。 実用例は見当たりません。

[130] ISO 639 言語符号 / IETF言語タグ琉球諸語を表すものがあります。

[136] Wikipedia で利用しています。

[148] >>147沖縄語辞書XML 移植版ですが、 ryu-Hira, ryu-Jpan, ryu-Latn, jp-Jpan を使っています。 最初の3つは沖縄語見出し語の各種表記、 最後は日本語の説明文。

[149] IPA 発音記号列を Latn とするのは誤りではないものの、違和感があります。

[150] jpja の誤り。

[147] - 6_s206.pdf, , https://researchmap.jp/SoMiyagawa/published_papers/40398156/attachment_file.pdf

歴史的言語の識別子

[76] 日本語古語を表す言語タグ ja-classic, 平安時代日本語を表す言語タグ ja-classic-heian平成時代中期頃に提案されていました。 実用例は見当たりません。

[128] Old Japanese を表す ISO 693 言語符号 / IETF言語タグ ojp があります。

[132] >>131 の例文は ojp-Hiraojp-Hani平仮名表記と万葉仮名表記を区別しています。


[313] LIISコードがいくつかの日本語表記体系・歴史的日本語符号を割り当てています。 >>312 言語タグとして使う方法も定められています。 LIISコード

[389] >>388 は題名に「傳統假名翻譯」とあり、 言語選択に「漢文訓読体」とある版ですが、 HTML lang="" 属性値IETF言語タグ x-liisor-chankun となっています。「漢文訓読体」のLIISコードです。 「日本語」の原文と比較すると、本文内容はほとんど同じで、 一部語尾が違う程度で文体の変更はありませんが、旧仮名遣いであり、 旧字体を使ったり仮名漢字に改めたり、 近代風の漢字の遣い方に改めたりしています。

表記法の識別子

[340] 日本語にはいろいろな表記法があります。


[27] ja-Kana (片仮名) って嫌な名前だなぁ。 ISO 15924 の馬鹿野郎〜

[333] Xユーザーの狩野宏樹さん: 「XML 1.0の§2.12→IETF BCP 47 (最新版はRFC 5646。EPUB 3.0はこの版を引用) と辿って、langtagの構成はlanguage-script-regionの順であることを確認。「xml:lang="ja-Hrkt-JP"」としなくてはならない。」 / X, , https://twitter.com/KAN0U/status/53663549649715200

読み仮名の識別子

[212] 平仮名読み仮名を表すため言語タグ ja-Hira >>211, >>213, >>219 が使われることがあります。

[78] 片仮名読み仮名を表すため言語タグ ja-Kana >>209, >>213, >>223, >>231, >>287, >>291 が使われることがあります。

[220] 他に言語タグ ja-Hira-JP >>214, >>215言語タグ ja-Kana-JP >>102 が使われることがあります。

[210] ja-JP より ja が好ましいのと同じく、 ja-Hiraja-Kana が一般的には好ましいと考えられます。

[77] 言語タグ ja-Hrkt >>222 が使われることがあります。 ひらがなカタカナかを問わないことを示すためでしょうか (>>222 の例示はすべて平仮名)。

[275] Semantic Web 系のデータベースでよみがなの意味の ja-hrkt が実用されている事例 >>310 をみました。

[298] なお ja-Kana については >>282 も参照。

[366] 読み仮名と「じゃない方」を言語タグで区別することについては、 >>232 も参照。

[219] Google 日本語入力 - CGI API デベロッパーガイド, , https://www.google.co.jp/ime/cgiapi.html

langpair=ja-Hira|ja

[222] GTFS.JP, , https://www.gtfs.jp/testsite/fix/format-reference_style/developpers-guide/format-reference.html#translations

国内の経路検索事業者においては、よみがなを必須としていることから、よみがな(lang=ja-Hrkt)を設定することを必須としています。

[209] api-spec.pdf, , https://id.ndl.go.jp/information/wp-content/uploads/2023/05/api-spec.pdf#page=9
  • 言語タグは、Web NDLA では「よみ」にのみ用いています。例えば「図書館」の場合、カナ読み "トショカン"@ja-Kana、ローマ字読みを"Toshokan"@ja-Latn としており、言語タグによっ て読みの種類を区別できます。
[223] JPCOARスキーマ項目の説明 | JPCOARスキーマガイドライン, https://schema.irdb.nii.ac.jp/ja/schema

xml:lang

  • 基本的にはISO 639-1の2桁の言語コードを使用する。(例:日本語の場合は"ja"、英語の場合は"en") 0 【Version 1.0,1.0.1,1.0.2】ただし、日本語のヨミは"ja-Kana"を使用し、ヨミを記入する場合はヨミとは別にxml:langを"ja"にした情報を必ず記入する。 0 【Version 2.0 Draft以降】ただし、日本語の片仮名ヨミは"ja-Kana"、ローマ字ヨミは"ja-Latn"を使用し、ヨミを記入する場合はヨミとは別にxml:langを"ja"にした情報を必ず記入する。
  • 中国語については、簡体字"zh-cn"と繁体字"zh-tw"で区別して記入することが望ましい。
  • 言語の識別が難しい場合およびISO 639-1の2桁の言語コードが存在しない場合は、言語コードを記入しない。
[215] OpenID ConnectとSCIMのエンタープライズ実装ガイドライン - eiwg_implementation_guideline_1.0.pdf, , https://www.openid.or.jp/news/eiwg_implementation_guideline_1.0.pdf#page=37

これら 2 つの属性では、locale サブ属性に言語を表す値を設定することで、クラウドサービス が 必要 とす る言 語の 値を 取り 出す こと に対 応す る。 locale サブ 属性に 設定 する 値に は、 [RFC5646] の形式で、IANA Language Subtag Registry に登録された値を用いる。同一言語で 異なる表記がある場合は、script subtag の値を含めることで対応する。具体的には、次のよう な値とする。

No表記locale サブ属性に使用する値
1漢字表記ja-JP
2よみがな表記ja-Hira-JP
3ローマ字・英語表記en-US

よみがな表記は「ひらがな」で値を設定するものとする。クラウドサービスが「カタカナ」で 値を必要とする場合は、クラウドサービス側で「ひらがな」で受け取った値を「カタカナ」に変 換する。

[214] ユーザ属性, Internet Initiative Japan Inc., , https://manual.iij.jp/iid/iidapi/19000993.html

氏名の言語

typeと一致させる必要があります

入力可能な値は以下です

  • ja-JP
  • ja-Hira-JP

ローマ字表記の識別子

[91] 日本語ローマ字表記を表す言語タグ ja-Latn が使われることがあります。 >>162, >>209, >>211, >>223, >>229, >>231, >>251

[241] ほとんどの用途は読み仮名に相当するローマ字併記を表すものです。 これについては >>232 を参照。

[231] RDFモデルについて « Web NDL Authoritiesについて, https://id.ndl.go.jp/information/model/#anchor03

読みを付加する優先ラベル(=名称/タイトル)と代替ラベル(=別名/別タイトル、同義語)の表現には、SKOS拡張のskosxl:prefLabelskosxl:altLabelをそれぞれ使用します。読みの記述には、DC-NDLで定義されるdcndl:transcriptionの語彙を使用します。典拠レコードでは、カタカナ読みとローマ字読みの2つの読みを保持しており、それぞれ言語属性”ja-Kana”と”ja-Latn”を用いて区別します。

[162] 地図作成 - 地図作成 - HERE Developer, , https://jp.developer.here.com/documentation/geojson-map-components-cartography/data_spec_guide/common/globals.html#languagebcp47

、 "ja" 、 "ja-Latn" 、


[173] 登録ファイル付でIANA登録簿に登録された異体部分タグ hepburn があります。 接頭辞ja-Latn とされます。 ヘボン式ローマ字を表します。 >>174

[175] つまり言語タグ ja-Latn-hepburn日本語ヘボン式ローマ字表記を表せます。

[176] この hepburn の登録には、 ヘボン式考案から近年のウェブページまでいろいろが参照されています。 そしてヘボン式には色々な変種があれども、それらを区別するのは生産的でないと主張しています。 >>174 つまり hepburn は「ヘボン式といわれるいろいろな手法のどれか」を表しています。

[177] だったら ja-Latn でも十分で、ローマ字ではなくヘボン式ローマ字とまで特定したいけどそれ以上詳しくは記述したくない場面って本当にあるんですかね?

[178] hepburn という部分タグの意味はの旧ヘボン式であるかのように説明があるのですが >>174、 それに続く何が言いたいのかよくわからない文章を読んでいくとどうやら「ヘボン式」 全般を包括的に表したいらしい (>>176) ことが判明します。

[188] それを念頭に読み直すと旧ヘボン式の説明の後になぜか

The common characteristic of Hepburn romanization in its many variants, apart from the name, is an emphasis on approximating Japanese _pronunciation_ using English or European spelling conventions. Hepburn romanization does not attempt to parallel or transcribe the Japanese logographic scripts (hiragana or katakana).

と各種ヘボン式の「共通の性格」を説明した段落があります。 >>174 hepburn が意味する「ヘボン式」の範囲はこの記述から推測する以外ありません。

[179] つまり、

というのが共通の性格だといっています。ただこの「共通の性格」 というのも曖昧な表現で、この性質を絶対に満たすものが hepburn だと言っているようにも理解できますし、 hepburn の多くはこの性質を満たすがそうでない例外ケースもあり得るという解釈も一応可能です。

[183] この説明から当然浮かんでくる疑問は

といったようなものですが、いずれも hepburn の意味の根幹に関わる疑問です。

[196] なおローマ字以外にヘボン式は存在しないので Latn と明示するのは冗長に思われますが、 ja-Latn にしか対応していない実装でも ja-Latnフォールバックできるというメリットがあります。

[198] 実利用例もいくらかあります。 >>197

[197] FamilySearch Developer Center — place 10365609, https://www.familysearch.org/platform/places/10365609
    <ns5:name xml:lang="uk">Петрівка</ns5:name>
    <ns5:name xml:lang="uk-Latn">petrivka</ns5:name>
    <ns5:name xml:lang="ja-Latn-hepburn">Shōwa-chō</ns5:name>
    <ns5:name xml:lang="ja-Hira">しょうわちょう</ns5:name>
    <ns5:name xml:lang="ru">Петровка</ns5:name>

[192] >>190 (登録ファイルは付) でIANA登録簿に登録された異体部分タグ heploc があります。 接頭辞ja-Latn-hepburn とされます。 米国 Library of Congress の方式のヘボン式ローマ字を表します。 >>189

[193] つまり言語タグ ja-Latn-hepburn-heploc日本語ヘボン式ローマ字 (米国 Library of Congress 式) 表記を表せます。

[194] ところがこれは付 (登録ファイルは付) で非推奨とされました。 alalc97好ましい (preferred) とされています。 つまり ja-Latn-hepburn-heplocja-Latn-alalc97 とするべきとされています。 >>190

[195] わずか数ヶ月での朝令暮改ですが、これは登録ファイル付で日本語に限定しない alalc97 が登録された >>191 ためそちらに寄せるべきと判断されたことによります。

[247] IANA登録簿の登録情報の機械可読部分だけから ja-Latn-hepburn-heplocja-Latn-alalc97 に置き換えるべきと実装するのは不可能です。これは当時指摘されていますが >>246、 対処されなかったようです。

[245] ヘボン式以外の方式、例えば訓令式用で広く通用する言語タグはありません。


[205] 拡張Tによって記述できる転写方式もあります (>>199)。

[206] 関連: 変換操作の識別

[208] >>207ja-Latn-s-Hani-t-Hepburn (ヘボン式), ja-Latn-s-Hani-t-Kunrei (訓令式) という例を示しています >>207 が、 これらは当時の提案 (後に拡張Tに統合され構文がまったく違うものに変更されたもの。) に沿って >>207 のブログ記事著者が独自に考案した利用法を提案したもので、 このまま使うことはできません。

[258] ja-Latn-x-hepburn を使ったものもあります。 >>257

[257] doc7.pdf, , http://ccs.tsurumi-u.ac.jp/docu/poster/doc/doc7.pdf#page=7
<seg xml:lang="ja-Jpan"> 鶴見大学 </seg>
<seg xml:lang="ja-Hira"> つるみだいがく </seg>
<seg xml:lang="ja-Latn-x-hepburn">tsurumidaigaku</seg>

[216] 「ローマ字・英語」を en-US とすると定めている応用もあります >>215

[285] 「英語名 (もしくはローマ字表記)」 を en とすると定めている応用もあります >>284

[292] 欄ごとに en日本語ローマ字と説明したり、 英語と説明したりするものもあります >>291

[217] English だけでなく日本語ローマ字表記まで en とするのは厳密には誤りに近いですが、 実運用上日本語ローマ字英語の区別が難しいことも多い ( 日本語ローマ字 ) ので、やむを得ないことがあります。

[286] 漢文のケースと同じく、「1つの言語である」という前提自体に無理があるとも言えます。 複数表記などで厳密さを向上させることはできますが、 取り扱いが難しくなる割に実益はそれほどありません。

[218] なお、その場合でも en, en-GB, en-US, en-JP 等からどれを選ぶかは検討の余地があります。


[325] 正規名と読み仮名やローマ字名が書ける GTFS で他に読み上げ用情報も入れたいということか。しかし本当に IPA で書くのか (書けるのか)...?

[350] なお SSML には alphabet="" という読み上げ用情報の表記法を指定する属性があります。

「じゃない方」の識別子

[79] 読み仮名ローマ字表記に対する本来表記を表す (例えば「氏名のよみがな」欄に対して「氏名」欄を表す) ときには、通常の言語タグ ja を使うことが多いです。


[252] 言語タグ ja-Jpan >>251, >>259, >>260, >>291, >>305言語タグ ja-Jpan-JP >>261 が使われることがあります。

[253] しかしながら、用字系抑制の規則があるので、特に理由がなければただの ja を使うべきです。

[260] Microsoft PowerPoint - 学術XML-R.ppt - Tokizane-TeX-20121027.pdf, , https://tokizane.jp/Ref/TokiPDF/Tokizane-TeX-20121027.pdf#page=23

- xml:lang=“en” 英語

- xml:lang=“ja-Jpan” 漢字まじり

- xml:lang=“ja-Kana” カタカナ

- xml:lang=“ja-Hira” ひらかな

[259] Localised metadata for Art Tracks and original release dates - YouTube Help, https://support.google.com/youtube/answer/4443834?hl=en-GB
    <Title TitleType="DisplayTitle" LanguageAndScriptCode="ja-Jpan">
[251] デジタル音楽業界を支える仕組みとは #1 | レコチョクのエンジニアブログ, , https://techblog.recochoku.jp/9225
         <DisplayArtistName ApplicableTerritoryCode="Worldwide" LanguageAndScriptCode="ja-Latn" IsDefault="true">Saeko Shu</DisplayArtistName>
         <DisplayArtistName ApplicableTerritoryCode="Worldwide" LanguageAndScriptCode="ja-Jpan">しゅうさえこ</DisplayArtistName>

[221] 稀に本来表記に言語タグ ja-Hani-JP が使われることがあります。 >>102

[277] OpenID Connect の仕様書に ja-Hani-JPja-Kana-JP で漢字名とヨミガナ名を表すとの例示があります >>276。 あくまで例示ではあるものの、仕様書にはっきりと明記されてしまっているので、 一般の解説記事もそれに従って紹介していて >>290, >>288, >>289 何の疑問も挟まれていません。 実装仕様がウェブ公開されているもの >>102 以外にも各所で使われてしまっていると考えるべきでしょう。

[80] Hani漢字を表します。漢字名と説明されており >>102, >>276、 その説明を忠実にあらわす符号ではあるのですが、 実際には漢字だけとは限らず仮名ラテン文字が含まれることもあり得ると考えられ、 Jpan がより適切とも思われます。

[227] 仮名ローマ字に対して「漢字の名前」のような言い方をすることはありますが、 そのまま符号になおすと不適切なこともある、ということです。
[276] Final: OpenID Connect Core 1.0 incorporating errata set 2, , https://openid.net/specs/openid-connect-core-1_0.html#rfc.section.5.2

Human-readable Claim Values and Claim Values that reference human-readable values MAY be represented in multiple languages and scripts. To specify the languages and scripts, BCP47 [RFC5646] language tags are added to member names, delimited by a # character. For example, family_name#ja-Kana-JP expresses the Family Name in Katakana in Japanese, which is commonly used to index and represent the phonetics of the Kanji representation of the same name represented as family_name#ja-Hani-JP. As another example, both website and website#de Claim Values might be returned, referencing a Web site in an unspecified language and a Web site in German.

[102] Yahoo! ID連携:属性取得API(UserInfoAPI) - Yahoo!デベロッパーネットワーク ( 版) http://developer.yahoo.co.jp/yconnect/userinfo.html

given_name#ja-Kana-JP カナ名 profile ユーザーが登録している名のヨミガナを返却します。最大100文字の可変長です。

given_name#ja-Hani-JP 漢字名 profile ユーザーが登録している名の漢字を返却します。最大100文字の可変長です。

[224] 用字副タグについて · Issue #54 · hfu/noteworthy · GitHub, https://github.com/hfu/noteworthy/issues/54
  1. ja, ja-Latn, ja-Kana, ja-Hira, ja-Hrkt は使うかもしれない
  2. ja-Jpan は RFC 5646 の SHOULD 規定により使わない、ということになる
  3. ja-Hani を使うこともないと思う。いわゆる Han-Unification 的な扱いになるので、かえって混乱を起こす可能性もあるし。また、漢字のみということをわざわざ示す必要があるユースケースはないのではないか。ja-Hani と書きたくなった場合には、ja とすれば OK である場合が多いと想像する
  4. ja-Kana がカタカナだというのがトリッキー

[225] >>224 3. は誤解。漢字統合Hani は無関係。

[226] 用途がないというのはその通りで、万葉仮名など特殊な事例以外で ja-Hani の出番はなさそう。

[228] 2. がどの SHOULD を指すのかこの記述だけでは不明ながら、 用字系抑制の規定を指すと推察されます。

[306] >>305ja-Jpan とともに ja-Hani を例示しています。 意図はよくわかりません。

複数の言語/スクリプトの組み合わせの名前 (たとえば日本語の [漢字 + ひらがな + カタカナ、xml:lang="ja-Jpan"] および漢字 [xml:lang="ja-Hani"]);

[307] Attribute: Language, , https://jats.nlm.nih.gov/archiving/tag-library/1.1d1/n-pxx2.html

Thus, for example, the following are among the expected values of @xml:lang for Japanese, incorporating both a language (“ja”) and a script type:

[308] >>307 これは機械的に全組み合わせを例示していて、確かに値の説明にはなっていますが、 いつ何のためにこれらを使うべきなのかは何も説明されておらずわかりません。


[296] 平成22年度の日本政府総務省の事業であるメタデータ情報基盤構築事業のまとめた指針は、 RDF において特性の値の言語タグja-Kanji (原表記) と ja-Kana (読み、実例ではひらがな) で区別する方法を推奨していました。 >>295

[297] メタデータ情報基盤構築事業はその他に、 本来表記と読みが区別される場合において、 仮名の読みとローマ字の読みを区別するため ja-Kana (実例では片仮名) と ja-Latn を使う方法を示していました。 >>295

[299] 2つ方法が示されていますが、 この方法「も」推奨されているのかどうか、指針の書き方が曖昧でよくわかりません。 しかも実例を重視した書き方のためどこまでが推奨される規定でどこからが例示に過ぎないのかがよくわかりません。 特に、具体的な言語タグは例示内にしか出現しないので、 それらは例に過ぎず実際には読み手の責任で選べというのかもしれませんが、 それだと指針として統一的な構造を要求する意味がないですよね... 平成時代後期の技術仕様書としては品質に難ありで困ったものです...

[300] ここで ja-Latn を使っているということは、 4文字の用字系部分タグ標準化を認識した上で書かれているはずですが、 片仮名を表す Kana平仮名片仮名の両方を認めていたり、 4文字の用字系部分タグではない Kanji で「じゃない方」を表していたり、 微妙に独自路線を行っているのが不思議です。

[301] 用字系部分タグ標準化される前の言語タグの旧仕様なら、 そのように好きに使って構わなかったのですけどね。新仕様を認識した上で、 旧仕様時代の蓄積があるわけでもなさそうなのに、謎です。

[294] RDF において ja-Hani (原表記) と ja-Kana (片仮名) による区別を例示した解説もあります。 >>293 >>296 とよく似た内容であり深い関係性が窺われます。

[282] 日本国立国会図書館が運営するジャパンサーチja-Kana を使っています >>280, >>284 が、 なぜかその意味を

言語タグja-Kanaは、カタカナだけでなくひらがなを含めた読みのために用いる。

と定めています >>281。これは明確な誤用です。しかもこの書き方から、 Kana片仮名だとわかっていて敢えて使っているように読めますが、 その意図は説明されておらず不明です。

[283] 不明ではあるのですが、 >>296 から >>294 を経て >>282 に至ったとすれば話が綺麗に繋がります。 話は繋がるものの、「なぜ」はやっぱり不明です。

[302] 日本政府として Kana片仮名を割り当てた変な符号体系に抗議したいということなら、面白い試みなのですが...
[303] https://fit.repo.nii.ac.jp/record/407/files/DC_Ko_k_50.pdf #page=40

立花祭ホームページの URI を主語として記述し,立花祭に関する記述を別の triple の集 合として整理している.その URI が“立花祭”であることを rdfs:label により示している. 共通語彙基盤では ic:カナ表記として“タチバナサイ”を記述しているが,図 24 のように @ja,@ja-Kana のように別の表記として記述することが可能である.この他,漢字表記の 場合は@ja-Kanji,ローマ字表記の場合は@ja-Lath,英語の場合は@en,中国語の場合は@zh のように言語タグによって別の表記として記述できる.但し,基本的にラベルやタイトルな どのプロパティは1つの主語に対して1回の出現回数とする制限があるため,「"立花祭"@ja, "福岡工業大学立花祭"@ja」のように記述することは誤りである.言語タグが異なるならば, 1 回の出現回数という制限がある場合でも複数のリテラルを定義できる.

[304] 図24では本来表記に jaカタカナ表記に ja-Kana を使っている。 ja-Lath は明らかに誤りで、利用例は示されていない。 ja-Kanji の利用例も示されていない。

読み仮名やローマ字表記と「じゃない方」を言語タグで区別すること

[232] ja-Hiraja-Kana のような言語タグ読み仮名用の識別子に使われることが多いですが、 「読み仮名」という言葉が持つ「本来の表記は漢字仮名混じりであるところ、 発音を明確にするため仮名表記でも併記する」というニュアンスは言語タグ自体には表れていないことには注意が必要です。 そのようなニュアンスが必要だとすると、言語タグではなくそれを利用する文脈 (プロトコルデータ形式やそれらを活用する応用) の側で定める必要があります。

[377] ja-Latn で「読み仮名に相当するローマ字表記」を表すこと、 jaja-Jpan で「じゃない方」を表すことも同様です。

[233] 例えば日本語 (ja) と英語仏語と・・・のデータを併記できる多言語文字列対データがあったとして、 そこに ja-Hira のデータを追加したとしても、 日本語英語仏語と並列の別の言語のデータと解釈されるのが自然で、 jaja-Hira が対になっていてセットで使われるデータと解釈されるためには特別の規定と処理が必要になります。

[368] RDFリテラル言語タグを使って読み仮名ローマ字と「じゃない方」 を区別する方法を採るには、RDFデータモデルのレベルでは何の規定もありませんから、 語彙意味なり、処理モデルなりに於いて明示的に定める必要があります。

[369] 例えば

の2つのがあるとき、 この2RDFデータモデルのレベルではまったく無関係です。

  • [372] 2つのはたまたま S, P が一致するだけで本当に無関係
  • [373] v, w は同じものをまったく別の表現で記述している
  • [374] vw は同じ語で、 v と書くこともあれば w と書くこともある
  • [375] vw は同じ語で、 v が通常の表記で w はその読み仮名である

など、いろいろな解釈の可能性があります。

[376] そのいずれであるかを確定させたければ、 P の定義においていずれであるかを明確にするなり、 いずれであるかを定めるための別のを付け足すなりしなければなりません。


[234] 読み仮名だけでなく「平仮名のみの文章」や「片仮名のみの文章」も ja-Hiraja-Kana で表される対象であることにはやはり注意が必要です。 具体的には、

のようなものがあります。 設計者はこうしたものと読み仮名の共存が必要かどうか、可能かどうかを考慮しなければなりません。

[367] ja-Latn で「読み仮名に相当するローマ字表記」を表すことにも、 同じことが言えます。 「読み仮名に相当するローマ字表記」以外の日本語ローマ字文は例えば

があります。これらにもやはり ja-Latn が使えます。


[359] また、読み仮名として使う場合もそれ以外として使う場合も、 Hira, Kana, Hrkt を指定したからといって、厳密に平仮名片仮名のみでなければならないわけではないことには注意が必要です。

[360] 例えば、「「住所の読み仮名 (ja-Hira)」欄 で欧州数字を仮名に開かずそのまま含めること」 「漢数字が混じった仮名文書ja-Hira で表すこと」 「慣習により漢字に置換した仮名異体字ja-Kana の文章に含めること」 「, -, などの記号を含めること」 には問題がないと考えられます。

[361] 勿論言語タグを使う応用仕様や実装の個別具体の規定により、 こうしたものを認める、認めない、と決めることはできます。 しかしそれは言語タグそれ自体から導かれる規定ではなく、 応用独自の規定が必要となります。

[362] なお、全角カナ半角カナの違い、 濁点文字合成に関する記述の違い、 標準仮名と変体仮名などは、 文字コードに関する技術的な差異に過ぎず、 言語タグ/用字系符号とは独立した問題です。

[363] 例えば「半角カナで表されるヨミガナ」 「全角カナで表されるヨミガナ」 「半角カナでも全角カナでもいいのでヨミガナ」 のいずれも ja-Kana で表すことができます。


[378] なおこうした言語タグによる区別の方法で表現できるのは、 いわゆる読み仮名のうち、欄単位で区別されるべきものだけであることにも、 注意が必要です。

[379] 読み仮名には他にも語単位で記述するもの、文字単位で記述するものがあります。 読み仮名 そうした記述力が必要なら、欄単位の言語タグの記述の仕組みではまかないきれません。 HTMLruby 要素のような細やかな記述ができる機構が必要となります。 ルビ


[279] >>278 これは言語タグによる区別でいいのではないかとの問いに対し、 読み仮名であることを別に表す方が便利との回答。

旧表記日本語の識別子

[354] 昭和時代国語改革の前後の表記法の違いを表したいという需要があります。


[74] 平成時代中期頃、正字正仮名文の言語タグの提案がいくつかありました。 実用例は見当たりません。

[69] ねこめしにっき(2001年4月中旬), , http://www.remus.dti.ne.jp/~a-satomi/nikki/2001/04b.html#d11n03

野嵜さんのテキストの引用部分へ lang="正字正假名-ja" を指定する事にして事無きを得てもよいですか。(笑)

[70] 未実施
[71] あくせくしているびりてい - カナかな団の躁鬱, 投稿者 首領, 投稿日 2001年07月26日 11時32分, http://www.aboutworks.com/shokodei/diary/read?200107e03#PrintNo3

そこで、現代かなづかいを"ja"、正字正かなを"valid-ja"、ついでに(謎)かなづかいを"nazo-ja"、ってな感じで追加するというのは……駄目ですか……?

[73] 言語コード - カナかな団の躁鬱, 投稿者 首領, 投稿日 2001年07月26日 16時39分, http://www.aboutworks.com/shokodei/diary/read?200107e01#PrintNo3

"valid-ja"では駄目ではないですか。

よって正字正かなは"ja-nippon"、(謎)かなづかいは"ja-nazo"にしなくてはいけましぇんね。この方法で行くと各地の方言もカバーできそう……。"ja-ibaraki"とか"ja-ohsaka"とか。

>>71 を引用

[37] 正字正假名日本語ja-trad と表す提案がありました。 >>53


[353] 平成時代終わりから令和時代初期にかけても新旧表記法の識別子の提案はちらほらあります。

[323] 現行の新字体が最初に制定されたのは当用漢字字体表当用漢字表の制定年で、誤り。 なお、現在通用する新字体はその後の常用漢字表による改正(追加)および人名漢字による事実上の改正も含まれるので、 単一の年号で表すとすると平成2年あたりのどこかになるはず。 (特定の法令による表記を指すのではなく「新字」を指したいときに年号で表すという手法がよくない。)

[143] Pleroma/nixeneko, https://nixeneko.info/notice/9iXYptD9JgifHDGuZs

PleromaにJapanese (Traditional)とかいって旧字旧仮名ロケールを追加したらどうだらう

[144] Pleroma/nixeneko, https://nixeneko.info/notice/9iXaJ219kjqqwS7cwK

現状のPleromaの言語、言語タグでいくとja-Hrktといった趣がある。

[145] Pleroma/nixeneko, https://nixeneko.info/notice/9iXeyQQMJYpkKJu6CG

旧字旧仮名日本語の言語タグ、ja-x-tradとかになるのかな。

[146] 令和元年の投稿

[314] LIISコード仮名遣い漢字字体の組み合わせで4種類の符号が定義されています。 (>>313)

[352] 言語タグとして使う方法も決められています。 しかし ja- から始まらないので、対応していない一般の実装で日本語扱いされないのが実用上の難点です。

日本語点字表記の識別子

[341] 点字Brai で表されますから、 日本語点字表記したもの全般は ja-Brai で表せます。

[345] 効果的に活用した事例は未見です。

[344] 言語非依存の点字入力用鍵盤定義が ja-Brai を採用した事例があります >>342, >>343 が、これはいろいろな言語を機械的に列挙しただけです。

[346] 日本語点字表記法は、代表的なものの他にも何種類かあります。 日本語点字 ja-Brai は具体的にどの表記法を採用するかを指定せずに点字全般を表しています。 区別の必要があるなら、より細かな区分の言語タグを用意することになります。

日時表示

[23] 元号を使うことを明示するために言語タグ ja-JP-u-ca-japanese を使うことがあります。

[57] 明示しないからといって和暦でないことにはなりません。

[56] また、 日本関係の u-nu の値として、 jpan, jpanfin, jpanyear があります。 数字表記の方法を明示したいときに言語タグに組み入れて使うことができます。


[165] >>164ja-JP-u-ca-iso8601-tz-jptyo という例を示しています。日本国日本語ISO 8601 式の東京時間を表します。

[166] >>164 は「ISO 8601 形式の日付・時刻、日本標準時」と解説していますが、 u-ca の登録では iso8601

ISO calendar (Gregorian calendar using the ISO 8601 calendar week rules)

と説明されています >>171。 つまりただ ISO 8601暦というだけではなく週暦を表しています。 これを「ISO 8601 形式の日付・時刻」と要約するのは甚だ誤解を招きます。

[167] 人工的な用例の提示とはいえ日本でほとんど利用のない週暦をわざわざ使った意図は謎で、 >>164著者も「ISO 8601 calendar week rules」を見落としている可能性があります。

[169] というか >>164Unicode Consortium の登録簿か何かから「抜粋」して

iso8601ISO-8601 Calendar↑↑↑ISO-8601

と書いているのですけど、この「抜粋」する前の記述はどこなんですかねえ。 大事なところが省かれてるじゃないですか。

[172] ということで探したらありました。登録簿 >>171 ではなく表示用の文字列データ >>170 では「ISO-8601」「ISO-8601 Calendar」のようになっていて、 >>164 はそれを拾っていたのですね。 変な定義した Unicode Consortium と不正確なラベルを付ける Unicode Consortium が一番悪く、 定義でないところを参照した >>164 がその次に悪い。

[168] 週暦を 「ISO 8601」 とだけ呼んで表すのはほとんど誤りに近いので、そのような用法は避けるべきですが、 たまにそう呼ばれているのもまた事実。

変形

[199] 言語タグ拡張Tを使うとどのような変形を経て得られたものかを記述できます。

[200] 拡張Tの仕様等で次のような利用例が示されています。 拡張T

[204] 「変換」は広い意味で使うことができるので、外来語ローマ字をはじめいろいろなものの記述に適用できそうです。

[391] Englishから機械的に翻訳された日本語を表すため ja-x-mtfrom-en が使われる事例があります。 -x-mtfrom-

[390] 音声から機械的に生成された文字データを表すため ja-x-autogen が使われる事例があります。 -x-autogen-

絵文字

[255] >>254絵文字フォント選択の制御のために拡張Uを使う例を示しています。

[256] 説明のための人工的な例で、実用的ではありません。

その他位相言語の識別子

mul-kambun (言語タグ)

[92] mul-kambunは、 (日本の) 漢文用の言語札です。

[93] この言語タグ平成時代中期に定義されました。

[94] 漢文中国語 (ただし現代中国語ではなく、古典中国語) としての性質と日本語としての性質を併せ持っていますから、 mulと札付けするのが適当だと考えます。

[95] 白文訓読文書き下し文のいずれにもmul-kambunを使えます。 これらを区別する必要がある場合のlanguage tagも必要かもしれませんが、どういう名前が良いか検討が必要です。 和様漢文を区別する必要があるかも検討が必要です。

[96] 朝鮮語等の、日本語以外における中国語は対象外としています。

[161] 中文言語タグも参照。

[364] でも表示その他の応用を考えると、 ja- から始まる言語タグに改めた方がいいかもしれないですねえ。 大陸由来のものも含め、日本で扱われる漢文日本語表記の1つといっていい ( 中文言語タグ ) ものになっているとも考えられますから。

ja-2ch (言語タグ)

[97] ja-2ch2ちゃんねる語を表す言語タグです。

[98] 平成時代中期に独立して方々で考案され使われました。

[134] 当時は ja-2ch は仕様上も正当な言語タグでした。その後 IETF言語タグの仕様書が改定され、 一般で使われている言語タグの実情を調査することもなしに非互換変更してしまったので、 現在のIETF言語タグの仕様では規格違反になってしまいます。

[135] 利用者はこの問題を深刻に捉える必要はありません。 非互換変更は完全に IETF のミスです。 2ちゃんねる語2ch の衰退でほぼ死語で、 今後この言語タグが今まで以上に普及するとは考えにくいので、 今更理論上だけの仕様適合性にこだわるより、従来の記述方法との連続性の方が重要です。

[111] <img longdesc=...>について ( 版) http://deztec.jp/x/10/faireal/d11223_2.xml

同様の遊びとして、

<q cite="http://pc.2ch.net/..." lang="ja-2ch">ハゲ銅!ahooのせいでみかかが株をあげたと思われ。</q>

なんてこともできます。

[115] 一行づつタグを書いてHPを完成させるスレ Web制作@ネット関係(1から200までのページです) ( 版) http://viva2ch.net/hp/1010056747-0.html

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja-2ch">

[133] >>131 の例文は ja-x-2ch を使っています。

Mac 用日本語の識別子

[49] ja-JP-macja-JPM は、 Macintosh の用語の指針に基づいた日本語を表すロケール識別子として平成時代中期頃の Mozilla プロジェクト関連製品で使われることがありました。

[356] プラットフォームごとにUIの用語の指針があり、 Mac 用とそれ以外を区別する必要があったために、 このような識別子が使われたのです。 ある種の位相言語を記述したものといえます。

[50] L10N FAQ - 日本語パックについて http://www.mozilla-japan.org/jp/l10n/faq/jlp.html#what_is_ja-JP-mac

[51] 418485 – "ja-jp-mac" is not a valid language code. Please stop using it. ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=418485

[355] 時系列は要調査ですが、おそらく最初に使われ始めた時点の仕様では、 ja-JP-mac は正当な言語タグだったはず。 ja-JPM が構文的に適当でないと ja-JP-mac に置き換えられたのです。 その後 IETF言語タグの仕様が改定されて非妥当にされてしまいました。

[52] ja-JP-mac (Language tag) - SuikaWiki Data ( 版) https://data.suikawiki.org/lang/ja-JP-mac

子供向け平仮名表記日本語

[105] 翻訳管理サービス Transifex の対応言語の1つに 「Japanese (Hiragana) (ja-Hira)」 があります。 >>112

[116] ただしこの Transifex の言語リストに示された符号がどのようなものなのかは明記されていません。 構文は POSIX locale 識別子に近いようですが、 ja-Hira のように IETF言語タグにも見えるものが混じっています。

[357] ja-HiraIETF言語タグだとすると、 「平仮名表記の日本語」 を意味しています。

[117] この 「Japanese (Hiragana)」 がどのような利用を想定したものなのかはよくわかりません。

やさしい日本語

[100] やさしい日本語には言語タグ ja-simple を使えます。 >>99

[101] 日本語を表す言語部分タグ ja と、 簡易化された言語変種を表す異体部分タグ simple >>103 を組み合わせたものです。

[263] ただし、 ja-simple は単純化された日本語全般を表し、 やさしい日本語だけを表すのではないことには注意が必要です。 例えば、

といったいろいろなものが ja-simple に当てはまり得ます。

[272] もし他の平易な日本語と異なるやさしい日本語だけを特定したい場面や、 何種類もあるうちの特定のやさしい日本語指針等に従ったものだけに限定したい場面があるなら、 より限定的な専用の言語タグを決める必要が出てきます。 今のところそのような提案はなされていないようです。

[104] なおやさしい日本語を使うプログラムで ja-basic も使われている >>99 とありますが、 IETF言語タグとして出力される場面があったのかは不明。 さらっとコードを眺めた感じは内部用のみで外には出していない (ja-JP を使っている) ように見えます。

[273] もしそうだとすると、 >>99 の投稿者は basic が登録されたIETF言語タグ部分タグでないことを問題視していますが、 そもそもIETF言語タグではないので何も問題はありません。 >>99 が却下されたのもそれが理由なのでしょう。

[122] このコードは日本国東京都の運営するウェブサイトだったのですが、 本段落執筆時点で既にサーバーが停止されていて閲覧できません。 Internet Archive だと参照しているファイルを読み込めずに、読み込み中の表示から先に進みません。 開発にも運営にも、 行政が公開した情報を次の時代に伝えようという意志がまったく感じられない酷いサイトですね。

[274] おかげで >>104 >>273 が正しいのか検証するのは困難です。

[124] ソースコードが残っているだけまだ良心的ですが、それも GitHub が永続的に保存してくれているからというだけの話なので、 ほんとにたまたま残ったものが少しだけあったということです。

[123] 自治体のウェブサイト運営の失敗事案として語り継いでいくべきですね。

[99] 「やさしい日本語」の言語コードを "ja-simple" に変更 · Issue #1801 · Tokyo-Metro-Gov/covid19 · GitHub, https://github.com/Tokyo-Metro-Gov/covid19/issues/1801

likibp commented on Mar 19, 2020

  • 現状、「やさしい日本語」の言語コードは、コード内では "ja-basic" , transifexでは "ja-Hira" を使用しています。
  • "basic"というサブタグはLanguage Subtag Registryに登録されておらず、"Hira" はその名のとおり平仮名のみの表記を示すサブタグであるため不適切です。
  • よって、「やさしい日本語」の言語コードを "ja-simple" に変更することを提案します。

怪しい日本語

[309] いわゆる怪しい日本語の主流である、 中華人民共和国の業者等が日本市場向け製品説明等で使う独特の日本語は、 言語タグ ja-CN で表すのが適当と考えられます。

日本語系人工言語

[311] いくつかの日本語系の人工言語LIISコードが割り当てられています。 言語タグとしても使えます。 >>312

日琉諸語の記述体系への要求

[30] 日本語の方言にも星の数ほど種類がありますから、全部 ja-foo にすると大変なことになります。

一つの提案として、日本国内の地域を主要な使用域とする方言は ja-JP-大地域名-* とし、大地域名としては地域名 (kansai など), 現行の47都道府県名, 明治時代の旧国名くらいに制限し、それ以上の細かいものは地域的あるいは言語的に近いものの小分類としてはどうでしょう。

[24] ただ、大阪弁ja-JP-oosaka にするのか ja-JP-kansai-oosaka にするのかみたいな話になりますが。

[154]関西弁」と指定したい時と、「大阪弁」「神戸弁」「京都弁」「奈良弁」「エセ関西弁」 と細かく指定したいとき、はそれぞれある。

[158] 一般に使われている区分と学術的な区分と、どちらもそれぞれの使い道がありそうなので、 1つの体系だけで揃えるのではなく方言と認識されている実態があれば全部それぞれ名前を与えるべきだろう。

[159] 変に階層化して長くて使いづらい名前にするより、階層なしでも一般の呼び名に近いものにすれば衝突のおそれもそうそうないだろうし。

[160] ウィキペディアに項目がある方言は一通りあってよさそうだな。

[334] 日本語方言にどんな「方言」が扱われているかいろいろ実例あり。

[338] 方言研究は歴史が長い分野のはずなのに、一覧にして識別子を割り振ってく試みは行われてこなかったのかなあ、全然見つからないなあ。

[339] 学者がやると分類をどうするかとかで揉めそうだしなあw

[35] 言語タグの一覧も参照。

[38] 「日本語 平成22年正書法」 「近代日本語」 「日本語候文」 「日本語片仮名漢字混じり文」 「日本語 旧字体現代仮名遣い」 「日本語 お嬢様言葉」 「日本語総ルビ」 のような違いも言語タグで記述したいなあ。

[44] ja (Language tag) - SuikaWiki Data ( 版) https://data.suikawiki.org/lang/ja

[40] ja-JP (Language tag) - SuikaWiki Data ( 版) https://data.suikawiki.org/lang/ja-JP

[152] 文体と表記法の記述 (script (コーパス), style (コーパス) より) : 文語体, 口語体, 文語体口語体の混在, 漢文, 韻文, 漢字片仮名交じり, 漢字平仮名交じり, 万葉仮名

[153] その他文体関係 : 書き言葉, 話し言葉, 訓読文, 書き下し文, 宣命体, 候文, 漢文調, であります, ですます調, だである調, 翻訳調, 敬語, 男言葉, 女言葉, 業界用語, お嬢様言葉, ギャル語, おじさん構文, 西洋人風, 中国人風, 赤ちゃん言葉, ルー語, ロコ語, エミリー語, 協和語, 横浜ピジン日本語, 日本語対応手話

[155] 語尾役割語の類は無限に増えているので、無限の記述能力が必要。 (そのすべてを言語タグで記述できる必要があるか、という論点はありそう。)

[156] 表記法関係 (用字系札より、その他) : 漢文 (白文), 訓読文, 書き下し文, かな漢字混じり (全般), 平仮名漢字交じり, 片仮名漢字交じり, 平仮名, 片仮名, 万葉仮名, 教育漢字年生 (元号年式), 当用漢字字体表, 元号常用漢字, 元号人名漢字, 表外漢字字体表 (印刷標準字体 / 簡易慣用字体), 旧字体 / 新字体, 御家流, 初唐標準字体, JIS X 0208, JIS X 0213, 制限付き JIS X 0213, MJ, MJ+, 歴史的仮名遣, 棒引き仮名遣い, 現代仮名遣, 送り仮名規則, 濁音無表記, 撥音無表記, 小書き仮名有無, 長音無表記, 分かち書き有無, ローマ字 (全般), ヘボン式ローマ字 (新旧), 訓令式ローマ字, 日本式ローマ字, ローマ字長音各種, キリル文字表記, ハングル表記, 日本点字, 漢点字, 6点漢字, 速記文字各種, モールス符号, 乎古止点各種, 振り仮名無/有/総, 句読点有無, 句点文字, 読点文字, 左横書き/右横書き/縦書き, 元号公用文

[157] その他ロケール関係: 和暦/西暦/併記, 北朝/南朝/併記, 皇紀, 干支年/十二支年, 12時間制/24時間制, 十二支時刻, グレゴリオ暦/旧暦/併記, 中央標準時/西部標準時/小笠原の標準時/台湾の標準時/関東州の標準時/南洋群島の標準時, SI/尺貫法, 単位記号/単位片仮名名/単位漢字名, 欧州数字/漢数字, 画線法, 位取り記数法/漢数字記数法, 3桁区切り/4桁区切り, 桁区切り/,, 小数点./

[335] 10-6-B3-3.pdf, , https://www.topic.ad.jp/ipsj-tohoku/archive/2010/report/report14/10-6-B3-3.pdf

[336] >>335 年代差を考慮した方言翻訳システム。このような要件を記述したいこともあろうが、 生まれ年 (世代) と年齢とどちらだろう?

[337] 言語の記述を目的にするなら生まれ年だろうし、実用を目的にするなら年齢の方が使いやすそうではあるが...

[347] 引用/翻刻ポリシーや包摂規準的なものも記述したいことある。 「片仮名を平仮名になおして引用」とか「新字新仮名とした」とか「青空文庫基準」とか。

[348] マーク付け言語の領分のような気もするが、 -t--mtfrom- があるのだから言語タグで書くのがいい場面もある。

[351] 教育ローマ字 (>>315) や一般に用いられる仮名アクセント表記含め、音声寄りの表記法各種 (>>350) も言語タグで記述できると嬉しいですね。

関連

[75] アイヌ語言語タグ, 日本手話

メモ