Робота з MediaWiki - Глава 15 - Адміністрація MediaWiki

1. Налаштування конфігурації
2. Налагодження
3. Покращення продуктивності MediaWiki
4. Кеш MediaWiki
5. Черга завдань
6. Адміністративні посилання
7. Замінити текст
8. Отримання інформації IP користувача
9. Роботи та API MediaWiki
10. API MediaWiki
11. Пошукова оптимізація
12. Запуск ферми вікі
13. Багатомовні вікі

Адміністрування вікі MediaWiki, як правило, не так складно, як тільки ви зробили початкове налаштування. Вона включає в себе як дії через веб-інтерфейс, так і дії, виконані на зворотному кінці, наприклад, редагування LocalSettings.php і встановлення розширень. Зазвичай є лише одна або декілька людей з доступом до заднього кінця, і така ж або дещо більша група людей з адміністративним доступом на самій вікі.

Вся ця книга в значній мірі орієнтована на адміністраторів MediaWiki, тому в певному сенсі більшість цієї книги може підходити під тему "адміністрування MediaWiki". Але ця глава призначена для того, щоб утримувати деякі інструменти та дії, які стосуються лише адміністраторів, які не вписуються в інші місця.

Налаштування конфігурації

Існує багато налаштувань для основних MediaWiki, які можна змінити в LocalSettings.php - по суті, всі змінні, які починаються з "$ wg". Деякі з них висвітлені в цій книзі, хоча це дуже невеликий відсоток від загальної кількості. Повний перелік можна переглянути тут, згрупований за типом функціональності:

https://www.mediawiki.org/wiki/Manual:Configuration_settings

Ось корисний, який не згадується в іншому місці книги:

• $ wgReadOnly - встановлює всю вікі як тільки для читання, вказану в якості причини; корисно для тимчасового обслуговування сайту

Налагодження

MediaWiki - це програмне забезпечення, а програмне забезпечення, на жаль, може піти не так. Якщо ви зіткнетеся з проблемою, це може бути дозвіл каталогів файлів, права доступу до бази даних, відсутні файли, відсутні таблиці таблиць, погані параметри в LocalSettings.php, несумісні версії або навіть (помирають) помилки в коді. (Що, до речі, набагато частіше трапляється в розширеннях, ніж у основних MediaWiki.)

Взагалі, джерело найбільшої плутанини в MediaWiki приходить, коли користувачі бачать порожню сторінку в браузері в будь-який момент, коли перебуваєте у вікі. Це відбувається, якщо виникла помилка, і якщо PHP налаштовано відображати порожню сторінку, а не повідомлення про помилку, коли це станеться. Майже завжди краще бачити помилку на екрані; тому, якщо ви отримаєте порожню сторінку, найкращим рішенням є додати наступний рядок, або до LocalSettings.php або до власного php.ini файлу PHP: ini_set ('display_errors', 1);

Якщо це додано до LocalSettings.php, воно повинно бути у верхній частині файлу, прямо під рядком "<? Php".

Найпростішим інструментом для будь-якого виду налагодження є панель інструментів налагодження MediaWiki. Він розміщує всю необхідну інформацію (виклики SQL, попередження, дисплеї налагодження) в одному легко доступному місці внизу браузера. Для тих з нас, які звикли домогтися відлагодження MediaWiki старим способом, це надзвичайно корисний інструмент. Ви можете ввімкнути його, додавши наступне до LocalSettings.php:

$ wgDebugToolbar = true;

Проте, можливо, вам не хочеться, щоб усі панелі інструментів налагодження відображалися під час увімкнення (якщо ви ввімкнете цю функцію, кожен зможе його побачити). На щастя, є й інші варіанти. Якщо ви бачите повідомлення про помилку, яке містить текст "(SQL query hidden)", і ви хочете побачити виклик SQL, ви можете побачити його, додавши наступне до LocalSettings.php:

$ wgShowSQLErrors = true; І якщо помилка, що відбувається, здається складною, ви можете увімкнути власну реєстрацію налагодження MediaWiki, а потім перевірити вміст цього файлу. Щоб увімкнути його, додайте до LocalSettings.php: $ wgDebugLogFile = "/ full / path / to / your / debug / log / file";

Цей файл має бути доступним для запису веб-сервером.

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

Покращення продуктивності MediaWiki

Це не книга веб-ефективності, але якщо ви вважаєте, що ваша вікі занадто повільна, або ви турбуєтесь про результати збільшення трафіку в майбутньому, ось кілька корисних порад:

• Переконайтеся, що ваш веб-сервер і PHP мають достатньо пам'яті.
• Існує безліч інструментів кешування, які можна використовувати в поєднанні з MediaWiki (і один з одним), наприклад Squid, Varnish і memcached. З усіх доступних інструментів, найкориснішим є, напевно, APC, утиліта кешування PHP, яка часто різко покращує продуктивність MediaWiki. Тут можна переглянути всі параметри кешування:

• Використання Nginx або Lighttpd як веб-сервера, а не Apache, може значно підвищити продуктивність для сайтів з високим рівнем трафіку.
• MediaWiki також може працювати з віртуальною машиною HipHop, або HHVM, відкритим вихідним кодом для PHP, розробленим Facebook. Вікіпедія почала використовувати HHVM у грудні 2014 року, і вона приблизно подвоїла швидкість сайту, як для перегляду, так і для редагування.

Кеш MediaWiki

MediaWiki робить велике кешування сторінок: коли ви переходите на вікі-сторінку, є ймовірність, що вона не була створена на місці, а скоріше це кешована версія, яка була створена коли-небудь у попередній день або близько того. (Це не стосується сторінок у просторі імен "Спеціальні", які генеруються заново кожного разу.)

Користувачі завжди можуть бачити "живу" версію будь-якої сторінки, додавши до дії URL-адресу "дія = очищення".

Розширення MagicNoCache дозволяє позначити деякі сторінки як ніколи не кешовані, за допомогою перемикача поведінки "__NOCACHE__". Див. Тут:

https://www.mediawiki.org/wiki/Extension:MagicNoCache

Кешування стає проблемою, коли інстальовано Cargo або Semantic MediaWiki, оскільки сторінки, які кешуються, не автоматично показують останній набір результатів запиту; це може викликати плутанину у користувачів, якщо вони додають деякі дані, а потім не з'являються в результатах запиту в іншому місці. Найкраще вирішення цієї проблеми - встановити розширення MagicNoCache, використовуючи його на кожній сторінці, яка містить запит.

Інший варіант - використовувати розширення "Затверджені оновлення" ( див. тут ) - хоча це не є навмисним, сторінки, які мають затверджену версію, не кешуються. Це може змінитися в майбутньому, але на даний момент це побічний ефект, про який треба знати. Вантажі та SMW забезпечують власну вкладку / випадаюче меню, яке бачать лише адміністратори, або "Purge cache" (Cargo) або "Refresh" (або SMW); обидва пункти вказують на URL-адресу "дія = очищення", що забороняє адміністраторам вводити його вручну.

Черга завдань

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

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

Роботи виконуються кожного разу, коли вікі отримують хіт сторінки. За замовчуванням одне завдання виконується при кожному натисканні, але цей номер може бути змінений, щоб зробити виконання завдань більш повільним або швидшим, змінивши значення $ wgJobRunRate. Щоб зробити роботу завдань у десять разів швидше, наприклад, ви повинні додати наступне до LocalSettings.php:

$ wgJobRunRate = 10;

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

Ви також можете запускати завдання у більш автоматизованому режимі, а не просто чекати, поки їх буде запущено (або натиснути кнопку "перезавантажити" у браузері повторно, щоб прискорити роботу). Це робиться викликом скрипту runJobs.php у каталозі MediaWiki / maintenance. Ви навіть можете створити завдання cron для запуску runJobs.php на регулярній основі - скажімо, один раз на день.

Існують різні параметри, які можуть виконувати runJobs.php, такі як встановлення максимальної кількості виконуваних завдань або, що може бути, більш важливо, тип завдання, яке потрібно виконати. Щоб увімкнути останнє, кожен тип завдання має своє ім'я ідентифікатора, який можна знайти в базі даних. Тут ви можете прочитати про всі параметри для runJobs.php:

https://www.mediawiki.org/wiki/Manual:RunJobs.php

На додаток до основних MediaWiki, розширення також можуть створювати свої власні завдання. Деякі розширення є передачею даних, DeleteBatch, Nuke і Replace Text.

Адміністративні посилання

Однією з поширених функцій у веб-додатках, яким MediaWiki завжди бракує, є область "інформаційної панелі", яка дозволяє адміністраторам переглядати статистику та виконувати адміністративні завдання з одного місця. У певній мірі сторінка Special: SpecialPages робить це вже; він просто перераховує більшість наявних спеціальних сторінок, згрупованих за категоріями. Це, безумовно, краще, ніж нічого, але не всі сторінки, перераховані в Special: спеціальні сторінки спеціально корисні для адміністраторів, і навпаки, не всі адміністративні завдання виконуються через спеціальні сторінки (редагування бічної панелі, наприклад, не є).

Розширення Admin Links надає щось ближче до реальної адміністративної інформаційної панелі. Вона визначає одну сторінку, Спеціальна: AdminLinks, яка містить посилання, корисні для адміністраторів, розділені за типом функціональності. Інші розширення можуть додавати свої власні посилання на сторінку посилань адміністратора, якщо вони захочуть, за допомогою крюків і кількох. На малюнку 15.1 показано, як виглядає сторінка, коли встановлені різноманітні розширення, описані в цій книзі, такі як Cargo, Page Forms і Data Transfer.

Малюнок 15.1 Сторінки посилань адміністратора, коли встановлено інші розширення (Затверджені версії, Заміна тексту, форми сторінок, вантажу тощо)

Інша приємна особливість посилань адміністратора полягає в тому, що вона надає посилання на сторінку "Адміністративні посилання" в межах посилань користувача у верхній частині кожної сторінки, так що панель завжди знаходиться на відстані одного кліка. Ось як виглядає верхня частина сторінки на шкірі «Вектор», з встановленими посиланнями адміністратора:

Замінити текст

MediaWiki не має вродженого способу виконувати глобальний пошук і заміну тексту. У Вікіпедії та деяких інших великих вікі, боти використовуються для цієї мети, але мати спосіб зробити це з вікі набагато зручніше. На щастя, розширення Replace Text дає змогу виконувати заміну тексту в масштабі всього сайту. Замінити текст може обробляти як вміст сторінок, так і їх імена; якщо зміст назви сторінки замінено, це означає, що сторінка "переміщується".

Щоб запустити заміну, перейдіть у розділ Спеціальні: ReplaceText. Ця дія регулюється дозволом 'replacetext', який за замовчуванням надається адміністраторам.

Рисунок 15.2 На початок сторінки: ReplaceText

Ви можете побачити вершину сторінки Special: ReplaceText на малюнку 15.2. Нижче наведено список просторів імен, з яких користувач може вибрати; потім нижче наведені деякі додаткові опції для заміни, які показані на малюнку 15.3.

Рисунок 15.3 Нижній розділ: ReplaceText

Якщо натиснути кнопку "Продовжити", користувач перейде на другу сторінку, вказавши точну відповідність рядку пошуку, щоб користувач міг вибрати вручну, які сторінки будуть змінюватись і / або змінювати назви.

Кожна зміна, зроблена за допомогою заміни тексту, відображається в історіях сторінок, при цьому користувач, який ініціював заміну, з'явився як автор цього редагування.

Для більш складних перетворень, ймовірно, вам доведеться покладатися на роботів і API MediaWiki, до яких ми потрапимо.

Отримання інформації IP користувача

У рідкісних випадках може бути корисно отримати інформацію про IP-адресу користувачів, які ввійшли в систему - наприклад, якщо пароль користувача вкрадений, а хтось інший починає редагувати вікі як їх; або якщо ви підозрюєте, що один користувач вандалізує вікі з декількох облікових записів; або, якщо ви підозрюєте, що один користувач створює кілька облікових записів, щоб спробувати дати ілюзію широкого консенсусу з певної проблеми (це відомо як "sockpuppeting"). IP-адреса фактично зберігається для кожної зміни, яка відбувається у вікі, хоча вона не видно ніде у вікі. Якщо ви маєте доступ до бази даних, ви можете переглянути цю інформацію в стовпці "rc_ip" таблиці "recentchanges". Розширення CheckUser дозволяє адміністраторам переглядати цю інформацію з самої вікі, щоб полегшити доступ: https://www.mediawiki.org/wiki/Extension:CheckUser

І навпаки, якщо ви не хочете зберігати цю інформацію з міркувань конфіденційності, можна вимкнути пам’ять, додавши в LocalSettings.php наступне:

$ wgPutIPinRC = false;

Роботи та API MediaWiki

Існують різні інструменти для автоматизованих змін у вмісті вікі, наприклад розширення Замінити текст. Але в багатьох випадках необхідний набір редагувань занадто специфічний для автоматичного інструменту. Для всіх цих випадків є роботи та API MediaWiki.

Бот, в термінології MediaWiki, - це сценарій, який виконує одне або декілька специфічних видів редагувань або витягує один або більше фрагментів даних. Бот може бути написаний на будь-якій мові програмування: він просто повинен з'єднатися з MediaWiki API, який робить фактичну роботу над записом і читанням даних. Більшість основних мов програмування мають одну або декілька бібліотек MediaWiki API, написані для них, які піклуються про деталі входу до вікі та підключення до API. Але навіть без бібліотеки створити MediaWiki бот не так вже й складно - скрипт просто повинен вразити деякі URL MediaWiki.

Якщо бот вносить будь-які зміни у вікі, він ідеально повинен бути зареєстрований як користувач - і в ідеалі, що користувач повинен бути окремим обліковим записом, який додається до групи "ботів". Ви можете бачити ці типи облікових записів по всій Вікіпедії - це ті, які фіксують розбиті теги <ref>, перейменування категорій, додавання підписів до повідомлень непідписаних ток-сторінок тощо. але деякі дрібні вікі роблять їх значним.

На цій сторінці міститься деяка інформація та корисні посилання щодо створення та запуску ботів:

API MediaWiki

API MediaWiki по суті є набором URL-адрес, до яких можна отримати доступ, щоб читати вікі та писати їх. Всі вони включають різні параметри, передані у файл api.php. Цей файл знаходиться в тому ж каталозі, що й index.php; наприклад, якщо у вашій вікі є URL-адреси форми mywiki.com/w/index.php?title = ..., головну URL-адресу API можна знайти на сторінці mywiki.com/w/api.php. (Для більш нових версій MediaWiki API пов'язаний з сторінки Спеціальна: версія.)

Якщо ви перейдете до цієї основної URL-адреси, ви побачите досить вичерпне (автоматично створене) пояснення всіх доступних дій API. Дії API визначаються як основними MediaWiki, так і рядом розширень. Ви також побачите список різних форматів, у яких можна відображати результати, включаючи JSON і XML. Наприклад, додавання "format = jsonfm" до URL-адреси покаже результати у форматі псевдо-JSON, який користувачі можуть читати на екрані, тоді як "format = json" призведе до фактичного сировинного JSON.

Ми не будемо вникати в подробиці всіх функцій API, доступних тут, але ви можете побачити їх на api.php - і ви також можете дізнатися більше про це за адресою:

https://www.mediawiki.org/wiki/API:Main_page

Пошукова оптимізація

Пошукова оптимізація, або SEO, це практика спроби отримати сторінки свого веб-сайту, щоб показати як можна вище в пошуковій системі результатів, особливо на Google. Це суперечливе поле: для його прихильників, це незамінний спосіб отримати веб-трафік, в той час як для його недоброзичливців, це в кращому випадку клейкий, і в гіршому випадку доменів, спамерів і шахраїв. Тим не менш, для людей, які керують громадськими вікі, важливим є високий показник результатів пошуку.

Перш за все, MediaWiki вже добре налаштований для досягнення успіху в результатах пошуку різними способами. Вікіпедія, яка, звичайно, базується на MediaWiki, є сайтом з найвищою ефективністю для результатів пошуку, за будь-яким показником: зазвичай у першій трійці, і часто в # 1, для пошуку по будь-якій темі. Здебільшого це пов'язано з тим, що він часто пов'язується з іншими сайтами про ці конкретні теми, але також частково через власний дизайн MediaWiki.

У MediaWiki темою кожної сторінки є також назва сторінки, частина її URL-адреси, текст у заголовку верхнього рівня, а також текст, який відображається у внутрішніх посиланнях на цю сторінку. Такий тип узгодженості є надзвичайно важливим для пошукових систем, пов'язаних з цим словом або фразою з певною URL-адресою. Прив'язавшись до цього, зазвичай на одній сторінці є лише один заголовок верхнього рівня: ім'я сторінки міститься лише в тезі <h1> на сторінці, що є ще однією річчю, яка допомагає встановити тему сторінки для пошукових систем.

Існує принаймні одне активне розширення MediaWiki, яке потенційно може допомогти з пошуковим рейтингом: розширення WikiSEO, яке додає до тегів вихідний код HTML сторінки вікі. Він визначає функцію парсера, відповідним чином названу "#seo", яка може бути додана в будь-якому місці сторінки, і яка викликається наступним чином: {{#seo: title = ... | titlemode = ... | ключові слова = ... | description = ...}}

Параметр "title =" або замінює, додається або додає вміст тега <title> HTML, залежно від значення параметра "titlemode =", який може бути або замінити, або додати або додати. Параметри "keywords =" і "description =" розміщуються як атрибути "name" і "content" відповідно тега HTML <meta>. Якщо ви не знаєте, як найкраще налаштувати всі ці теги, це гарна ідея шукати їх значення, і як вони повинні бути найкраще використані для SEO.

Ви можете знайти більше інформації про WikiSEO тут: \ t

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

Запуск ферми вікі

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

Звичайно, кожна група, яка хотіла б мати власну вікі, могла б просто створити одну з них; якщо всі вони використовують MediaWiki, установка безкоштовна і в цілому не надто складна. (Це, власне, і те, як вікі історично вводилися в організації: невеликі групи, що самі створювали їх, в тому, що відомо як проекти "skunkworks"). Але таке налаштування може швидко стати громіздким: якщо іншій людині потрібно стати вікі-експертом для кожної вікі, яку потрібно створити та підтримувати, то витрачається занадто багато роботи. Навіть якщо всі вікі управляються централізовано однією особою або відділом ІТ, це може стати великою кількістю роботи, коли прийде час оновити програмне забезпечення.

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

https://www.mediawiki.org/wiki/Manual:Wiki_family

На цій сторінці наведено багато підходів: одиночні чи множинні бази коду, одиночні чи декілька баз даних, одиночні чи багаторазові екземпляри LocalSettings.php тощо. Однак ми рекомендуємо лише один підхід: використовувати один кодова база, кілька баз даних і кілька файлів налаштувань. Це, по суті, відповідає підходу "Drupal-style sites", описаному на цій сторінці.

Ми не потрапимо до повних технічних деталей, але основна ідея полягає в наступному: у вас є окрема база даних для кожної вікі, а також окремий файл налаштувань. Кожен файл налаштувань за вікі включений з LocalSettings.php. Файли індивідуальних налаштувань встановлюють назву бази даних для кожної вікі і дозволяють налаштувати параметри вікі, включаючи стандартні функції, такі як назву вікі, логотип, шкіру та дозвіл; на додаток до розширень, які включені лише для деяких вікі.

Посібник "Сімейство вікі" містить просте поєднання PHP і сценарію оболонки для цього підходу, що дозволяє створювати і оновлювати базу даних для кожної вікі.

Також потрібно визначитися зі структурою URL для різних вікі: два стандартні підходи полягають у використанні субдоменів, таких як "wiki1.mycompany.com" або підкаталоги, наприклад "mycompany.com/wiki1". Ця структура повинна оброблятися комбінацією LocalSettings.php (яка повинна визначити, який файл налаштувань використовувати, на основі URL), і конфігурацію сервера, яка, якщо використовується Apache, зазвичай є файлом httpd. conf. Конкретні налаштування для обох висвітлюються в посібнику "Вікі-сім'ї".

Якщо ви знаєте заздалегідь, що у вас буде кілька вікі, може бути корисно мати спільні облікові записи користувачів для всіх, щоб користувачі не повинні створювати новий обліковий запис на кожній вікі, яку вони хочуть редагувати. Вікіпедія робить це складним чином, використовуючи розширення "CentralAuth", але для інших вікі це можна зробити набагато простіше, просто використовуючи різні бази даних для спільного використання однієї таблиці таблиць для інформації користувача. Ви просто повинні вирішити, в якій базі даних буде зберігатися інформація, а потім додайте наступне до LocalSettings.php: $ wgSharedDB = " main-database-name ";

Хоча "спільна БД" звучить як велика справа, за умовчанням спільно використовуються лише таблиці, які мають відношення до інформації користувача.

Багатомовні вікі

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

По-перше, деякі гарні новини: текст самого інтерфейсу - як і текст на вкладках "Редагувати" і "Переглянути історію", або текст на спеціальних сторінках - зазвичай не є проблемою, оскільки, якщо користувач встановлює свою мову під "Користувацькі налаштування", хороші шанси, що весь цей текст був переведений на їхню мову, завдяки першокласній установці перекладу MediaWiki.

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

Існують по суті три підходи. Для того, щоб від найважчих до найменш складних, вони:

Рисунок 15.4 Панель із посиланнями на різні переклади сторінки, надані розширенням Translate

• Машинний переклад змісту. За допомогою такого підходу ви зберігаєте весь контент на одній мові, а потім просто маєте механізм перекладу вмісту через службу перекладу. Розширення Live Translate є рекомендованим підходом для цього: він забезпечує простий у використанні інтерфейс, деякі корисні додаткові функції, а також дозволяє використовувати служби перекладу Google і Microsoft. Це найпростіший підхід до кількох мов. Про це читайте тут: