Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Language translations #26

Open
Calinou opened this issue Sep 1, 2015 · 20 comments
Open

Language translations #26

Calinou opened this issue Sep 1, 2015 · 20 comments
Labels
enhancement help wanted high priority

Comments

@Calinou
Copy link
Member

Calinou commented Sep 1, 2015 •
edited by rubenwardy
Loading

See acceptance criteria
@rubenwardy
Copy link
Member

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

@est31
Copy link
Contributor

est31 commented Sep 1, 2015

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.

@rubenwardy
Copy link
Member

rubenwardy commented Sep 1, 2015 •
edited
Loading

Github doesn't support it, however, so makes things more difficult.

Edit (2023): GitHub supports plugins now

@est31
Copy link
Contributor

est31 commented Sep 1, 2015 •
edited by rubenwardy
Loading

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.
    [...]

@srifqi
Copy link
Member

srifqi commented Jun 20, 2016

Then, why we don't use Javascript instead? I know that some users just turn off their Javascript for their security reason.

@Calinou Calinou mentioned this issue Feb 5, 2017
Closed
@zaoqi
Copy link
Contributor

zaoqi commented Feb 9, 2017

#89

@mnh48
Copy link

mnh48 commented Jun 19, 2019

Ping me when the website is ready for translations.

@rubenwardy rubenwardy mentioned this issue Sep 29, 2020
Closed
@wsor4035
Copy link
Contributor

linking github/pages-gem#401 here

@Lemente
Copy link
Contributor

Lemente commented Oct 18, 2021

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.

@rubenwardy
Copy link
Member

rubenwardy commented Aug 17, 2022 •
edited
Loading

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/

@rubenwardy
Copy link
Member

GitHub Pages now supports building using GitHub Actions, so you can use any jekyll plugin for this

@rubenwardy
Copy link
Member

rubenwardy commented Mar 6, 2023 •
edited
Loading

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/)

@xipe-totec-gnu
Copy link

Ping me too when the website is ready for translations. I'd like to contribute.

@loviuz
Copy link

loviuz commented Jun 25, 2023

Hi all! Do you want to add a plugin for the translations, or do you have plan to switch to another tool, like hugo?

@rubenwardy
Copy link
Member

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

@loviuz
Copy link

loviuz commented Oct 7, 2023

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? :-)

@rubenwardy
Copy link
Member

rubenwardy commented Dec 14, 2023 •
edited
Loading

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

@wsor4035
Copy link
Contributor

astro is also popular

@loviuz
Copy link

loviuz commented Aug 25, 2024

After some months, I'd like to remember that I am available as a contributor for migration and especially for italian translation, but it is quite hard to me to start migration to a new static site generator like hugo from scratch, because I have no time to coordinate and/or to perform this, because it is a hard task that need lot of coordination with the main team, at least at the beginning.

Pls treat this comment mainly as a ping for this issue :-)

@Zughy
Copy link
Member

Zughy commented Nov 10, 2024

Relevant: user who maintains the French player wiki is fine with deleting the wiki, but they want the site to be translatable first https://forum.luanti.org/viewtopic.php?p=440396&sid=5260ec1e045f5630b157f34f11f04cbc#p440396

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement help wanted high priority
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests