minetest.github.io
minetest.github.io copied to clipboard
Language translations
The easiest way would be to do this:
- Put translations in sub folder
source/en/download.html
- Maybe keep English index.html in root, doesn't matter.
- Set up canonical links
Pages are should be mostly text
There seems to be a preprocessor project: https://github.com/ruby-gettext/jekyll-task-i18n
It seems to be what @rubenwardy proposes, just creation of the pages is automated, and we have .po files, allowing to be weblate-able.
~~Github doesn't support it, however, so makes things more difficult.~~
Edit (2023): GitHub supports plugins now
~~Agreed. The project writes:~~
Edit (2023): GitHub supports plugins now
There are some i18n softwares for Jekyll that are implemented as Jekyll plugin such as jekyll-localization and jekyll-i18n. jekyll-task-i18n uses preprocessor approach instead of Jekyll plugin. This approach has the following advantages:
- You can use i18n feature on GitHub pages. [...]
Then, why we don't use Javascript instead? I know that some users just turn off their Javascript for their security reason.
#89
Ping me when the website is ready for translations.
linking https://github.com/github/pages-gem/issues/401 here
I am currently a bit stuck in my project because of the lack of translation of the website. I am running a workshop where people might come with their own computer, and I want them to install the game autonomously. I cannot expect everyone to be fluent in english. There are a few French guides, but they aren't as clear and polished as the website.
I will probably use one of those guides (probably the Getting Started page), or use a website that automatically translate web pages for now.
I also feel like having the game fully translated, but not the download page is detrimental to the project and the translation effort as a whole.
I added translation support to the website for one of my projects: https://renewedtab.com
Translators can translate it using my Weblate instance. It doesn't use any Jekyll plugins, so supports GitHub Pages.
It works by putting all the strings into yml files in _data/locale
. Weblate supports using yml for translations.
Source code: https://github.com/rubenwardy/renewedtab_website/
GitHub Pages now supports building using GitHub Actions, so you can use any jekyll plugin for this
Acceptance criteria:
- Translation using Weblate must be supported (To do this, the translations should be files in the git repo using json, gettext, or another weblate-supported format)
- English used as source strings. Translators will then translate English strings when they appear. Translators should not be required to translate entire pages at once
- Languages need to whitelisted before they appear (this prevents partial translations from appearing before they are ready)
- Each translation should have its own directory (ie:
/en/downloads/
). Each page should link to other translations using<link>
tags in the<head>
and also with a language selector in the nav bar - Old pages should redirect to english translations (ie:
/downloads/
to/en/downloads/
)
Ping me too when the website is ready for translations. I'd like to contribute.
Hi all! Do you want to add a plugin for the translations, or do you have plan to switch to another tool, like hugo?
Hi all! Do you want to add a plugin for the translations, or do you have plan to switch to another tool, like hugo?
@loviuz We don't have any plans currently to switch to another tool, but if that's easier to implement translations in then it could be discussed
Jekyll is a bit old. It can be (easily) migrated to Nikola, but I don't know it so well. I know hugo, another static website generator written in go. Can I propose a theme for hugo to a possible restyling + multilanguage website? :-)
I had a look into this and none of the plugins for Jekyll were fit for purpose. The one that was best maintained would break redirects for example, so break all pages
I think the best approach would be to switch to a different static site generator. Perhaps Hugo or Eleventy. I'm familiar with Eleventy but not Hugo. It's probably best to keep the styling the same though, and just attempt the markup for the new generator and translation
astro is also popular