Прискорююча кнопка n назначена для пропусків при навігації по сторінкам. Пропуск для переходу на початок контента.

Даний документ є перекладом. У випадку будь-яких невідповідностей і помилок остання версія документу англійською мовою повинна розглядатися як офіційна. Першопочаткове авторське право належить W3C, як це вказано нижче.

Перекладач: Alexandr Shlapak

s_gotoW3cHome Інтернаціоналізація
 

Розуміння Нових Language Тегів

Аудиторія: користувачі, шифрувальники XHTML/HTML (використовуючи редактори або скрипти), розробники скриптів (PHP, JSP, і т.д.), шифрувальники CSS, розробники схем (DTDs, XML Schema, RelaxNG, і т.д.), розробники XSLT, менеджери Веб проектів, і кожен хто, ймовірно, використовуватиме language теги.

Редакційна примітка: Ця стаття містить інформацію з точки зору історичної перспективи, оскільки запропонований новий підхід, вона посилається на опубліковані RFC 4646 і RFC 4647 (разом відомі як BCP 47) в Вересні 2006. Останню актуальну інформацію про те, як побудувати language теги можна знайти у статті Language теги в HTML та XML.

Так як починають з'являтися нові language теги та програмне забезпечення основані на RFC 3066bis, співредактор RFC3066bis Addison Phillips разом із Mark Davis, розглянули як новий стандарт змінює language теги, і що ще залишилось зробити.

Вступ

Language теги - ідентифікатори, що використовуються в протоколах і форматах документа, щоб вказати, природну мова контенту, або, щоб виразити певну мову або набір мов, яким користувач надає перевагу. Language теги можуть використовуватися комп'ютерною системою для застосовування конкретної обробки або форматування тексту з урахуванням мовних інтересів. Наприклад, language тег можна використати для надання допомоги у виборі шрифту за замовчуванням або для вибору словника для програми перевірки орфографії.

Також language теги можуть використовуватися для визначення аудиторії для документу або в механізмі language negotiation (узгодження мови) для вибору контента який буде відображатися. Додатки, що основані на Мережі часто використовують language теги для виводу локалі, якій користувач надає перевагу (впливають на числовий формат або формат дати наприклад, на Веб сайті).

Стандарт для language тегів в Інтернеті, який включає Веб технології, електронну пошту, заголовки протоколу, HTML, XML, IMAP, LDAP, RDF, RSS, і попурі з інших скорочень, називається "BCP 47".

В Листопаді 2005 року IETF (Спеціальна Комісія Інтернет Розробок), що є основою стандарту, який визначає ці теги, затвердила ряд документів для поновлення BCP 47, внесла зміни до структури language тегів і їх використання. Ніколи не чули про BCP 47? Можливо, ви чули про RFC 1766 (що був основою BCP 47) або його наступник, RFC 3066, який ще був BCP 47 до цього минулого Листопада. Це були документи, які визначають використання кодів ISO 639 і ISO 3166 для формування таких language тегів "fr", "en-US", "de-CH", або "ja", так як реєстр для інших, більш спеціалізованих, тегів.

BCP позначає Найкращу Теперішню Практику. RFC позначає Запити для Коментарів. RFCs є стабільними і офіційними специфікаціями IETF , перенесеним на минулому етапі Інтернет Проектом.

Огляд нового підходу

RFC 3066bis накладає додаткові обмеження на формат language тега, тобто, language теги не можуть так широко змінюватися у RFC 3066bis так, як вони могли це робити в попереднику. Оскільки тільки декілька тегів, були насправді зареєстровані, то це не накладає новий тягар на користувачів або програмне забезпечення. Будь-який тег, який був дійсний у RFC 3066 як і раніше дійсний у RFC 3066bis тезі. Це, як правило, правильний тег, так як, користувачі на сьогоднішній день, зазвичай, не захочуть вибрати інший тег замість вчорашнього RFC 3066 тега.

Будь-яка реалізація, що може обробляти зареєстровані RFC 3066 теги повинні бути в змозі обробляти теги, що згенеровані RFC 3066bis, оскільки всі нові теги були дійсні для реєстрації в RFC 3066. Насправді, більш ніж наполовину реєстр складається з тегів, які очікують додавання скриптових subtags, які використовували структуру RFC 3066bis до того часу, як прийняли нові правила.

Language теги досі складаються з послідовності "subtags", які розділені дефісами. Subtag може містити від одного до восьми символів і обмежений літерами ASCII та номерами (тобто, a-z, A-Z, та 0-9). Великі і малі літери не розрізняються, тому тег "EN" рахується тим самим, що й "en" або "eN".

RFC 3066bis визначає кожний тип subtag відповідно до його позиції та розміру в тезі. Повний синтаксис для цих тегів показано тут:

Language-Tag складається з:
                   langtag                ; згенерований тег
              -or- private-use            ; тег приватного використання
              -or- grandfathered          ; схвалені реєстрації

langtag       = (language
                 ["-" script]
                 ["-" region]
                 *("-" variant)
                 *("-" extension)
                 ["-" privateuse])

language      = "en", "ale", або зареєстроване значення

script        = "Latn", "Cyrl", "Hant" ISO 15924 коди

region        = "US", "CS", "FR" ISO 3166 коди
                "419", "019",  або UN M.49 коди

variant       = "rozaj", "nedis", "1996", multiple subtags можуть використовуватися в тезі

extension     = одна буква за якою слідують додаткові subtags; більше одного розширення
                можуть використовуватися в language тезі

private-use   = "x-" за яким слідують додаткові subtags, стільки скільки потрібно
                Зверніть увагу, що вони можуть розташовуватися на початку тега або з'являтися в кінці (але не
                в середині)

grandfathered = теги перераховані в старому реєстрі, які не є redundant (надлишковими) (закритий список)

Як зазначалося вище, будь-який допустимий RFC 3066 language тег справедливий і за новою схемою. Більшість тегів в даний час складаються з послідовності subtags використовуючи генеративний синтаксис.

Деякими винятками є "grandfathered" (схвалені) теги: це теги зареєстровані в RFC 3066 , які не вписуються в синтаксис (або застаріли до їх прийняття). Будь-який існуючий контент або програмне забезпечення, таким чином, продовжують використовувати ці теги. Їх є 34, з яких вісім є застарілими і десять стануть застарілими у найближчому майбутньому. Чотири схвалені теги підходять для RFC 3066bis зразка, але вони спочатку не були зроблені надлишковими.

Велика відмінність від RFC 3066bis в тому, що за винятком декількох схвалених реєстрацій, всі теги тепер генеративні. Так як списки ISO кодів не завжди були вільними й тому, що вони змінюються з часом, ключовою ідеєю було створити постійний, стабільний реєстр всіх subtags доступних в language тезі. Це означає, що замість п'яти окремих списків кодів, є лише одна таблиця, яка містить значення, розташовані в одному місці. IANA Language Subtag Реєстр як і раніше стежить за стандартами ISO, за винятком того, що subtags ніколи не відкликалися і є чіткі правила, що мають справу з суперечливими завданнями, якщо вони виникають.

Кожен тип subtag має унікальну довжину і обмеження контенту. Тег завжди починається із language subtag - або одного із ISO 639 кодів або зареєстрованого значення. Потім, за бажанням, за ним можуть слідувати різні subtags. Нині є п'ять видів subtags які слідують за ідентифікатором мови: скриптові, регіональні, варіантні, розширення, і приватного використання. Порядок, довжина і контент кожного типу subtag фіксована, так теговий процесор може завжди точно визначати який він має тип subtag, навіть якщо процесор не має того subtag в його копії реєстра (або взагалі не має копії реєстра!)

Script (Скриптовий).Скриптові subtags нам вже зустрічалися. Вони основані на ISO 15924 і вказують писемність. Скриптовий subtag може зустрічатися не частіше одного разу (його можна пропустити) і повинен з'явитися відразу після language. Деякі мови мають поле в реєстрі, яке вказує, що особливий скриптовий код потрібно "suppressed" (заборонити). Наприклад, "zh-Hant" і "zh-Hans" відображає Китайську письмову мову відповідно на Традиційному та Спрощеному скриптах, в той час як language subtag "en" в реєстрі має поле "Suppress-Script" (Заборонити Скрипт) вказує що більшість Англійських текстів написані на Латинському скрипті, пригнічуючи такий тег, як "en-Latn-US".

Region (Регіональний). Регіональні subtags ми також зустрічали: вони основані переважно на коді ISO 3166-1 і вказують державні або регіональні відмінності. Регіональний код може також включати вибрані UN M.49 регіональні коди. UN M.49 коди охоплюють великі території землі або забезпечують, щоб конфліктні рішення ISO 3166 перепризначали код вже в реєстрі. Насправді, ISO 3166 залежить від UN M.49 щоб визначити, що є чи не є "країною" або регіоном відповідно до коду. Регіональний код може зустрічатися не більше одного разу (його можна пропустити) і він має слідувати за будь-якими мовними і скриптовими кодами. Наприклад, тег "es-419" представляє "Іспанську, яка використовується в Латинській Америці та Карибах" в той час як "es-CO" представляє "Іспанську, яка використовується в Колумбії".

Variants (Варіантні). Варіантні subtags не основані на зовнішньому стандарті. Вони всі є індивідуально зареєстрованими значеннями, головним чином вказує особливі діалекти або інші варіанти мови, на які не поширюються скрипти або регіони. Multiple variant (багатоваріантні) subtags можуть включатися в тег. Кожен варіант має поля в реєстрі хоча й вказує, які subtags призначені для використання. Наприклад, "nedis" subtag має префікс "sl" (Словенська) оскільки він відображає діалект Словенської мови. Варіантні не повинні використовуватися разом, якщо тільки один з варіантів містить інший в своєму "prefix" (префіксі). Наприклад, тег "sl-IT-nedis" визначає Nadiza - діалект Словенської, яка використовується в Італії.

Extensions (Розширення). Розширення - механізм, за допомогою якого можуть бути стандартизовані майбутні доповнення до language тегів. Кожне розширення має односимвольний subtag ("singleton" (одинак)), що його визначає. Різні обмеження приміняють до розширень, і як вони формуються, використовуються, і управляються. Розширення формують основу для майбутнього додавання функцій до language тегів.

Private use (Приватного використання). Subtags приватного використання взагалі не основані на будь-якому стандарті. Вони призначені для використання окремими особами або групами, які мають розпізнавати щось, що стосується мови, і що не може піднятися до рівня стандартизації. RFC 3066 включав теги приватного використання, але і весь тег був приватного використання (звичайно, це як і раніше справедливо). Зараз генеративні subtags і subtags приватного використання можуть використовуватися разом. Однолітерний subtag "x" визначає, де починаються subtags приватного використання. Наприклад: en-US-x-twain може визначити твір написаний Марком Твеном серед робіт двох колег, які вивчають Американську літературу. Однією з переваг цієї можливості змішувати два subtags є те, що постачальники, які поширюють language теги з власних причин у майбутньому можуть так зробити і, при цьому збережуть максимальну взаємодію між їх системою та іншими системами.

Новий синтаксис тега використовує довжину і контент, щоб розрізняти кожен тип subtag, роблячи легшим ніж будь-коли перевірку контенту тега, навіть без копію реєстру. У наступній таблиці наведено кілька прикладів нових тегів:

Тег Форма Значення
en language Англійська
de-AT language-region Німецька, що використовується в Австрії
es-419 language-region (UN M.49) Іспанська, яка використовується в Центральній і Південній Америці
de-CH-1901 language-region-variant Німецька, що використовується в Швейцарії, орфографія 1901
sr-Cyrl language-script Сербська, яка написана на Кирилиці
sr-Cyrl-CS language-script-region Сербська, яка написана на Кирилиці, що використовується в Сербії і Чорногорії
sl-Latn-IT-rozaj language-script-region-variant Словенська, яка написана на Латині, що використовується в Італії, Резьянський діалект

Велика суперечка скриптів

Критичною точкою дебатів в ході розробки нових language тегів було розміщення скриптового subtag після language subtag, але перед регіональним subtag. Ніщо в RFC 1766 або RFC 3066 не гарантує те, що регіональний subtag з'явитися на другій позиції і, раніше в 2003, коли з'явилися перші спроби, не існувало жодного зареєстрованого тега, що дозволив би уточнити, чи було це правомірно припустити, що регіональний код, якщо б він існував, завжди з'являвся другим (було абсолютно ясно, що інше значення, таке як скрипт, може з'явитися другим).

Деякі люди вважають, що розміщення скриптів на другій позиції приносить деякі проблеми. Зокрема, дехто побоювався, що скриптовий subtag заважатиме звичайному вибору мови або механізмам узгодження мови. Ці механізми, такі ж, як описані в RFC 2616 (HTTP 1.1) використовувати префікс, що називається "language range" (мовний діапазон) який зазначений користувачем для того, щоб вибрати контент.

Ця форма узгодження припускає, що переваги користувача "відповідає" частині контента, якщо language тег користувача є префіксом для цього контенту. Цей механізм відбору грунтується на припущенні, що мови, які поділяють префікс, як правило, "взаємно зрозумілі". (Зауважимо, що це припущення часто є помилковим.) Ось кілька прикладів узгодження префікса:

Мовний Діапазон ... підходить ... не підходить
de de, de-CH, de-AT, de-DE, de-1901, de-AT-1901 en, fr-CH
de-CH de-CH, de-CH-1901, de-CH-1996 de, de-DE, de-1901, de-AT, etc.
zh-TW zh-TW zh-Hant-TW, zh-Hans-TW
zh-Hant zh-Hant, zh-Hant-TW, zh-Hant-HK zh, zh-Hans, zh-TW

Вставка скриптового subtag між language і регіональним може мати негативний вплив на існуючі запити користувача або на контент, що не використовує скриптовий subtag. Замість очікуваної відповідності, користувач може не отримати контент або отримати менш точні відповідності. Це показано вище в останньому прикладі.

З іншого боку, скрипт, як правило, більш тісно пов'язаний з мовою, ніж регіональні варіації. Зазначення префікса виробляє більш розумні результати, коли скриптовий subtag розташований до language subtag ближче ніж регіональний. Для того щоб працювати, користувачі які потребують скриптові subtags повинні використовувати (або скасувати) їх послідовним чином, як в їхніх запитах так і в контенті.

Іншою проблемою була двозначність RFC 3066 щодо генеративного синтаксису. Ідею "language-dash-region" (мова-тире-регіон) language тегів було досить легко зрозуміти; Більшість користувачів безпосередньо не читали RFC 3066 або розглянули невстановлений але реалізований висновок, що інші subtags іноді можуть зустрічатися на другій позиції.

Зрештою було вирішено, що тісні відносини між скриптом і мовою зробили другу позицію кращим вибором, ніж штучно помістивши його в останню чергу. Це рішення частково керувалося усвідомленням того, що інший тип subtag може знадобитися в майбутньому (який ми отримаємо пізніше).

На додаток до самих subtags, новий subtag реєстр містить інформацію, щоб допомогти користувачам вибрати найкращу комбінацію, щоб визначати звичайну мову. Вирішальним для прийняття позиції скриптового subtag стало включення інформації до реєстру, щоб ясно дати зрозуміти необхідність уникати скриптових subtags за винятком випадків, коли вони додають корисну для розпізнання інформацію. Таким чином, запис у реєстрі для language subtag "en" (Англійська) має поле, яке називається "Suppress-Script" (Заборонити Скрипт) вказує те, що скриптового subtag "Latn" слід уникати з тією мовою, так як практично всі Англійські документи використовують Латинський скрипт.

Зазначимо, що це не означає, що "en-Latn" теги ніколи не використовуватимуться. Є випадки, коли скрипт надаватиме інформацію, яка розрізняє контент. Наприклад, в документі, який містить як Латинський скрипт так і шрифт Брайля, можливо, необхідно розрізняти дві форми. Однак це виняткові випадки і виключення в тих випадках буде розумним (і навіть очевидним).

У кожному разі, практично для будь-якого контенту що сьогодні не використовує скриптовий subtag, буде краще не використовувати його і в майбутньому. Мови які не використовують більш ніж один скрипт або зазнають переходу скрипта - наприклад, перераховані вище - можуть і повинні отримати вигоду з визначення контента використовуючи скриптові subtags. Трохи більше року з його реєстрації, швидкий пошук в пошуковій системі показує більше 8000 сторінок на Спрощеній Китайській зазначаючи тільки тег "zh-Hans". Генеративний синтаксис багато в чому допоможе при використанні та прийнятті скриптових subtags для мов, що їх потребують.

IANA Language Subtag Реєстр

Новий IANA Language Subtag Реєстр містить інформацію про кожен subtag який дійсний для використання в language тезі. Реєстр - текстовий файл в спеціальному форматі, який читають машини, що називається "record-jar". Кожен subtag має свій власний запис, складається з декількох рядків тексту, які визначають subtags, їх використання, і деяку корисну при виборі інформацію, які subtags правильні для конкретних обставин.

Ось деякі приклади деяких записів "language" subtag:

   %%
   Type: language
   Subtag: cs
   Description: Czech
   Added: 2005-10-16
   Suppress-Script: Latn
   %%
   Type: language
   Subtag: cu
   Description: Church Slavic
   Description: Old Slavonic
   Description: Church Slavonic
   Description: Old Bulgarian
   Description: Old Church Slavonic
   Added: 2005-10-16
   %%
   Type: language
   Subtag: cv
   Description: Chuvash
   Added: 2005-10-16
   %%

Кожен запис містить сам subtag, його тип (в цьому випадку "language"), описання (або набір описань), і дату, коли запис додали до реєстру. Як показано вище: всі початкові записи мають дату "2005-10-16".

Іноді доступна додаткова інформація. Наприклад, вище, в записі для Чеської мови (cs) ви помітите, так зване поле "Suppress-Script" (Заборонити Скрипт). Це поле вказує, що більшість текстів на Чеській написані на Латинському скрипті і те, що скриптовий код "Latn" не підходить для більшості language тегів, які визначають контент на Чеській мові. Тобто, тег подібний до "cs-CZ" рекомендується, в той час як такий тег, як "cs-Latn-CZ" настійно не рекомендується.

Інші поля, що можуть з'явитися включають поле "Deprecated" (застарілий), яке показує дату, коли конкретний код застарів. Воно майже завжди з'являється з іншим полем, так званим "Preferred-Value" (значення, яким віддають перевагу), що вказує більш відповідний subtag для використання для того значення. Наприклад, код "TP" застарів після появи ISO 3166, коли в 2002 та країна змінила свою адміністрацію та назву:

   %%
   Type: region
   Subtag: TP
   Description: East Timor
   Added: 2005-10-16
   Preferred-Value: TL
   Deprecated: 2002-11-15
   %%

Реєстраційний процес може досі використовуватися, щоб додати інформацію або оновити інформацію про специфічні записи, так само, як додавати повністю нові subtags. Записи не можна видалити і є правила, щоб запобігти "mutated" (мутації) значень subtag в щось зовсім інше.

Сам файл містить запис "File-Date", що показує коли востаннє був оновлений реєстр. У поєднанні з різними полями дати в самих записах, можливо перевірити будь-який конкретний тег або його subtags для будь-якої заданої дати, в минулому або нині.

Сучасний стан та робота, що ще залишилася

Сучасний стан

RFC 3066bis насправді складається з трьох частин. Перша - документ який описує синтаксис language тегів і реєстр, так само, як підтримуються language теги і т.д. Цей документ є Інтернет Проектом, який називається "draft-ietf-ltru-registry-14" і містить близько 62 сторінок. Тоді є початковий контент IANA Language Subtag Реєстра, який, міститься в Інтернет Проекті , що називається "draft-ietf-ltru-initial-05". Цей документ був відредагований та підтримується Doug Ewell.

IANA Language Subtag Реєстр в даний час запущений і працює, і навіть отримував реєстрації.

Остання частина головоломки - Інтернет Проект про відповідність language тегів. Цей документ працював на той час, коли це було написано і його нинішня назва - "draft-ietf-ltru-matching-12".

IETF веб сайти розміщають всі ці документи, або ви можете знайти всі їх останні версії перераховані на моєму персональному веб сайті і на сайті W3C.

Узгодження

Зіставлення, як зазначалося раніше, досить добре зрозуміле в його самій простій формі - "prefix matching" (узгодження префікса), яка описана вище в розділі про скрипти. Однак, є деякі інтригуючі, застосування для RFC 3066bis тегів стилю для узгодження, так само, як деяких відомих схем узгодження, які не були добре задокументовані в RFC 3066. На момент написання, ця робота очікує завершення процесу Останнього Виклику.

ISO 639-3 і Макро Мови

Незважаючи на зміни в тому, як формуються і підтримуються language теги залишаються деякі випадки на які, в свою чергу, новий дизайн ссилається не в повній мірі.

Помітною проблемою є виявлення варіацій мови або варіацій в межах родини мов. Поки варіантні або регіональні subtags часто використовуються для цієї мети, доти деякі мови будуть довго жити: стабільні, добре описані зміни, які не особливо добре описуються національними кордонами. На додаток, ISO 639 має випадково призначені коди для "macro-languages" (макро мов), які є мовними сімействами, що містять ряд впізнавано пов'язаних (але не обов'язково взаємно зрозумілих) мов.

Прекрасним прикладом є ще раз Китайська. ISO 639-1 код 'zh' визначає "Китайську", але концепція Китайської охоплює ряд різних мов або діалектів, що поділяють деякі риси. Хоча ці мови написані дуже схоже (виготовлення таких тегів, як "zh-Hant" та "zh-Hans" є корисним), розмовний контент дійсно сильно відрізняється. І, знову, доступні регіональні опції є поганими дорученнями для розмовних діалектів (багато з яких обмежені материковим Китаєм).

RFC 3066bis забезпечує частину рішення цієї головоломки, зарезервувавши місце для ще одного виду спеціалізованого subtag, так званий "extended language subtag" (розширений). Це трилітерні коди які слідують за primary (основним) language subtag, але зустрічаються перед скриптовим subtag. Є дуже чіткі правила для того, коли може використовуватися один із цих subtags (вони мають використовуватися тільки із зазначеним prefix (префіксом)), і очікується, що дуже маленька переробка в RFC 3066bis буде проходити в mid-2006, щоб зробити їх доступними.

Можна було б запитати: "Якщо вимоги до цих кодів існують вже зараз, і ми їх знаємо, то чому б ці коди не включити в RFC 3066bis?" Причина затримки в тому, що основою для визначення розширених language subtags, як очікується, буде ISO 639-3. Подібно як ISO 639-2 є підмножиною ISO 639-1, ISO 639-3 визначає ще більший набір мовних кодів, спочатку основаних на кодах в SIL Ethnologue (SIL, насправді, є "Реєстраційним Органом" в ISO 639-3, тобто, люди, які будуть підтримувати список кодів у майбутньому). ISO 639-3 також визначає, які мови закриті якими Макро Мовами. Таким чином Мандаринська мова (розмовний варіант) буде визначена ISO 639-3 кодом 'cmn' і правила вимагатимуть той код, коли він використовується як subtag, щоб завжди з'являтися зі своєю макромовою "zh" (Китайська). Це, нарешті, зробить можливим відмітити Китайський контент точно у всіх вимірах:

Тег Значення
zh-cmn Мандаринська мова
zh-cmn-Hant Мандаринська мова, яка написана на Традиційному скрипті
zh-cmn-Hans Мандаринська мова, Спрощений скрипт
zh-cmn-Hant-HK Мандаринська мова, Традиційний скрипт, що використовується в Гонконзі SAR (Особливому адміністративному районі)
zh-cmn-Hans-CN Мандаринська мова, Спрощений скрипт, що використовується в Китаї
zh-gan Ган Китайська
zh-hak Хакка Китайська
zh-yue Юе Китайська (Кантонська)
zh-hsn Сян Китайська
zh-yue-Hant-HK Кантонська, Традиційний скрипт, Гонконгський SAR (Особливий адміністративний район)

Є близько сорока різних мов, відмінних від Китайської, які визначені як Макро Мови в прототипі ISO 639-3. Більшість з них є мовами меншин і не виключено, що здатність точно визначити ці мовні зміни в контенті може вплинути на їх зберігання серед існуючих мов.

У кожному разі, розширені language subtags вже повністю визначені і просто чекають на ISO 639-3 щоб, нарешті, стати офіційними і завершеними до включення в список language subtags. Зверніть увагу, що виконавцям просто необхідно оновити свою копію реєстру, коли доданий ISO 639-3, до тих пір, поки вони дотримуються виконання вимог уже в RFC 3066bis.

Висновок

Нова версія BCP 47 дає можливість точно позначити або зробити запит контента використовуючи стабільні, чітко визначені теги. Ці теги спрямовують ряд давніх проблем із визначенням мови, і ми сподіваємося що доводять їх до розширених функцій в нашому програмному забезпеченні, що відносяться до мови і поліпшують підтримку мови в наших документах. Розуміння цих тегів і їх формату допоможе користувачам прийняти їх і використовувати їх розумно і послідовно.

Розкажіть нам про те, що Ви думаєте.

Підписатися на RSS джерело.

Нові джерела

Новини головної сторінки

Twitter (Новини головної сторінки)

‎@webi18n

Додаткові матеріали

Автор: Addison P. Phillips, Yahoo! Inc.. Перекладач: Alexandr Shlapak.

Допустимий XHTML 1.0!
Допустимий CSS!
Кодування UTF-8!

Переклад Англійського контенту від 2006-05-15. Переклад останнього оновлення 2011-07-31 12:00 GMT

Для перегляду історії внесення змін до перекладу натисність article-bcp47 в блоге i18n.