[262] 大文字と小文字は区別しません (どちらでもいいです) が、 プロトコル等で特別に定めていることもあります。
ja (言語タグ)[81] ja は日本語を表す ISO 639 言語符号であり、
言語タグであります。
[82] 特に細かい指定が必要ないときはこれを使います。
ja-JP (言語タグ)[21] 日本国で使われる日本語と特に明記する必要がある場合は、
言語タグ
ja-JP を使うことができます。
[59]
実際には、日本国以外で日本語が使われる場面は多くなく、
しかも国の違いを明示する必要がある場面はその中でもわずかなので、
ja
とだけ書くのが一般的です。
[60]
特定のプログラムの仕様等で地域部分タグが必須な場合や、他の言語タグとの統一性のため地域部分タグを明示したいような場合もあって、
ja-JP が使われることもままあります。
しかしそうした事情がなければ、短くて必要十分である ja
が望ましいと考えられます。
ja_JP (POSIX ロケール識別子)[58]
POSIX locale ja_JP は日本国の日本語のロケールを表します。
[61] POSIX では言語符号と国符号を組み合わせて両方明記するのが一般的です。
[62]
稀に誤って言語タグ ja_JP が使われることがあります。
(この誤りは日本語以外の言語タグでもみられます。)
言語タグの構文に違反しており、明確な誤りです。
jp (言語タグ)[7]
jp は、
たまに使われる日本語を表しているらしい言語タグです。
[39] 言語タグ jp は誤りです。正しくは ja です。
[64]
国符号が JP なので、よく日本語も誤って jp と記述されるのです。
[65]
多くの実装は jp に対応しておらず、未知の言語とみなします。
[66]
なお、日本語を ja と表し jp と表さないのは ISO 639
言語符号の仕様に過ぎず、人間同士で便宜上用いる略号や、
ISO 639 以外の言語符号で日本語を 「jp」「JP」
と表すことは必ずしも誤りではありません。
[67] ただ、紛らわしい表現であることは確かです。 また、日本語のことを人間同士で「JP」や「JA」と略すのは、 英語話者の間でも、日本語話者の間でも、 一般的な表現ではないので、伝わりやすいとはいえません。 確実に伝わるといえる場面以外では避けるべきです。
<html lang="jp">
<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">
<html lang="jp">
<html class="gs-fontSmall" lang="jp">
[68]
また、 Accept-Language: に相当する Webブラウザーの設定に自分で
jp
を追加している人も稀にいるようです。
jpnjapanese (言語タグ)[83]
極めて稀に言語タグ japanese が使われることがあります。
[85] 対応している実装はみたことがありません。
日本語 (言語タグ)[88]
極めて稀に言語タグ 日本語 が使われることがあります。
[90] 対応している実装はみたことがありません。
jpx[126] >>125 は津軽弁を追加しようとしたものの、言語タグがわからず、(おそらく)断念しています。
[127] 言語タグ体系が整備されていないことで自分の使いたい言語を自由に使えないという実害の1事例といえ、 由々しき事態です。
[380] 関西弁は現代日本語のうち標準語/共通語を除いて最もよく用いられ言及される方言で、 これを計算機システムで実装しようとした試み (商用システムで実戦投入されたものを含む。) もかなりあります。
[382] しかしその識別子は既成の標準規格がまったく対応できていないために安定性を欠いているのが実情です。
[381] 適切な標準の欠如が言語的多様性の実現の障害になっているとも考えられ憂慮される状況ですが、 打開の見通しも立たないのが現状です。
[2] ja_KS は、 Facebook が関西弁を表すために使っている
>>1 ロケール識別子です。
[3] 他の ja_JP などは POSIXロケールと同じですが、
ja_KS は Facebook 独自のもので、 Facebook
以外のシステムでは使えません。
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だった)、 その後の仕様の非互換変更のせいで、本稿執筆時点では非妥当な言語タグになってしまっています。
[249]
大阪弁の言語タグに ja-osaka
があります。
[250] 古くから例文でよく使われています。大阪弁の言語タグの事実上の標準といって良いでしょう。 実利用がどれだけあるかは不明です。
ja-osaka (日本の大阪弁)
ja-osaka(大阪弁)
x- で始まるコードはプライベートに使用することが許されています。
x-uchuujin(宇宙人語)
ja-osaka(大阪弁)
x- で始まるコードはプライベートに使用することが許されています。
x-uchuujin(宇宙人語)
ja-osaka(大阪弁)、en-us(米国英語)
x- で始まるコードはプライベートな言語として使用することが許可されています。
x-orelang(自分が勝手に作った言葉)
assert_equal Locale::Tag::Rfc.parse("ja-osaka"), lang.to_rfc
<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言語タグで琉球諸語を表すものがあります。
[148]
>>147 は沖縄語の辞書の XML 移植版ですが、
ryu-Hira,
ryu-Jpan,
ryu-Latn,
jp-Jpan
を使っています。
最初の3つは沖縄語の見出し語の各種表記、
最後は日本語の説明文。
[149]
IPA 発音記号列を Latn とするのは誤りではないものの、違和感があります。
[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-Hira
と
ojp-Hani
で平仮名表記と万葉仮名表記を区別しています。
[313]
LIISコードがいくつかの日本語表記体系・歴史的日本語に符号を割り当てています。
>>312
言語タグとして使う方法も定められています。
or:japn_trs:現代日本語(伝統仮名遣い・正字体)or:japn_trn:現代日本語(伝統仮名遣い・新字体)or:japn_mds:現代日本語(現代仮名遣い・正字体)or:japn_mdn:現代日本語(現代仮名遣い・新字体)hs:japn_emd:近世日本語hs:japn_lmi:中世日本語hs:japn_emi:中古日本語hs:japn_old:上代日本語 <{iso3}ojp はこれに正規化する>or:chan_kun:漢文訓読体[389]
>>388 は題名に「傳統假名翻譯」とあり、
言語選択に「漢文訓読体」とある版ですが、
HTML lang="" 属性値がIETF言語タグ
x-liisor-chankun
となっています。「漢文訓読体」のLIISコードです。
「日本語」の原文と比較すると、本文内容はほとんど同じで、
一部語尾が違う程度で文体の変更はありませんが、旧仮名遣いであり、
旧字体を使ったり仮名を漢字に改めたり、
近代風の漢字の遣い方に改めたりしています。
[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
が使われることがあります。
[77]
言語タグ
ja-Hrkt >>222
が使われることがあります。
ひらがなかカタカナかを問わないことを示すためでしょうか
(>>222 の例示はすべて平仮名)。
[275]
Semantic Web 系のデータベースでよみがなの意味の ja-hrkt が実用されている事例
>>310
をみました。
[298]
なお ja-Kana については >>282 も参照。
[366] 読み仮名と「じゃない方」を言語タグで区別することについては、 >>232 も参照。
国内の経路検索事業者においては、よみがなを必須としていることから、よみがな(lang=ja-Hrkt)を設定することを必須としています。
- 言語タグは、Web NDLA では「よみ」にのみ用いています。例えば「図書館」の場合、カナ読み
を "トショカン"@ja-Kana、ローマ字読みを"Toshokan"@ja-Latnとしており、言語タグによって読みの種類を区別できます。
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桁の言語コードが存在しない場合は、言語コードを記入しない。
これら 2 つの属性では、locale サブ属性に言語を表す値を設定することで、クラウドサービス
が 必要 とす る言 語の 値を 取り 出す こと に対 応す る。 locale サブ 属性に 設定 する 値に は、 [RFC5646] の形式で、IANA Language Subtag Registry に登録された値を用いる。同一言語で 異なる表記がある場合は、script subtag の値を含めることで対応する。具体的には、次のよう な値とする。
No 表記 locale サブ属性に使用する値 1 漢字表記 ja-JP 2 よみがな表記 ja-Hira-JP 3 ローマ字・英語表記 en-US よみがな表記は「ひらがな」で値を設定するものとする。クラウドサービスが「カタカナ」で
値を必要とする場合は、クラウドサービス側で「ひらがな」で受け取った値を「カタカナ」に変 換する。
氏名の言語
typeと一致させる必要があります
入力可能な値は以下です
- ja-JP
- ja-Hira-JP
[91]
日本語ローマ字表記を表す言語タグ
ja-Latn
が使われることがあります。
>>162, >>209, >>211, >>223, >>229, >>231, >>251
[241] ほとんどの用途は読み仮名に相当するローマ字併記を表すものです。 これについては >>232 を参照。
読みを付加する優先ラベル(=名称/タイトル)と代替ラベル(=別名/別タイトル、同義語)の表現には、SKOS拡張の
skosxl:prefLabelとskosxl:altLabelをそれぞれ使用します。読みの記述には、DC-NDLで定義されるdcndl:transcriptionの語彙を使用します。典拠レコードでは、カタカナ読みとローマ字読みの2つの読みを保持しており、それぞれ言語属性”ja-Kana”と”ja-Latn”を用いて区別します。
、 "ja" 、 "ja-Latn" 、
[173]
登録ファイル付でIANA登録簿に登録された異体部分タグ
hepburn
があります。
接頭辞は
ja-Latn
とされます。
ヘボン式ローマ字を表します。
>>174
[175]
つまり言語タグ
ja-Latn-hepburn
で日本語のヘボン式ローマ字表記を表せます。
[176]
この hepburn の登録には、
のヘボン式考案から近年のウェブページまでいろいろが参照されています。
そしてヘボン式には色々な変種があれども、それらを区別するのは生産的でないと主張しています。
>>174
つまり hepburn は「ヘボン式といわれるいろいろな手法のどれか」を表しています。
[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
に該当するのかhepburn
に該当するのかhepburn に該当するのかhepburn に該当するのかといったようなものですが、いずれも hepburn の意味の根幹に関わる疑問です。
[196]
なおローマ字以外にヘボン式は存在しないので
Latn と明示するのは冗長に思われますが、
ja-Latn
にしか対応していない実装でも
ja-Latn
にフォールバックできるというメリットがあります。
<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 が好ましいとされています。
つまり
ja-Latn-hepburn-heploc
は
ja-Latn-alalc97
とするべきとされています。
>>190
[195]
わずか数ヶ月での朝令暮改ですが、これは登録ファイル付で日本語に限定しない
alalc97 が登録された
>>191
ためそちらに寄せるべきと判断されたことによります。
ja-Latn-hepburn-heploc
を
ja-Latn-alalc97
に置き換えるべきと実装するのは不可能です。これは当時指摘されていますが >>246、
対処されなかったようです。[245] ヘボン式以外の方式、例えば訓令式用で広く通用する言語タグはありません。
[205] 拡張Tによって記述できる転写方式もあります (>>199)。
[208]
>>207 は
ja-Latn-s-Hani-t-Hepburn (ヘボン式),
ja-Latn-s-Hani-t-Kunrei (訓令式)
という例を示しています >>207 が、
これらは当時の提案
(後に拡張Tに統合され構文がまったく違うものに変更されたもの。)
に沿って >>207 のブログ記事著者が独自に考案した利用法を提案したもので、
このまま使うことはできません。
[258]
ja-Latn-x-hepburn
を使ったものもあります。
>>257
<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
とするのは厳密には誤りに近いですが、
実運用上日本語ローマ字と英語の区別が難しいことも多い
(
[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
を使うべきです。
- xml:lang=“en” 英語
- xml:lang=“ja-Jpan” 漢字まじり
- xml:lang=“ja-Kana” カタカナ
- xml:lang=“ja-Hira” ひらかな
<Title TitleType="DisplayTitle" LanguageAndScriptCode="ja-Jpan">
<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-JP と ja-Kana-JP
で漢字名とヨミガナ名を表すとの例示があります >>276。
あくまで例示ではあるものの、仕様書にはっきりと明記されてしまっているので、
一般の解説記事もそれに従って紹介していて >>290, >>288, >>289
何の疑問も挟まれていません。
実装仕様がウェブ公開されているもの >>102
以外にも各所で使われてしまっていると考えるべきでしょう。
[80] Hani は漢字を表します。漢字名と説明されており >>102, >>276、
その説明を忠実にあらわす符号ではあるのですが、
実際には漢字だけとは限らず仮名やラテン文字が含まれることもあり得ると考えられ、
Jpan
がより適切とも思われます。
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-JPexpresses 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 asfamily_name#ja-Hani-JP. As another example, bothwebsiteandwebsite#deClaim Values might be returned, referencing a Web site in an unspecified language and a Web site in German.
given_name#ja-Kana-JP カナ名 profile ユーザーが登録している名のヨミガナを返却します。最大100文字の可変長です。
given_name#ja-Hani-JP 漢字名 profile ユーザーが登録している名の漢字を返却します。最大100文字の可変長です。
- ja, ja-Latn, ja-Kana, ja-Hira, ja-Hrkt は使うかもしれない
- ja-Jpan は RFC 5646 の SHOULD 規定により使わない、ということになる
- ja-Hani を使うこともないと思う。いわゆる Han-Unification 的な扱いになるので、かえって混乱を起こす可能性もあるし。また、漢字のみということをわざわざ示す必要があるユースケースはないのではないか。ja-Hani と書きたくなった場合には、ja とすれば OK である場合が多いと想像する
- ja-Kana がカタカナだというのがトリッキー
[225]
>>224 3. は誤解。漢字統合と Hani は無関係。
[226]
用途がないというのはその通りで、万葉仮名など特殊な事例以外で
ja-Hani の出番はなさそう。
[306] >>305 は ja-Jpan とともに ja-Hani を例示しています。
意図はよくわかりません。
複数の言語/スクリプトの組み合わせの名前 (たとえば日本語の [漢字 + ひらがな + カタカナ、xml:lang="ja-Jpan"] および漢字 [xml:lang="ja-Hani"]);
Thus, for example, the following are among the expected values of
@xml:langfor Japanese, incorporating both a language (“ja”) and a script type:
xml:lang="ja-Hira"(Japanese written in Hiragana)xml:lang="ja-Hrkt"(Japanese written in Hiragana + Katakana)xml:lang="ja-Jpan"(Japanese written in Han + Hiragana + Katakana)xml:lang="ja-Hani"(Japanese written in Kanji (Hanzi, Hanja, Han))xml:lang="ja-Kana"(Japanese written in Katakana)
[308] >>307 これは機械的に全組み合わせを例示していて、確かに値の説明にはなっていますが、 いつ何のためにこれらを使うべきなのかは何も説明されておらずわかりません。
[296]
平成22年度の日本政府の総務省の事業であるメタデータ情報基盤構築事業のまとめた指針は、
RDF
において特性の値の言語タグを ja-Kanji (原表記)
と ja-Kana (読み、実例ではひらがな)
で区別する方法を推奨していました。
>>295
[297]
メタデータ情報基盤構築事業はその他に、
本来表記と読みが区別される場合において、
仮名の読みとローマ字の読みを区別するため
ja-Kana (実例では片仮名)
と
ja-Latn
を使う方法を示していました。
>>295
[300] ここで ja-Latn を使っているということは、
4文字の用字系部分タグの標準化を認識した上で書かれているはずですが、
片仮名を表す Kana で平仮名と片仮名の両方を認めていたり、
4文字の用字系部分タグではない Kanji で「じゃない方」を表していたり、
微妙に独自路線を行っているのが不思議です。
[294]
RDF
において
ja-Hani (原表記)
と
ja-Kana (片仮名)
による区別を例示した解説もあります。 >>293
>>296 とよく似た内容であり深い関係性が窺われます。
[282]
日本の国立国会図書館が運営するジャパンサーチは
ja-Kana を使っています >>280, >>284 が、
なぜかその意味を
言語タグ
ja-Kanaは、カタカナだけでなくひらがなを含めた読みのために用いる。
と定めています >>281。これは明確な誤用です。しかもこの書き方から、
Kana が片仮名だとわかっていて敢えて使っているように読めますが、
その意図は説明されておらず不明です。
[283] 不明ではあるのですが、 >>296 から >>294 を経て >>282 に至ったとすれば話が綺麗に繋がります。 話は繋がるものの、「なぜ」はやっぱり不明です。
立花祭ホームページの 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-Hira や ja-Kana
のような言語タグは読み仮名用の識別子に使われることが多いですが、
「読み仮名」という言葉が持つ「本来の表記は漢字仮名混じりであるところ、
発音を明確にするため仮名表記でも併記する」というニュアンスは言語タグ自体には表れていないことには注意が必要です。
そのようなニュアンスが必要だとすると、言語タグではなくそれを利用する文脈
(プロトコルやデータ形式やそれらを活用する応用) の側で定める必要があります。
[377]
ja-Latn で「読み仮名に相当するローマ字表記」を表すこと、
ja や ja-Jpan で「じゃない方」を表すことも同様です。
[233]
例えば日本語 (ja) と英語と仏語と・・・のデータを併記できる多言語文字列対データがあったとして、
そこに ja-Hira のデータを追加したとしても、
日本語や英語や仏語と並列の別の言語のデータと解釈されるのが自然で、
ja と ja-Hira が対になっていてセットで使われるデータと解釈されるためには特別の規定と処理が必要になります。
[368] RDFリテラルの言語タグを使って読み仮名やローマ字と「じゃない方」 を区別する方法を採るには、RDFデータモデルのレベルでは何の規定もありませんから、 語彙の意味なり、処理モデルなりに於いて明示的に定める必要があります。
[369] 例えば
の2つの文があるとき、 この2文はRDFデータモデルのレベルではまったく無関係です。
など、いろいろな解釈の可能性があります。
[376] そのいずれであるかを確定させたければ、 P の定義においていずれであるかを明確にするなり、 いずれであるかを定めるための別の文を付け足すなりしなければなりません。
[234]
読み仮名だけでなく「平仮名のみの文章」や「片仮名のみの文章」も
ja-Hira や ja-Kana で表される対象であることにはやはり注意が必要です。
具体的には、
のようなものがあります。 設計者はこうしたものと読み仮名の共存が必要かどうか、可能かどうかを考慮しなければなりません。
[367]
ja-Latn で「読み仮名に相当するローマ字表記」を表すことにも、
同じことが言えます。
「読み仮名に相当するローマ字表記」以外の日本語ローマ字文は例えば
があります。これらにもやはり ja-Latn が使えます。
[359]
また、読み仮名として使う場合もそれ以外として使う場合も、
Hira,
Kana,
Hrkt
を指定したからといって、厳密に平仮名や片仮名のみでなければならないわけではないことには注意が必要です。
[360]
例えば、「「住所の読み仮名 (ja-Hira)」欄
で欧州数字を仮名に開かずそのまま含めること」
「漢数字が混じった仮名文書を ja-Hira で表すこと」
「慣習により漢字に置換した仮名異体字を ja-Kana の文章に含めること」
「・, -, 、などの記号を含めること」
には問題がないと考えられます。
[361] 勿論言語タグを使う応用仕様や実装の個別具体の規定により、 こうしたものを認める、認めない、と決めることはできます。 しかしそれは言語タグそれ自体から導かれる規定ではなく、 応用独自の規定が必要となります。
[362] なお、全角カナと半角カナの違い、 濁点の文字合成に関する記述の違い、 標準仮名と変体仮名などは、 文字コードに関する技術的な差異に過ぎず、 言語タグ/用字系符号とは独立した問題です。
[378] なおこうした言語タグによる区別の方法で表現できるのは、 いわゆる読み仮名のうち、欄単位で区別されるべきものだけであることにも、 注意が必要です。
[379]
読み仮名には他にも語単位で記述するもの、文字単位で記述するものがあります。
ruby 要素のような細やかな記述ができる機構が必要となります。
[279] >>278 これは言語タグによる区別でいいのではないかとの問いに対し、 読み仮名であることを別に表す方が便利との回答。
[354] 昭和時代の国語改革の前後の表記法の違いを表したいという需要があります。
[74] 平成時代中期頃、正字正仮名文の言語タグの提案がいくつかありました。 実用例は見当たりません。
[69] ねこめしにっき(2001年4月中旬), , http://www.remus.dti.ne.jp/~a-satomi/nikki/2001/04b.html#d11n03
野嵜さんのテキストの引用部分へ
lang="正字正假名-ja"を指定する事にして事無きを得てもよいですか。(笑)
そこで、現代かなづかいを"ja"、正字正かなを"valid-ja"、ついでに(謎)かなづかいを"nazo-ja"、ってな感じで追加するというのは……駄目ですか……?
"valid-ja"では駄目ではないですか。
よって正字正かなは"ja-nippon"、(謎)かなづかいは"ja-nazo"にしなくてはいけましぇんね。この方法で行くと各地の方言もカバーできそう……。"ja-ibaraki"とか"ja-ohsaka"とか。
[37]
正字正假名の日本語を
ja-trad
と表す提案がありました。
>>53
[353] 平成時代終わりから令和時代初期にかけても新旧表記法の識別子の提案はちらほらあります。
[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とかになるのかな。
[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
を使うことがあります。
[56]
また、
日本関係の
u-nu
の値として、
jpan,
jpanfin,
jpanyear
があります。
数字表記の方法を明示したいときに言語タグに組み入れて使うことができます。
[165]
>>164
は
ja-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] というか >>164 は Unicode Consortium の登録簿か何かから「抜粋」して
iso8601 ISO-8601 Calendar ↑↑↑ ISO-8601
と書いているのですけど、この「抜粋」する前の記述はどこなんですかねえ。 大事なところが省かれてるじゃないですか。
[172] ということで探したらありました。登録簿 >>171 ではなく表示用の文字列データ >>170 では「ISO-8601」「ISO-8601 Calendar」のようになっていて、 >>164 はそれを拾っていたのですね。 変な定義した Unicode Consortium と不正確なラベルを付ける Unicode Consortium が一番悪く、 定義でないところを参照した >>164 がその次に悪い。
[199] 言語タグの拡張Tを使うとどのような変形を経て得られたものかを記述できます。
[200]
拡張Tの仕様等で次のような利用例が示されています。
ja-t-de-m0-und-x0-medical :
日本語であって、独語からの機械翻訳で、
(私用タグ利用:) 医学用語辞書を使ったもの。ja-t-it : 日本語であって、イタリア語から変換したものja-Kana-t-it : 日本語のカタカナ表記であって、
イタリア語から変換したもの[204] 「変換」は広い意味で使うことができるので、外来語やローマ字をはじめいろいろなものの記述に適用できそうです。
[391]
Englishから機械的に翻訳された日本語を表すため
ja-x-mtfrom-en
が使われる事例があります。
[390]
音声から機械的に生成された文字データを表すため
ja-x-autogen
が使われる事例があります。
[255] >>254 は絵文字のフォント選択の制御のために拡張Uを使う例を示しています。
[256] 説明のための人工的な例で、実用的ではありません。
mul-kambun (言語タグ)[92]
mul-kambunは、
(日本の) 漢文用の言語札です。
[94]
漢文は中国語 (ただし現代中国語ではなく、古典中国語)
としての性質と日本語としての性質を併せ持っていますから、
mulと札付けするのが適当だと考えます。
[95]
白文、訓読文、書き下し文のいずれにもmul-kambunを使えます。
これらを区別する必要がある場合のlanguage tagも必要かもしれませんが、どういう名前が良いか検討が必要です。
和様漢文を区別する必要があるかも検討が必要です。
[96] 朝鮮語等の、日本語以外における中国語は対象外としています。
[364]
でも表示その他の応用を考えると、 ja- から始まる言語タグに改めた方がいいかもしれないですねえ。
大陸由来のものも含め、日本で扱われる漢文は日本語表記の1つといっていい
(
ja-2ch (言語タグ)[97]
ja-2ch
は2ちゃんねる語を表す言語タグです。
[98] 平成時代中期に独立して方々で考案され使われました。
[134]
当時は ja-2ch は仕様上も正当な言語タグでした。その後 IETF言語タグの仕様書が改定され、
一般で使われている言語タグの実情を調査することもなしに非互換変更してしまったので、
現在のIETF言語タグの仕様では規格違反になってしまいます。
[135] 利用者はこの問題を深刻に捉える必要はありません。 非互換変更は完全に IETF のミスです。 2ちゃんねる語は 2ch の衰退でほぼ死語で、 今後この言語タグが今まで以上に普及するとは考えにくいので、 今更理論上だけの仕様適合性にこだわるより、従来の記述方法との連続性の方が重要です。
同様の遊びとして、
<q cite="http://pc.2ch.net/..." lang="ja-2ch">ハゲ銅!ahooのせいでみかかが株をあげたと思われ。</q>
なんてこともできます。
xml:lang="ja-2ch"
とすれば2ch語。
この日記スレなら2ch語ベースで書かれているので記述するとしたらja-2chか。
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja-2ch">
[49]
ja-JP-mac や
ja-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
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-Hira は IETF言語タグだとすると、
「平仮名表記の日本語」
を意味しています。
[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 が永続的に保存してくれているからというだけの話なので、 ほんとにたまたま残ったものが少しだけあったということです。
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
ja-2ch に札付けするのが(・∀・)イイ!!)ja-desumasu+Japn-ja-old-kana にして下さると嬉しう存じます。)ja-JP-TKY-shibuya-slang 渋谷の女子高生の言葉ja-JP-TKY-shibuya-slang-2002 とするとか。ja-trad: >>37ja-2ch-2001-08 とか表せて(・∀・)イイ![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] 引用/翻刻ポリシーや包摂規準的なものも記述したいことある。 「片仮名を平仮名になおして引用」とか「新字新仮名とした」とか「青空文庫基準」とか。
[351] 教育ローマ字 (>>315) や一般に用いられる仮名のアクセント表記含め、音声寄りの表記法各種 (>>350) も言語タグで記述できると嬉しいですね。