Більшість компаній уявляють Wikipedia як одну річ: «ми хочемо сторінку в Wikipedia». Але Wikipedia — не одна енциклопедія, а приблизно 340 окремих, кожна своєю мовою, кожна зі своєю спільнотою волонтерів, власними правилами та власною думкою щодо того, чи заслуговує ваша компанія на статтю. Англійський розділ (language edition) отримує найбільше уваги у西方них корпоративних кабінетах. І саме він найменш імовірно буде прочитаний вашими клієнтами у Сан-Паулу, Ер-Ріяді, Джакарті та Києві.
Це та частина розмови про видимість у штучному інтелекті, яку зазвичай пропускають. Люди нав'язливо зосереджуються на потраплянні до англомовної Knowledge Panel і забувають, що ШІ-асистент, який відповідає на запитання португальською, арабською, індонезійською чи українською, насамперед звертається до джерел цією мовою — а здебільшого це португальська, арабська, індонезійська або українська Wikipedia, жодна з яких про вас не чула.
Ця стаття про те, як правильно робити багатомовну (multilingual) роботу: не «переклади англійську сторінку сорока мовами» — це не працює, — а продуманою стратегією, побудованою на єдиній сутності (entity) Wikidata, тверезому прочитанні незалежних правил кожного розділу та пріоритетному списку мов, що визначається реальним розподілом ринку. Стаття чесна щодо вартості та прямо говорить про типові помилки, бо саме в багатомовній частині цієї роботи найбільше виплеском грошей.
Чому мова має більше значення, ніж більшість команд припускає
Почнімо з того, як велика мовна модель відповідає на запитання. Коли користувач пише іспанською, модель не тихо перекладає на англійську, шукає англійські факти й перекладає назад. Вона спирається на закономірності, яких навчилась із іспаномовних текстів, — а найважче-зважене іспаномовне джерело майже в будь-якому навчальному корпусі — це іспанська Wikipedia. Те саме стосується німецької, японської, арабської, гінді та кожного іншого великого розділу. Кожна Wikipedia є якірним джерелом для тієї мовної частини моделі.
Отже, компанія з сильною статтею в англійській Wikipedia і нічим іншим добре представлена, коли хтось запитує ChatGPT англійською — і фактично невидима, або ще гірше, неправильно представлена, коли хтось задає те саме запитання турецькою. У моделі немає турецькомовного якоря для цієї сутності. Вона або відмовиться відповідати, або придумає щось, або переплутає компанію з однойменною, яка має турецькоюний слід.
Google поводиться так само на рівні сутностей. Knowledge Panel, що показується користувачу у Франції, спирається на французькомовні сигнали; рядок опису часто береться зі вступу французької Wikipedia, а не англійської. Якщо у французькій Wikipedia немає статті, це поле повертається до того, що Google може зібрати сам, — а це нерідко нічого впорядкованого, іноді дані конкурента.
Практичний висновок: видимість у ШІ та пошукових системах — локальна, навіть якщо ваш бренд глобальний. Одна англійська сторінка — це плацдарм, не кампанія. Якщо ваш дохід надходить із дванадцяти країн, ваша репутаційна інфраструктура існує приблизно в одній із них. Розрив між «у нас є сторінка Wikipedia» і «нас правильно описано на кожному ринку, де ми продаємо» — колосальний, і саме цей розрив коштує угод, коли ШІ-асистент потенційного клієнта повертає відповідь «я не зміг знайти надійної інформації про цю компанію».
Як сайтлінки та єдина сутність Wikidata об'єднують бренд
Ось механізм, що перетворює багатомовну роботу на щось зв'язне, а не хаотичне. Кожен мовний розділ Wikipedia має власну статтю про вашу компанію — різний текст, різні редактори, різні списки джерел. Без додаткової структури це сорок роз'єднаних сторінок, про які машини можуть і не здогадатися, що вони описують одну й ту саму сутність. Те, що пов'язує їх разом, — Wikidata (структурована база знань Wikimedia).
Єдиний елемент Wikidata — один QID (унікальний постійний ідентифікатор сутності, незалежний від мови) — перебуває в центрі. Ми детально писали про те, як цей структурований шар працює, у нашому поясненні Wikidata і Knowledge Graph, але багатомовний аспект варто підкреслити окремо: QID однаковий незалежно від того, чи інтерфейс англійський, японський чи арабський. Q42 — це Дуглас Адамс скрізь. QID вашої компанії — це ваша компанія скрізь.
До цього єдиного елемента приєднані сайтлінки (sitelinks) — по одному на кожну статтю в мовному розділі Wikipedia. Сайтлінк — це формальний зв'язок, який каже: «цей елемент Wikidata відповідає цій статті в цьому мовному розділі». Коли ваші німецька, іспанська та японська статті всі посилаються на той самий QID, відбуваються три речі:
- Машини знають, що це одна й та сама сутність. Google і мовні моделі, читаючи будь-яку з цих статей, можуть зіставити її з єдиною ідентичністю та єдиним набором структурованих фактів. Жодного змішування, жодного дублювання.
- Заповнюється міжмовна навігаційна панель. Читачі та пошукові роботи бачать, що стаття існує N мовами, — це видимий сигнал усталеного мультиринкового суб'єкта, а не разової сторінки.
- Структуровані факти залишаються узгодженими між розділами. Дата заснування, штаб-квартира, офіційний сайт, ключові особи, тикер акцій — все це зберігається один раз у елементі Wikidata і живить усі мовні версії. Ви виправляєте факт в одному місці — він правильний скрізь.
Це й є архітектура. Багато мовних статей, одна спільна сутність. Статті несуть текст і мовно-специфічний кейс значущості (notability); елемент Wikidata несе ідентичність і машиночитані факти. Пропустите шар Wikidata — отримаєте купу сторінок, які не знають одна про одну. Побудуєте правильно — отримаєте зв'язну глобальну сутність, яку пошукові системи та моделі ШІ зможуть точно описати будь-якою мовою, якою їх запитають.
Пастка незалежності: кожен розділ встановлює власні правила
А тепер частина, яка дивує майже кожного клієнта, — і найдорожче непорозуміння в багатомовній роботі з Wikipedia: мовні розділи — це незалежні спільноти з незалежними правилами. Не існує центрального органу Wikipedia, який одного разу затвердить статтю й поширить її скрізь. Wikimedia Foundation утримує сервери; редакційними рішеннями вона не керує.
Це означає, що суб'єкт може мати процвітаючу статтю в одному розділі й бути видаленим при першій же появі в іншому. Конкретно:
- Англійська Wikipedia має найбільш розроблені та, мабуть, найсуворіші вимоги до значущості (notability), розгалужений і добре організований апарат видалення. Пройти англійський розділ — це висока планка.
- Німецька Wikipedia відома тим, що вона суворіша за англійську щодо корпоративних статей — спільнота особливо не терпить усього, що читається як рекламне, а «Relevanzkriterien» (критерії відповідності) застосовуються неухильно. Чимало компаній, які проходять в англійській, отримують відмову або видалення в німецькій.
- Розділи середнього розміру надзвичайно різні. Одні відкриті й слабо патрулюються; інші мають жменьку відданих редакторів із сильними думками й довгою пам'яттю.
- Менші розділи можуть бути ліберальніші щодо значущості, але чутливіші до якості перекладу та до статей, що явно прийшли з іншого місця.
Пастка полягає в припущенні, що схвалена англійська стаття — це паспорт. Це не так. Кожен розділ оцінює суб'єкт за власними стандартами значущості, використовуючи власні норми щодо надійних джерел (reliable sources) — а те, що вважається надійним джерелом, різниться залежно від мови й країни. Джерело, яке є золотим стандартом в англомовному світі, може бути невідомим або не довіреним редакторам іншого розділу, які по-іншому зважують свої національні ЗМІ.
Стратегічний висновок прямий: кожна мова — це окреме питання значущості. Не можна представляти багатомовний розгортку як «англійська сторінка помножена на N». Кожен розділ потребує власної оцінки: чи відповідає цей суб'єкт планці цієї спільноти, з джерелами, яким ця спільнота довіряє? Будь-яке агентство, що обіцяє рівномірну публікацію в усіх розділах без поперокційної оцінки, або недосвідчене, або збирається розмістити сторінки, які будуть видалені. (Саме тому ми розглядаємо кожен розділ як окремий проєкт; пакет джерел переходить, оцінка значущості — ні.)
Пріоритизація мов за ринковою цінністю, а не заради статусу
Коли ви приймаєте той факт, що кожен розділ має реальну вартість і реальний ризик, постає питання: які саме? Неправильна відповідь — «якнайбільше» або «ті, що звучать вражаюче». Правильна відповідь визначається тим, де ваш бізнес реально діє — де ви продаєте, наймаєте, залучаєте гроші і де стикаєтеся з репутаційними ризиками.
Корисно думати про це в рівнях (tier), прив'язуючи кожну мову до бізнес-обґрунтування, а не до кількості прапорців:
| Рівень | Мовні розділи (приклади) | Коли це виправдано |
|---|---|---|
| Якір | Англійська | Майже завжди перша. Найбільш цитований розділ, найвища вага в мовних моделях, орієнтир, на який Google спирається глобально. Сторінка, з якої інші розділи позичають джерела. |
| Ключові ринки | Німецька, французька, іспанська, японська, португальська | Мови ваших найбільших ринків за виручкою, інвесторами або наймом. Кожна є серйозним якором у мовній моделі. Особливо німецька, якщо ви працюєте в DACH — і закладіть бюджет на суворіший бар'єр. |
| Стратегічні регіональні | Арабська, гінді, російська, корейська, італійська, нідерландська, турецька, українська, польська | Регіони з великим населенням або високою цінністю, де ви реально присутні. Виправдано за наявності справжньої ділової активності, а не просто «хочемо виглядати міжнародно». |
| Довгий хвіст | Все інше (індонезійська, тайська, в'єтнамська, суахілі, каталонська тощо) | Лише за конкретної причини: конкретний вихід на ринок, місцеве партнерство, регіональна репутаційна проблема. Охоплення заради престижу — це чисті витрати. |
За таблицею стоять два принципи. Перший: слідуйте за виручкою та ризиками. B2B-компанія, чиї клієнти — німецькі виробники, потребує німецького розділу набагато більше, ніж десятка дрібних розділів, що добре виглядають у презентації. Споживчий бренд, що виходить у Південно-Східну Азію, має протилежні пріоритети. Правильний список мов — це бізнес-документ перш за все і вже потім — документ Wikipedia. Саме тому ми формуємо обсяг багатомовної роботи в рамках ширших B2B Wikipedia services, відштовхуючись від ваших ринків, а не від стандартного пакету.
Другий: кожен розділ, який ви додаєте, — це розділ, який треба підтримувати. Це витрати, про які більшість команд забуває на етапі планування й виявляє пізніше. Сорок статей сорока мовами — це сорок поверхонь для вандалізму, нераптового правок, номінацій на видалення й повільного фактологічного дрейфу, в мовах, які ваша команда може не читати. Додавання мови — це не одноразова покупка; це тривале зобов'язання. Одного цього достатньо, щоб жорстко відбирати список пріоритетів. Менше розділів, але добре підтримуваних, краще, ніж багато розділів, залишених гнити.
Переклад — це не створення
Ось та помилка, яку нас найчастіше кличуть виправляти: компанія (або дешевий підрядник) бере англійську статтю, пропускає через машинний переклад або молодшого перекладача й вставляє результат до німецької, французької та іспанської Wikipedia. За дні, іноді за години, сторінки отримують теги, переносяться до простору чернеток або висуваються на видалення. Гроші витрачені, а бренд тепер має видимий слід відхилених статей, що робить наступну спробу складнішою.
Це провалюється з причин структурних, а не косметичних:
- Джерела не перекладаються. Англійська стаття побудована на англомовних надійних джерелах. Німецька спільнота хоче джерел германомовних (або принаймні визнаних у Німеччині), зважених за її нормами. Перекладена стаття часто цитує список посилань, який цільова спільнота просто не приймає, і кейс значущості залишається недоведеним у цьому розділі. Переклад тексту ніяк не перекладає докази, що лежать в основі.
- Тон і структура різняться залежно від розділу. Кожна спільнота має конвенції щодо структури статті, що має бути у вступі, як описуються компанії, що вважається рекламним. Буквальний переклад англійської статті нерідко читається як рекламний або дивно структурований для редакторів іншого розділу, навіть якщо англійський оригінал був бездоганним.
- Текст машинного перекладу впізнається й не викликає довіри. Редактори одразу розпізнають артефакти МП. Стаття, що читається як перекладена, сигналізує про «імпортований рекламний контент» — саме той прапорець, що запускає прискіпливу перевірку й видалення.
- Аргумент щодо значущості треба наводити для тієї спільноти. Пройти рецензування означає, що стаття наочно відповідає планці того розділу з джерелами, яким він довіряє. Це редакторське судження і пошук джерел, а не завдання з конвертації мови.
Чесне формулювання: кожна мовна версія — це нова стаття, написана нативно для тієї спільноти, яка спирається на спільне дослідження та пакет джерел, але переписана для задоволення місцевих вимог значущості, джерел, тону та структури. Англійська сторінка закріплює список джерел і факти; німецька стаття пишеться як німецька стаття кимось, хто знає стандарти німецької спільноти. Саме тому реальний багатомовний розгорток оцінюється поперокційно з поперокційним доповненням джерел, а не як масове перекладацьке завдання. Хто продає вам «ми перекладемо вашу сторінку 30 мовами» — продає вам 30 видалень.
Wikidata як багатомовний хребет Knowledge Panels у всьому світі
Повернімось до структурованого шару, бо Wikidata тихо виконує важку роботу на кожному ринку одночасно — і це найважільніша та найдешевша частина багатомовної стратегії.
Єдиний добре побудований елемент Wikidata несе багатомовні мітки та описи (multilingual labels and descriptions): назву сутності та короткий опис усіма мовами, які ви заповнили. Коли Google складає Knowledge Panel для користувача в Кореї, назва та тип сутності можуть надходити прямо з корейських міток вашого елемента Wikidata. Той самий елемент обслуговує арабську, іспанську, гінді панелі. Один структурований запис — багато локалізованих відображень.
Це найважливіше в дуже поширеній ситуації, коли у вас немає статті Wikipedia певною мовою. Як ми показали в нашій роботі з шаром сутностей, Wikidata має значно нижчий бар, ніж Wikipedia — підтверджена існуваність та ідентифікованість, без високих вимог до значущості, які потрібні для статті. Тож навіть на ринках, де повноцінна стаття Wikipedia поки нереалістична, чистий багатомовний елемент Wikidata може забезпечити:
- Назву та тип сутності, локалізовані, у Knowledge Panel цього ринку.
- Узгоджені структуровані факти — дату заснування, штаб-квартиру, офіційний сайт, ідентифікатори — без залежності від існування статті якоюсь конкретною мовою.
- Зв'язки
sameAs, що прив'язують вашу сутність до авторитетних реєстрів (VIAF, ISNI, LEI, ORCID там, де застосовно), які самі по собі незалежні від мови.
Отже, для виходу на новий ринок послідовність часто така: спершу локалізувати шар Wikidata — мітки, описи, структуровані факти цільовою мовою, — що дешево, швидко та корисно незалежно від іншого; потім просувати повноцінну статтю Wikipedia у тому розділі лише там, де кейс значущості та ринкова цінність це виправдовують. Хребет Wikidata дає вам базовий рівень точної машиночитаної ідентичності кожною мовою за долю вартості статті — і ніколи не завадить майбутній статті. Це найменш використовуваний хід у міжнародній роботі з сутностями.
Управління: підтримка N версій без втягування в редакційні конфлікти
День публікації останньої статті — це не кінець проєкту, а початок фази підтримки, і багатомовна підтримка об'єктивно складніша за однофалову. Тепер у вас N поверхонь N мовами, кілька з яких ваша внутрішня команда не читає, і всі вони відкриті для правок будь-кого на планеті.
Ризики зростають із кожним розділом:
- Вандалізм і нераптові «покращення» мовою, яку ніхто всередині не моніторить, можуть «жити» тижнями.
- Повільний фактологічний дрейф — доброзичливий редактор «виправляє» дату заснування або штаб-квартиру в одному розділі, і тепер ваша структурована розповідь суперечить сама собі на різних ринках.
- Локалізовані номінації на видалення можуть з'явитися в будь-якому розділі в будь-який час, нерідко довго після публікації, і на них треба відповідати тією мовою, тій спільноті, за умовами тієї спільноти.
- Редакційні конфлікти — пастка, яка потрапляє в новини. Надто завзятий внутрішній маркетолог, що логіниться, щоб «виправити» критику у французькій статті, скасовує правку волонтерського редактора, отримує відкат, починає ескалацію — саме так тихий репутаційний актив стає публічним конфузом. Ризик конфлікту інтересів множиться з кожним розділом, де хтось може бути спокушений втрутитися.
Розсудлива багатомовна система управління виглядає так:
- Централізований моніторинг усіх розділів зі списками спостереження та оповіщеннями, що не вимагають від когось щодня вільно читати кожну мову.
- Факти підтримуються в Wikidata, щоб виправлення поширювалося автоматично, а не вносилося вручну в N статей непослідовно.
- Жодного прямого редагування внутрішніми людьми з очевидним конфліктом інтересів. Зміни пропонуються прозоро, на сторінках обговорень, з належним розкриттям — та сама дисципліна платного редагування, що захищає однофалову сторінку, застосована до всіх.
- Захист здійснюється людьми, які знають кожну спільноту. Обговорення видалення в польській Wikipedia виграє той, хто розуміє польські норми значущості й може аргументувати польською, а не перекладений copy-paste з англійського захисту.
Це непомітна, повторювана половина багатомовної роботи — і саме тому постійне супроводження (дивіться annual Wikipedia support) — це не допродаж, а єдиний відповідальний спосіб утримати мультирозділове охоплення. Непідтримуване портфоліо сорока статей не залишається активом. Воно перетворюється на сорок зобов'язань, кілька з яких тихо помиляються мовами, про які ви дізнаєтесь лише тоді, коли ШІ-асистент потенційного клієнта повторить вам цю помилку у відповідь.
Поетапний багатомовний розгортання
Зведімо все докупи: розсудлива послідовність — виважена, а не наскок. Ми ведемо багатомовні програми поетапно, щоб кожен крок знижував ризик наступного, а бюджет відповідав доказовій базі.
Фаза 0 — Стратегія та мовна карта. До будь-якого написання визначте які розділи і чому — орієнтуючись на реальні ринки, виручку та ризики: вправа з рівнів вище, перетворена на конкретний пріоритетний список. Результат: ранжований мовний план з бізнес-обґрунтуванням для кожного розділу та чесним попередженням, які (особливо німецька) мають вищий бар'єр.
Фаза 1 — Хребет Wikidata. Спершу побудуйте або очистіть єдиний елемент Wikidata: один QID, структуровані факти, посилання на авторитетні реєстри, а також багатомовні мітки й описи для всіх цільових ринків, включно з тими, де стаття ще не запланована. Це дешево, швидко й одразу покращує локалізоване розпізнавання сутності скрізь. Це також каркас, до якого всі наступні статті приєднуватимуть сайтлінки.
Фаза 2 — Якірна стаття. Створіть англійську статтю (або, іноді, найбільш релевантний для вашого бізнесу єдиний розділ) через правильне Wikipedia page creation — оцінку значущості, нативне написання, рецензування спільнотою, моніторинг після публікації. Це закріплює пакет джерел, з якого черпатимуть інші розділи.
Фаза 3 — Розділи ключових ринків, у порядку пріоритету. Розгортайте найцінніші мовні розділи по одному, кожен як нативно написану статтю з поперекційним доповненням джерел і власною оцінкою значущості — не переклади. Послідовне виконання дає змогу вчитися з прийому кожної спільноти перед зобов'язанням щодо наступної, і можна зупинитися або перерозподілити пріоритети, якщо планка якогось розділу виявиться вищою, ніж очікувалося.
Фаза 4 — Стратегічні та «довгохвостові» розділи — там, де виправдано. Додавайте подальші розділи лише за наявності конкретної ринкової причини. Чиніть опір тязі до статусу. Кожне доповнення — це зобов'язання щодо підтримки.
Фаза 5 — Постійне багатомовне управління. Централізований моніторинг, узгодженість фактів через Wikidata, прозоре розкрите редагування та захист від видалення для кожної спільноти по всьому охопленню — безперервно, доки сторінки важливі.
Наскрізна нитка — чесність щодо вартості та ризиків. Багатомовна Wikipedia і Wikidata, зроблені правильно, — це одна з найпотужніших частин глобальної інфраструктури видимості в ШІ, яку компанія може мати: те, що змушує модель описувати вас правильно, чи запитують її англійською, арабською чи японською. Зроблені як масовий перекладацький наскок — це швидкий спосіб витратити багато грошей і генерувати видалення мовами, яких ви не читаєте. Різниця повністю в дисципліні: єдина уніфікована сутність, повага до незалежних правил кожного розділу, мови обрані за ринковою цінністю, а підтримка розглядається як частина роботи, а не як доповнення.
Продаєте більш ніж на один ринок і не знаєте, які мовні розділи варті уваги? Напишіть нам на team@wikibusines.com, і ми надішлемо чесну, ринково орієнтовану карту мовних пріоритетів — включно з тими розділами, які ми б пропустили.