jekyll-polyglot ще не підтримується нативно в github-actions
gem install jekyll-polyglotу _config.yml наступні властивості керують тим, які мови підтримує ваш вебсайт. Ви можете надати підтримку новій мові, додавши її до цих значень (див. нижче). Мови ідентифікуються за їхніми офіційними кодами локалі.
languages: ["en", "es", "fr", "de"]
default_lang: "en"
exclude_from_localization: ["images", "fonts", "sitemap"]
url: https://polyglot.untra.io
languages: масив кодів локалей, що ідентифікують мови, які підтримує вебсайт.default_lang: мова за замовчуванням для вебсайту.exclude_from_localization: теки та каталоги, що є частиною побудованого вебсайту, але не потребують локалізації. Це насамперед задля скорочення часу побудови, а також тому, що файли активів, такі як зображення та шрифти, є великими частинами вебсайту, що гарантує, що вони не «перекладатимуться» або не дублюватимуться у вихідних даних без потреби.url URL вашого продакшн-вебсайту.Якщо у вас вже є функціональний одномовний вебсайт, додавання нової мови не буде тривіальним. Щоб справді створити багатомовний вебсайт, очікуйте, що вам доведеться переробити весь свій вміст новою мовою. Це може здатися великою справою, але розгляньте переклад частинами. Контент — король; важливіше, щоб нові сторінки та дописи отримували оновлені слова в перекладі. Створення багатомовного вебсайту складно лише тоді, коли ви вимагаєте, щоб він був ідеально перекладений з самого початку.
По-перше, ви (і ваша команда, і ваші менеджери теж, якщо у вас є декілька в наявності) повинні обговорити та вибрати, який вміст потрібно перекласти на новий вебсайт. Ви маєте вибрати свій бажаний базовий вміст для перекладу. Розгляньте аналітику, популярні сторінки та блог-дописи, а також потік поточних і майбутніх користувачів вашого вебсайту. Якщо сумніваєтеся, надавайте перевагу сторінкам перед застарілими блог-дописами. Якщо це означає швидший запуск нової мови, застарілі дописи можуть бути не вартими зусиль перекладу.
По-друге, ви повинні (або наполегливо рекомендується) забезпечити 100% покриття насиченого вмісту вашого сайту. Це маленькі рядки, вбудовані складнішими способами. Існує кілька способів ітерувати насичений вміст. Пам’ятайте, ви повинні підтримувати всі маленькі рядки мови у своєму насиченому вмісті.
Вміст вебсайту надходить у двох варіантах: базовий та насичений.
Базовий вміст — це плоский текст блог-дописів, сторінок і неінтерактивного вмісту. Подумайте про сторінки та дописи. Базовий вміст — це паливо для кліків вашого вебсайту. Polyglot надає базовому вмісту резервну підтримку.
Насичений вміст є інтерактивним, ефектним і складається з коротших рядків. Подумайте про навігаційні панелі та випадні меню. Насичений вміст є більш технічним і утримує ваших відвідувачів на сайті. Немає резервної підтримки для відсутнього насиченого вмісту.
Наступні інструменти liquid доступні для використання з jekyll-polyglot:
{% for lang in site.languages %}
{{lang}}
{% endfor %}site.languages вказує безпосередньо на масив languages у _config.yml. До нього можна отримати доступ через liquid.
{{site.default_lang}}site.default_lang вказує безпосередньо на рядок default_lang у _config.yml. До нього можна отримати доступ через liquid.
{% if site.active_lang == "es" %}
<h1>Hola! Como estas?</h1>
{% endif %}site.active_lang — це код локалі, для якого створюється сторінка. Це "de" для німецької версії сторінки, "es" для іспанської версії і так далі. До нього можна отримати доступ через liquid.
Використовуючи ці інструменти, ви можете вказати, як приєднати правильний насичений вміст.
{% if page.rendered_lang == site.active_lang %}
<p>Welcome to our {{ site.active_lang }} webpage!</p>
{% else %}
<p>webpage available in {{ page.rendered_lang }} only.</p>
{% endif %}Змінна page.rendered_lang вказує фактичну мову вмісту сторінки, дозволяючи шаблонам визначати, коли сторінка обслуговується як резервний вміст.
За замовчуванням github не дозволяє блогам jekyll використовувати плагіни. Це зроблено навмисно, щоб запобігти виконанню шкідливого коду на серверах github. Хоча це ускладнює використання Polyglot (та інших плагінів jekyll), це все ще можливо.
_site/ у gh-pagesЗамість того, щоб розмістити свій блоговий рушій Jekyll на github, ви можете розробляти свій вебсайт jekyll на окремій гілці, а потім надсилати побудований вміст _site/ у вашу гілку gh-pages. Це дозволяє керувати та контролювати джерело розробки вашого вебсайту за допомогою github без необхідності покладатися на github для побудови вашого вебсайту!
Ви можете зробити це, зберігаючи свій вміст Jekyll на окремій гілці та фіксуючи лише теку _site/ у своїй гілці gh-pages. Оскільки це лише статичні html-сторінки в теках, github буде хостити їх як будь-який інший вміст gh-pages.
Цей процес значно полегшується простим скриптом, який створить ваш вебсайт і зафіксує теку _site/ у вашому gh-pages. У багатьох людей такий є. Ось один. Ось ще один. Ось мій скрипт публікації:
#! /bin/sh
# change the branch names appropriately
rm -rf site/_site/
cd site && bundle exec jekyll build && cd ..
git add site/_site/ && git commit -m "$(date)"
git subtree push --prefix site/_site origin gh-pages