ここでは，HTMLの国際化に影響を与える二つの重要な課題を規定する。つまり, 言語(lang属性)及び文書中のテキストの方向(dir属性)を指定する。
lang属性によって指定される言語情報は, 様々な方法でレンダリングを制御するために，利用者エージェントによって使用されてもよい。 文書作成者が提供する言語情報が有効であり得るいくつかの状況を次に示す。
lang属性は, 要素の内容及び属性値の言語を指定する。その言語が与えられた属性に関して意味があるかどうかは，属性及び関連する操作の構文及びセマンティクスに依存する。
lang属性は，利用者エージェントが，与えられた言語に対する認められた文化的習慣に基づいて，内容を意味深くレンダリングできることを意図している。これは，特定の言語について例外的な文字を, 利用者エージェントが意味のない方法でレンダリングするのがよいということを意味するのではない。利用者エージェントは, langによって指定される値にかかわらず， すべての文字をレンダリングするために, 最善を尽くさなければならない。
英語のテキストの途中にギリシャアルファベットの文字が現われる例を 次に示す。
<P><Q lang="en">Her super-powers were the result of γ-radiation,</Q> he explained.</P>
利用者エージェントは，
関連する情報については, 表示不可能な文字を参照のこと。
lang属性の値は，話され, 書かれ, 又は人々の情報通信のためにその他の方法で使われる自然言語を識別する言語コードとする。コンピュータ言語は, 言語コードからは明示的に除外される。
[RFC1766]は, HTML文書で使用しなければならない言語コードを定義し解説する。
簡潔にいえば，言語コードは, 主コード及び空でもよい一連の副コードから 構成される。
language-code = primary-code ( "-" subcode )*
言語コードのいくつかの例を次に示す。
2文字の主コードは [ISO639]言語 短縮形として確保されている。 2文字コードには, fr(フランス語), de(ドイツ語), it(イタリア語), nl(オランダ語), el(ギリシャ語), es(スペイン語), pt(ポルトガル語), ar(アラビア語), he(ヘブライ語), ru(ロシア語), zh(中国語), ja(日本語), hi(ヒンズー語), ur(ウルドゥ語), 及び sa(サンスクリット語)がある。
2文字の副コードはすべて, [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 値とを比較することによって)レンダリングを調整する場合，まずコードが完全一致するものを採用することが望ましいが，十分な効果を得るためには，主コードだけが一致するものも考慮したほうがよい。そのため，"en-US"というlang属性値がHTML要素に設定される場合，利用者エージェントは最初に"en-US"に一致するスタイル情報を使用し, 次により一般的な値である"en"に一致するスタイル情報を使用することが望ましい。
注. 言語コード階層は，共通の接頭辞をもつ言語すべてが，そのうちの一つは又は複数の言語を理解する人によって理解されることを保証しない。 言語コード階層のお陰で，利用者は，利用者が理解できる場合には，この共通性を要求することができる。
属性定義
文書作成者は文書の言語をlang 属性で指定するほかに， 文書のテキスト又は表構造などの一部の 基本方向性 (左から右又は右から左) を指定する必要があるかもし れない。 これには dir 属性を用いる。
[UNICODE] 規定は，方向性を文字に割り当てていると共に， テキストの適切な方向性を決定する(複合)アルゴリズムを定義している。 文書が表示可能な右から左文字を含まない場合，適合利用者エージェントは [UNICODE] 双方向性アルゴリズムの適用を要求されない。文書が右から左文字を含み, かつ 利用者エージェントがこれらの文字を表示する場合，利用者エージェントは双方向性 アルゴリズムを使用しなければならない。
Unicode規定はテキスト方向を処理する特別な文字を指定するが，HTMLは dir 属性( DIR 要素と混同しないこと)及び BDO要素など，より高いレベルのマーク付け構成要素を提供し て，Unicodeと同様の役割を果たす。そのため， ヘブライ語の引用を行なう場合は, 次のように書いた方が,
<Q lang="he" dir="rtl">...a Hebrew quotation...</Q>
次のUnicode基準による等価な記述よりも直感的である。
‫״...a Hebrew quotation...״‬
利用者エージェントは，テキスト方向性の決定に lang 属性を使用してはならない。
dir 属性は継承され，上書きされる場合もある。詳細については， テキスト方向情報の継承を参照のこと。
双方向性アルゴリズムの望ましい振る舞いを記述した例を次に示す。この例は，英語であって左から右へのスクリプト，及びヘブライ語であって右から左へのスクリプト，を含むものとする。
次のテキスト例を考えてみる。
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
この例及び関連するすべての例の文字は，ここで表示されているように， ファイルの最初の文字が "e", 2番目の文字が "n", 最後の文字が "6"としてコンピュータに格納されている。
この段落を含む文書の主な言語は英語であると仮定する。これは，この例の場合は最初の仮定によって，基本方向が左から右であることを意味する。この行の正確な表示を次に示す。
english1 2WERBEH english3 4WERBEH english5 6WERBEH
<------ <------ <------
H H H
------------------------------------------------->
E
点線は文の構造を示す。即ち，英語が主流であり，ヘブライ語のテキストが 埋め込まれている。ヘブライ語の素片が，双方向性アルゴリズムを適用する 利用者エージェントにより正確に逆転されているため，正確なプレゼンテーションを 実現する上で付加的なマーク付けを必要としない。
一方で，文書の主たる言語がヘブライ語である場合は，基本方向は右から左である。 その結果として示される正確なプレゼンテーションを次に示す。
6WERBEH english5 4WERBEH english3 2WERBEH english1
-------> -------> ------->
E E E
<-------------------------------------------------
H
この場合，全文は右から左として表示されており，埋め込まれた英語文は 双方向アルゴリズムによって，適正に逆転されている。
Unicode双方向性アルゴリズムはテキストブロックに対する基本テキスト方向 を必要とする。ブロックレベル要素の基本方向を指定するためには， 要素の 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] 双方向性アルゴリズムは，前例で記述しているように本来の方向性に従って, 自動的に 埋込み文字列を逆転する。 しかし，一般に説明できるのは1レベルの埋込みにすぎない。埋込み方向変更の 付加的レベルを実現するために，行内要素で， dir 属性を使用しなければならない。
次に，前と同じテキスト例を考慮する。
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
この段落を含む文書の主な言語が英語であると仮定する。 さらに，上記の英語文は，HEBREW2からHEBREW4に至るヘブライ語セクションを 含み，ヘブライ語セクションは英語の引用(english3)を含む。テキストの望ましい プレゼンテーションを次に示す。
english1 4WERBEH english3 2WERBEH english5 6WERBEH
------->
E
<-----------------------
H
------------------------------------------------->
E
二つの埋込み方向変更を実現するために，第二の埋込みの区切りを明示的に定める付加情報の提供が必要である。 この例では， SPAN 要素及び dir 属性を使用して，テキストのマーク付けが行われている。
english1 <SPAN dir="RTL">HEBREW2 english3 HEBREW4</SPAN> english5 HEBREW6
文書作成者は，同様に，特別なUnicode文字を使用して多重埋込み方向変更を実現してもよい。左から右への埋込みを実現するためには，その埋込みテキストを, LEFT-TO-RIGHT EMBEDDING文字 ("LRE", 16進数 202A) と POP-DIRECTIONAKL FORMATTING文字 ("PDF", 16進数 202C)とで囲む。 右から左への埋込みを実現するためには，その埋込みテキストを, RIGHT-TO-LEFT EMBEDDING文字("RTE",16進数 202B)とPDF文字とで囲む。
Unicode文字を用いたHTML方向性マーク付けの使用。 文書作成ソフトウェアの文書作成者及び設計者は，dir属性をBDOをはじめとする行内要素で使用し，その際に類似する[UNICODE]フォーマット化文字を同時に用いた場合，矛盾が生じうることに注意することが望ましい。なるべくいずれか一方だけを使用するほうがよい。マーク付けの方法は，文書構造の全体性をより十分に保証し，簡単なテキストエディタで双方向性のHTMLテキストを編集する場合に発生する問題を軽減する。しかし， [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要素に電子メール抜粋を置き(行区切りを保存するため)， BDO 要素に各行を配置することにより，双方向性アルゴリズムを 上書きすることである。その場合の dir属性はLTRに設定する。
<PRE> <BDO dir="LTR">english1 2WERBEH english3</BDO> <BDO dir="LTR">4WERBEH english5 6WERBEH</BDO> </PRE>
これは，双方向性アルゴリズムに"左から右のままで!"と命じており， 次の望ましいプレゼンテーションを実現する。
english1 2WERBEH english3 4WERBEH english5 6WERBEH
BDO 要素は，多言語からなるパート番号など，文字列の順序を完全に制御する必要がある場合のシナリオでは使用することが望ましい。この要素についてはdir属性は必須である。
文書作成者はまた, 特別なUnicode文字, LEFT-TO-RIGHT OVERRIDE (202D) 又は RIGHT-TO-LEFT OVERRIDE(16進 202E) を使用して，双方向性アルゴリズムを上書きしてもよい。 POP DIRECTIONAL FORMATTING (16進 202C)文字はどちらの双方向性上書きも終了させる。
双方向性及び文字符号化 [RFC1555] 及び [RFC1556]に従って，MIMEメールで双方向性処理を指定 するために，特に視覚的方向性，暗黙的方向性，明示的方向性の区別をするために， "charset"パラメタ値の使用に関して特別な規約が存在する。 パラメタ値 "ISO-8859-8"はヘブライ語対応であり，視覚的符号化を意味する。 "ISO-8859-8-i" は暗黙的双方向性を意味し，"ISO-8859-8-e" は明示的方向性を 意味する。
HTMLはUnicode双方向性アルゴリズムを使用するため，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に似ているため，1年の最後の5を表す"HEH"との混同を避ける ことを目的として， "HEH"の語頭形が使用される。しかし，結合文字など， "HEH" が結合できる文脈が続かない。 zwj 文字はその文脈 を提供する。
同様に，ペルシャ語のテキストでは，筆記体の文脈で通常連続文字を結合する 文字がそうならないほうがよい場合が存在する。文字zwnjは，そういった場合に結合を防ぐめに使用される。
lrm 及び rlmなど, その他の文字は，方向的に中立である文字の方向性を強制するために使用される。 例えば，二重引用符がアラビア文字(右左)及びラテン文字(左右)の間で生じる場合， 引用符の方向は明らかではない。つまり，アラビア語のテキストの引用なのか， ラテン語のテキストの引用なのかわからないのである。 lrm 及び rlm 文字には方向的特性はあるが， 幅特性及び単語/行区切り特性はない。詳細については， [UNICODE]を参照のこと。
鏡像化文字グリフ 一般に，双方向性アルゴリズムは文字グリフを鏡像化せずに影響を及ぼさない ままにしておく。例外は，括弧などの文字である ( [UNICODE], 表4-7参照)。 鏡像化が望ましい場合としては，例えば古代エジプトの象形文字(ヒエログリフ)，古代ギリシャの 犂耕体書式又は 特別な設計影響のある文字が挙げられる。これはスタイルで制御することが望ましい。
一般に，ブロックレベルから行内又はその逆に要素の視覚的レンダリング を変更するためには，スタイルシートの使用が直接的である。しかし，双方向性 アルゴリズムが 行内及びブロックのレベル区分に依存する ため, 変換には特に注意しなければならない。
dir 属性のない行内要素がスタイルシートにより ブロックレベル要素のスタイルに変換される場合，最も近い親ブロック要素から dir 属性を継承し，ブロックの基本方向を定義する。
dir 属性のないブロック要素がスタイルシートによって 行内要素のスタイルに変換される場合，その結果である表示は， 双方向性フォーマット化に関しては， 継承された値を割り当てられたdir属性に，変換された 要素を付加することによって獲得されたフォーマットと同等となることが望ましい。