Open ajmas opened 7 years ago
Another possibility
I made an issue here asking what I need to do to get it supported : https://github.com/github/pages-gem/issues/438
I'd love to add multi-lingual support. It looks like there are multiple multi-lingual plugins out there. Is there a clear front runner? One with clear advantages over others?
Going by Gem downloads it would be https://github.com/Anthony-Gaudino/jekyll-multiple-languages-plugin The only possible problem with the Polyglot one, might be how it overrides the build https://github.com/untra/polyglot#how-it-works
Going by Gem downloads it would be https://github.com/Anthony-Gaudino/jekyll-multiple-languages-plugin
I'd be hesitant to add a plugin without a test suite to ensure the intended functionality. Adding a plugin to millions of sites will naturally expose edge cases, feature requests, and contributions, and we'd want to make sure that (positive) attention can be incorporate into a healthy project without risking the existing functionality, etc.
@benbalter What do you think about asking explicitly on the ISSUE template that before suggesting a plugin for GitHub Pages, it should be available as a gem, covered with a test suite?
@DirtyF Great call! Will get that going (unless you'd like to?)
@benbalter I did a proposal in #473.
Without having an answer for the best multi language plugin, I just want to add my support to adding one. It would best support both use cases:
Thanks for looking into this!
Although considering security and risk is important, but please imagine that there are so many customers that can't serve multiple-language pages. I really need the function.
GitHub Pages comes with limitations.
Fortunately, it's possible to host a Jekyll repository on GitHub and easily overcome those limitations by linking your GitHub repo to Netlify for instance. Netlify will automatically build your custom Jekyll site - with any plugin you require - when you push a commit to your GitHub Branch.
You can also use Travis CI or equivalent to deploy your custom build on GitHub Pages.
Thank you for the suggestion. I don't know whether the options are suitable for my case, anyway, I look into it. Thank you.
For those who can't wait on a plugin solution, https://www.sylvaindurand.org/making-jekyll-multilingual/ has a plugin-free solution which AFAICT would lend itself to an eventual switch to a plugin.
I've tried jekyll-multiple-languages-plugin but it breaks everything. Can't find support, will try Iarsrc link
I'm using jekyll-multiple-languages-plugin as well, and ended up compiling everything locally using the gh-pages
npm package and running gh-pages -d _site
after every change. This commits and pushes the _site
directory to a gh-pages
branch.
I found this how to about jekyll-multiple-languages-plugin. In your opinion what is the best solution to follow jekyll-multiple-languages-plugin or jekyll-multilingual without plugin?
Use data files for site specific language data and font matter for page specific data. I’ll post a temple link for regency when I’m back.
ICYMI jekyll-locale is a plugin currently in development to help handle i18n in Jekyll.
Up on the topic!
Where are we now? What can be done?
👍 for https://github.com/Anthony-Gaudino/jekyll-multiple-languages-plugin
For now, I'm using Netlify as @DirtyF suggested, though never a big fan of using extra external services.
So to brainstorm the issue discussions, the only thing blocking Github Pages to whitelist any Jekyll language plugin is the lack of tests?
It's a bit saddening to see that this issue has been opened for 4 years, still without any sign of an upcoming resolution.
I do understand that validating a plugin, and ensuring that it does not contribute to introducing a global security risk, is tricky, and does indeed warrant extra caution, but, considering that GitHub's new parent company, Microsoft, has always been at the forefront of providing localised content as well as easing up localisation matters for developers, it's disappointing not to see GitHub embrace the same stance and make sure that people, who do use GitHub's recommended services to provide web pages, can make these pages easily accessible for people of all horizons.
Thus, in case GitHub staff needs a little more convincing that this is an important matter, let me give you a concrete example of how the lack of progress on this issue is negatively impacting some GitHub users. In my case, as the developer of Rufus, which is a rather popular Windows Open Source utility, I am currently using GitHub pages to host the web site, and I must commend GitHub for making this service available to its users, on account that it has greatly reduced the headaches I was having with custom server hosting. As you can see however the web page for the application is quite plain looking, and I sure wouldn't mind being able to modernize it, as well as make its maintenance less dependent on editing plain HTML, by switching to GitHub's attractive Jekyll static page generation...
However, because of this very issue, I just cannot do that, because I also must provide localised versions of my content, and, if I am going to move to new ways of generating it, I sure would like to take this opportunity to also do away with the current mess of having to:
php-gettext
to generate localized pages).Thus I genuinely can't wait for the day where I finally switch to Jekyll generated content, with a GitHub supported multilingual plugin, and end this brittle, hard to support & hard to upgrade content generation process (which I'm sure many other people, who need to provide localised versions of GitHub pages have their own different version of). But for that to happen, it looks like GitHub will need to show the same level of commitment to localisation that Microsoft has, and bite the bullet on investing resources to test and validate at least one Jekyll multilingual plugin...
Hopefully then, after more than 4 years of users patiently waiting for progress on this matter, GitHub staff might consider that the benefits of solving this issue for users of GitHub services worldwide, does outweight the cost of having to approve a new Gem, and we may finally see this issue come to some form of resolution.
Thank you.
Hi, I used "jekyll-multiple-languages-plugin" plugin in a website and now want to serve that in GitHub Pages, But seems it's not possible.
There is no plan to whitelist this plugin? No idea? No, decide? no plan? It's not a new issue! https://pages.github.com/versions/
I'm aware this plugin maintenance stopped, there is any other plugin with support? https://github.com/kurtsson/jekyll-multiple-languages-plugin/commits/master
Thank you
I guess this is due to the fact that those american based companies think English is the only language around.
What a pity. Such cultural impoverishment.
In many ways the Jekyll team should be choosing a multilingual solution and pushing it on the community.
I ended choosing Hugo for my pages, since multilingual support is part of its architecture. I was also working on a project on GitLab, where they are more agnostic, but they have CI templates to deal with them.
Maybe we just need some GitHub workflow templates and then just go towards static website generators that are multilingual friendly?
Hi Is there any update on this plugin?
Well, considering that there still hasn't been any progress in 7 years, I will ask that GitHub either closes this issue altogether or provides us with an ETA/outline of what they are planning to do about it. It is not acceptable to leave your users in limbo about this for more than 7 years.
So I would request that GitHub makes a formal decision on whether they are planning to ever add support for a multilingual plugin, and have the courtesy to post it here. Thank you.
Some pages have a need to be multilingual, so it would be useful to have support for one of the multilingual Jekyll plugins in the gh-pages whitelist, without having to resort to using a CI for this.
Two possibilities: