内容
このセクションで、HTMLの国際化に関わる二つの重要な問題に言及します：言語の特定（ lang属性）と文書内テキストの方向（ dir属性）
属性定義
lang属性で設定された 言語情報は、ブラウザなどの表示代行手段によって様々な方法で再現表示されます。自動的に提供される言語情報が、助けてくれる状況もあります：
lang属性は、要素内容や属性値の言語を特定します：これが、或る既存の属性にとって 適切であるかどうかは、属性の構文や意味論及び操作に依存します。
lang属性の意図は、或る一定の言語にとって文化的実際的で妥当な使用で意味がある様に、ブラウザなどの表示代行手段が内容を再現表示できると言うことです。ブラウザなどの表示代行手段が、或る特殊な言語にとって非典型的である文字符号を意味のない方法で再現表示すべきだと言うことは含まれません；ブラウザなどの表示代行手段は、 langによって特定された値にかかわらず、 全ての文字符号を再現表示しようと最善の試みをすべきです。
例えば、ギリシャ文字由来の文字符号が英語テキストの中に現われる場合：
<P><Q lang="en">Her super-powers were the result of γ-radiation,</Q> he explained.</P>
ブラウザなどの表示代行手段は、まず（1）適切なやり方で英語の内容を再現表示し（例：引用符の取扱いにしても）、次に（2）英語の文字符号でなかっても、 γを再現表示する最善の試みをしなければなりません。
より詳しい情報は、 undisplayable charactersセクションを参照して下さい。
lang属性の値は、普通に話されている言語であり、書くことやその他人々の間で情報交換として使われているものを指定します。コンピューター言語は、この言語コードから除外されています。
[RFC1766]で、HTML文書で使うべき言語コードを定義説明されています。
簡単に言えば、言語コードはプライマリー・コードと空けておくこともできるサブコード群から構成されています：
language-code = primary-code ( "-" subcode )*
言語コードの幾つかの例です：
二文字コードが、 [ISO639]言語の省略型として予約されています。 fr (French)・de (German)・it(Italian)・nl (Dutch)・el (Greek)・es (Spanish)・pt (Portuguese)・ar(Arabic)・he (Hebrew)・ru (Russian)・zh (Chinese)・ja (Japanese)・hi(Hindi)・ur (Urdu)・sa (Sanskrit)と言った二文字コードがあります。
二文字コードは、どれも [ISO3166]国コードとわかります。
要素は、次の優先順位（高い方から低い方へ）に従って言語情報を継承します：
Content-Language: en-cockney
文書本来の言語はフランス語("fr")です。或るパラグラフがスペイン語("es")と宣言され、スペイン語の後本来の言語であるフランス語に戻ります。日本語("ja")のフレーズが組み込まれたパラグラフに続き、また本来の言語であるフランス語に戻ります。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<HTML lang="fr">
<HEAD>
<TITLE>Un document multilingue</TITLE>
</HEAD>
<BODY>
...Interpreted as French...
<P lang="es">...Interpreted as Spanish...
<P>...Interpreted as French again...
<P>...French text interrupted by<EM lang="ja">some
Japanese</EM>French begins here again...
</BODY>
</HTML>
HTMLの文脈上で、言語コードを一つ一つのトークン（字句）としてではなく階層構造としてブラウザなどの表示代行手段は解釈すべきです。ブラウザなどの表示代行手段は、言語情報に沿って再現表示を調整し（スタイル・シート言語と lang値を比較して）、常に正確な一致を助けるべきですが、本来のコードでも十分であるような一致も考慮しなければなりません。従って、 lang属性の"en-US"と言う値が HTML要素の設定されている場合ブラウザなどの表示代行手段は、まず"en-US"に一致するスタイル情報を選び、それからより一般的な値 "en"をとります。
注意： 言語コード階層が、ありふれた接頭語のある言葉を複数の言葉の中で流暢なものと理解する保証はありません。使い方が正しい場合その普及性を、ブラウザなどの表示代行手段が問い合わせられるようにしておきます。
属性の定義
lang属性で文書言語を設定する以外に、文書の一部やテーブルの構造等の 基本方向（左右乃至右左）を特定したい要求もありえます。これは、 dir属性で果たせます。
[UNICODE]仕様は、文字符号に方向性を指定し、テキストの適切な方向性を決める（複雑な）アルゴリスムを定義します。文書に表示可能な右から左への文字符号がない場合最適なブラウザなどの表示代行手段なら、 [UNICODE]双方向性アルゴリスムを適用する要求をしません。文書に表示可能な右から左への文字符号があってブラウザなどの表示代行手段がこの文字符号を表示する場合ブラウザなどの表示代行手段は双方向性アルゴリスムを使わなければなりません。
Unicodeはテキスト方向性を取り扱う特別な文字符号を特定しますが、HTMLでも同じものをする高度なマーク付け構文を提供します： dir属性（ DIR要素と混同しなように）と BDO要素です。従って、ヘブライ引用符を表現するには、こう書くほうがより直観的です。
<Q lang="he" dir="rtl">...a Hebrew quotation...</Q>
Unicode参照と等価です：
‫״...a Hebrew quotation...״‬
ブラウザなどの表示代行手段は、テキストの方向性を決めるのに lang属性を利用してはいけません。
dir属性は継承され、また上書きもされます。詳しくは、 テキスト方向情報の継承のセクションを参照下さい。
次の例で、双方向性アルゴリスムの期待通りの振る舞い方を示しています。英語は左右でヘブライ語は右左という文が混在しています。
次の例で説明します：
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
この例での文字符号（関連例は全て）は、ここに表示する様なやり方でコンピュータに貯えられています：ファイルの最初の文字符号は"e"で、二番目は "n"そして最後は"6"です。
このパラグラフの在る文書の言語は英語が主体とします。このことは、基本方向が左右と言うことです。この行の正しい表示は：
english1 2WERBEH english3 4WERBEH english5 6WERBEH
<------ <------ <------
H H H
------------------------------------------------->
E
破線で、文の構造を示しています。英語が基本で、ヘブライ語テキストが組み込まれています。正しい表示を達成するには、マーク付けを加える必要はありません、何故ならブラウザなどの表示代行手段はヘブライ語の断章は双方向性アルゴリスムによって正しく保存されるからです。
逆に基本言語がヘブライ語の場合、基本方向は右左です。従って、表示の狙いは：
6WERBEH english5 4WERBEH english3 2WERBEH english1
-------> -------> ------->
E E E
<-------------------------------------------------
H
このケースで、全ての文は右左として表示され、組み込まれた一連の英語は双方向性アルゴリスムに従って適切に保存されます。
ユニコード双方向性アルゴリスムでは、テキスト・ブロックに対しての基本テキスト方向が必要です。ブロック・レベル要素の基本方向を特定するには、 dir属性を設定します。 dir属性の初期値は、"ltr"（左から右です）。
dir属性をブロック・レベル要素のために設定する場合、その要素の支配範囲と入れ子されたブロック・レベル要素に及びます。 dirを入れ子要素に設定すれば、継承されている値に上書きします。
文書全体の基本テキスト方向を設定するには、 HTML要素で dir属性を設定します。
例えば：
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <HTML dir="RTL"> <HEAD> <TITLE>...a right-to-left title...</TITLE> </HEAD> ...right-to-left text... <P dir="ltr">...left-to-right text...</P> <P>...right-to-left text again...</P> </HTML>
他方、インライン要素は dir属性を継承しません。 dir属性がないインライン要素は、双方向アルゴリスムの視点から、組み込みの追加レベルに解放的ではありません（ここで、要素が、初期値の表示に基づいたブロック・レベルであるかインラインかが考慮されます）。 INSとDEL要素は、文脈に沿ってブロック-レベルにもインラインにもなりえます。
[UNICODE]双方向アルゴリスムは、組み込まれた一連の文字符号を継承された方向性に沿って自動的に予約します（前の例のように）。しかし、一般的には組み込みの第一レベルのみをそのように見做します。組み込まれた方向を追加レベルに変更するには、オンライン要素で dir属性を使います。
前と同じ例を考でてみます：
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
このパラグラフの在る文書の基本言語は、英語とします。この英文には、HEBREW2からHEBREW4までの間はヘブライ語に拡張され、そのヘブライ語範囲内に英語の引用（english3）が在ります。このテキストの狙いう表示は：
english1 4WERBEH english3 2WERBEH english5 6WERBEH
------->
E
<-----------------------
H
------------------------------------------------->
E
二つの組み込まれたものの方向を変更するには、情報を追加しなくてはなりません。それには、二度目の組み込みの範囲をはっきりしなくてはなりませn。この例では、 SPAN要素やdir属性でテキストをマーク付けしています。：
english1 <SPAN dir="RTL">HEBREW2 english3 HEBREW4</SPAN> english5 HEBREW6
複数の組み込みテキスト変更をするのに、特殊なユニコード文字符号を使うこともできます。左右組み込みにするには、 LEFT-TO-RIGHT EMBEDDING("LRE", 十六進法 202A) とPOP DIRECTIONAL FORMATTING ("PDF")で組み込まれたテキストを囲います。右左組み込みにするには、 LEFT-TO-RIGHT EMBEDDING("LRE", 十六進法 202B) とPDFで組み込まれたテキストを囲います。
ユニコード文字符号でマーク付けしたHTML方向性を使う。作成ソフトウェアーの制作者やデザイナーは、以下のことに気付いていなければなりません。 dir属性を、オンライン要素に（ BDOも含めて）、対応する [UNICODE]体裁用文字符号と同時に使うと衝突（コンフリクト）が起こる可能性がると言うことです。どちらか一つだけを使うのが好ましいやり方です。このやり方は、文書構造の統合を保証し、シンプルなテキスト・エディターで方向性を編集する際の或種の問題を少なくしますが、ソフトウェアーの中には [UNICODE]文字符号の使用でもいいものもあります。両方の方法を使う場合、適切なマーク付けの入れ子・組み込みの方向性・上書きなどや表示結果を確認しておくのに十分な注意を働かせておかないと表示結果は漠然としたものなります。
<!ELEMENT BDO - - (%inline;)* -- I18N BiDi over-ride --> <!ATTLIST BDO %coreattrs; -- id, class, style, title -- lang %LanguageCode; #IMPLIED -- language code -- dir (ltr|rtl) #REQUIRED -- directionality -- >
開始タグ：必須終了タグ：必須
属性定義
その他の属性
双方向性アルゴリスムと dir属性で、一般的には組み込まれた方向の変更を十分処理できます。しかし、或る状況下では、双方向性アルゴリスムでは正しくない表現をもたらすことがあります。 BDO要素で、テキストの選択された断章の双方向性アルゴリスムを 切り換えことが出来ます。
前述のテキストの在る文書で考えてみましょう：
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
しかし、このテキストは既に視覚的な順序に組み込まれています。その理由の一つは、MIME標準で（ [RFC2045]・ [RFC1556]）視覚的順序が選ばれています、例えば右左文字符号列がバイト並で右左に挿入されています。電子メールで、以下のように上記の様にフォーマットされ、強制改行もあると：
english1 2WERBEH english3 4WERBEH english5 6WERBEH
これは、 [UNICODE]双方向性アルゴリスムと衝突します。何故なら、アルゴリスムは 2WERBEHを、4WERBEHと6WERBEHは二度変換するので、ヘブライ単語は右左ではなく左右に表示します。
この場合での解決には、電子メール部分を PRE要素（強制改行を保持するために）で、各行は dir属性が LTRに設定してある BDO要素で囲みます：
<PRE> <BDO dir="LTR">english1 2WERBEH english3</BDO> <BDO dir="LTR">4WERBEH english5 6WERBEH</BDO> </PRE>
これで双方向性アルゴリスムに、「左右儘にしておいて」と伝え、意図する表示になる様にします：
english1 2WERBEH english3 4WERBEH english5 6WERBEH
BDO要素は、順序に絶対的な制御が必要な(例：多言語部分の詩句）筋書で使われます。 dir属性は、その要素に強制的なものです。
双方向アルゴリスムを上書きするのに特殊なユニコード文字符号も使えます--左右上書き（202D）乃至右左上書き（十六進法 202E）。
双方向性と文字符号コード化 [RFC1555]や[RFC1556]に従うと、MIMEメール上双方向性処理を示唆する"charset"パラメータ値の使用に、殊に視覚的・絶対的・明示的な方向性の区別をするのに、便利です。パラメーター値"ISO-8859-8"（ヘブライ語用）は視覚的コード化を、"ISO-8859-8-i"は絶対的な方向性を、そして "ISO-8859-8-e"は明示的な方向性を拒否します。
HTMLは、ユニコード双方向性アルゴリスムを使用しますので、ISO 8859-8を使ってコード化した適合文書は"ISO-8859-8-i"でラベルしておかなければなりません。明示的な方向性制御もHTMLで可能ですが、ISO 8859-8では表現できませんし、"ISO-8859-8-e"は使うべきではありません。
値"ISO-8859-8"では文書が、双方向性を処理し得ない古いブラウザなどの表示代行手段でも適切な表示を確保するために、或種のマーク付け（右配置や改行なしの TABLEなど）の使い方を変えて視覚的に体裁化します。このような文書は、表示仕様に適合していません。必要なら、現在の仕様書に適合するように、必要な所に BDOマーク付けをして、作成されなければなりません（そして同時に古いブラウザなどの表示代行手段で正しく表示されるでしょう）。 [RFC1555]と[RFC1556]で言われていることとは違って、ISO-8859-6 （アラビア語）は視覚的な順序付けをしません。
ある種の文字符号（例、句読点）では、双方向性に関して時に不都合なことが生じますので、 [UNICODE]仕様書には、これを適正に解決できる文字符号を用意しています。またUnicodeには、必要に応じて結合習性を制御する為に、幾つかの文字符号があります（例、アラビア文字で起こることがあります）。HTML 4.0ではこれらの文字符号のために、 文字符号参照があります。
次はDTDから引用したもので、或種の双方向性実体を示しています：
<!ENTITY zwnj CDATA "‌"--=zero width non-joiner--> <!ENTITY zwj CDATA "‍"--=zero width joiner--> <!ENTITY lrm CDATA "‎"--=left-to-right mark--> <!ENTITY rlm CDATA "‏"--=right-to-left mark-->
zwnj実体は、文脈上結合習性を阻止するのに使い、結合が起った場合そうすべきでない時につかいます。 zwj実体は、その逆で；結合を強制し、結合が起こらない場合結合すべき時に使います。例えば、アラビア文字の"HEH"は、イスラム暦の名前である"Hijri"の省略語としてつかわれます。"HEH"自体は、アラビア書体で使われる数字5（インド数字に由来した）に似ていますので、"HEH"を年号の最後数値5と混同しない様に、"HEH"の大文字（イニシアル）で使われます。しかし、引き継ぐ文脈がな（例、一纏めの文字）く、そこに"HEH"が結合します。 zwj文字符号は、そこに文脈を提供します。
同じ様にペルシャ語テキストで、普通に文字列を結合する文字で結合に切れ目があってはいけないケースがあります。文字符号 zwnjが、この様なケースで結合を阻止するのに使われます。
lrmとrlmは、方向性上中立文字符号の方向性を強制するのに使います。例えばアラビア文字（右左）とラテン文字（左右）間に二重引用符が来る場合、二重引用符号の方向ははっきりしません（アラビア文字を囲うのか、ラテン文字を囲うのか）。 lrmやrlm文字符号が、方向特有性をもっていますが、幅や言葉/行分け（ワード・ラップ 折り返し）はありません。より詳しくは、 [UNICODE]を参照下さい。
鏡像化される象形文字符号 一般的に双方向性アルゴリスムでは、象形文字符号を鏡像化しなくて、その儘にしておきます。例外として、括弧などの文字符号があります（ [UNICODE]、目次4-7、を参照下さい）。鏡像化が必要なケースでは、例えば 古代エジプト象形文字・ 古代ギリシャ犂耕（りこう）体書式・特別なデザイン文字符号の場合これはスタイルで制御すべきです。
スタイル・シートの使用で視覚的な再現表示をブロック-レベルからインラインにまたその逆に変更することは、一般的にはできます。しかし、双方向性アルゴリスムは、 インライン／ブロック-レベルの区別に依存していますので、この変換には特別な注意を払わなければなりません。
dir属性を持たないインライン要素がスタイル・シートでブロック-レベル要素のスタイルに変換される場合、ブロックの基本方向を定義するのに一番近い親ブロック要素から dir属性を継承します。
dir属性を持たないブロック要素がスタイル・シートでインライン要素に変換される場合表示結果は、明示的に加えられた dir属性によって得られる体裁と双方向性体裁と言う専門用語上で等価になります。