Move wiki: Search engines don’t Index GitHub wiki

[ann0see]

The wiki doesn’t seem to be indexed by google:

https://github.community/t/my-github-wiki-is-not-crawl-data-by-google/947

That’s a big problem. I’d suggest a change to an other wiki app.

77 is related

[gilgongo]

I had suspected this was the case. I thought at first it was just taking the Google bot a while.

So. Github Pages? That would allow for proper internationalisation too I think.

[ann0see]

As far as I know, GitHub pages doesn't support PHP so all the translation etc. would have to be managed client side. I don't see that as practical. source forge does support PHP and MySQL but do we need to host an own wiki? Can't we use something like read the docs?

The fastest fix would be to move the wiki into a docs/folder but what about translation?

Open questions:

• What happens to llcon.sourceforge.io?
• How do we handle translations
• How do we enable contribution

https://github.com/corrados/jamulus/wiki (the base page) does get indexed

[gilgongo]

Can't we use something like read the docs?

What do you mean?

[ann0see]

Read the docs is an online documentation platform with localization: https://readthedocs.org/

Probably there are also other services which might have some kind of GitHub synchronisation?

[gilgongo]

Probably there are also other services which might have some kind of GitHub synchronisation?

Still a bit confused. Do you mean you want something that has GitHub synchronisation but also PHP or some other server-side processing?

[ann0see]

What I‘d prefer: A service showing the wiki hosted somewhere (not having to be maintained by anybody of the jamulus project) which displays the github wiki. So all changes would be made on github but the viewable and searchable/translated content is found on that page.

This would allow easy migration and editing by anybody (Wikipedia style). If we move to e.g. read the docs I assume we‘d loose quite some functionality (namely open editing) but we‘d have proper translation. And there wouldn‘t be an automatic github/read the docs syncronisation. But I‘m not sure about that yet.

[ann0see]

Something similar: https://www.gitbook.com/

Both seem to be quite good

Read the docs and GitHub wiki:

https://coderwall.com/p/3aamsa/sync-documentation-between-source-and-wiki-on-github

Gitbook and GitHub wiki:

https://docs.gitbook.com/integrations/github/import-of-github-wikis

[gilgongo]

Both seem to be quite good

Forgive me, but these solutions look very boring. Why not take this opportunity to present Jamulus like this, or this, or this? Something that could make it look interesting and fun rather than locking it into looking like an academic research project?

[ann0see]

Actually for a wiki it's quite difficult. I must admit that I’m not a webdesigner or similar.

What could be done: Have two websites: Site 1: Setup guides Site 2: For geeks (This can be on GitHub)

By the way: I'm currently editing the getting started page. Could you please have a look at it in about 30 minutes? #602 related

[gilgongo]

OK I think it's probably a good idea to split the information architecture for Jamulus into an easily-consumable and (one day) nicely presented "front end" for normal people, then having a wiki for geeks that will I'm afraid probably become overly complicated, buggy and confusing (Just this week I had to remove to a separate page a massive amount of text about a multi-distro shell script to automate the Linux install. This was of course added by someone who thought it was OK to make it look like you have to have a doctorate in computer science to install it).

While it may be an article of faith, I do think the adoption of Jamulus is much more dependent than we realise on whether it presents itself as being hard to use. Our goal right now should be to make Jamulus usable without assuming people want to know how it works. They don't have to know unless they really want to. They just want to get it running, click on a server, play and sing.

I'll have a look at your edits with the above in mind :-)

[chrisrimple]

FWIW, I've had good success pointing people to my doc, which I've written for non-technical users. Yes, it covers more than just Jamulus, but I'd be happy to extract out portions of the Jamulus section for the Wiki, etc. I've made the same offer to the Jamulus World Jam folks.

https://docs.google.com/document/d/1smcvsxdaaViPQvGMQHmah_6BQeqowhmGSFMHfnlY2FI/

[ann0see]

Ok. So https://github.com/corrados/jamulus/issues/77#issuecomment-698497863 could be an option. But honestly I‘d just use gitbook or read the docs for the technical part at least. The getting started guides (client and server) should remain up but focused on technically savvy people. A link pointing to a site with a quick start guide has to be added there.

The quick start guide is shown on a separate page e.g. on llcon.sourceforge.io or even better (since then pull requests would be possible) on GitHub Pages. The only problem I see is translation on GitHub since it doesn’t support PHP.

[gilgongo]

The only problem I see is translation on GitHub

I was assuming that if we used GitHub pages for everything, we'd all use Jekyll, which supports i18n.

[ann0see]

Ok. If that’s the case, I‘d consider that as the solution

[gilgongo]

If we move the wiki content to Github Pages (where I assume it will be indexed), then there is also the question of how the overall information architecture should work after that. A Github Pages site would imply a fifth "home" for Jamulus: so the existing SourceForge home page, the SourceForge "site" (where binary downloads are distributed, and where the SourceForge forums are), the Facebook group, and the Github "readme" home page.

This seems to be a bit fragmented. Is that a problem?

(BTW I wonder who owns jamulus.org Creation Date: 2020-04-27?)

[ann0see]

If there's no duplicate content I'd say it's ok.

The Jamulus website (llcon.sourceforge.io) could be moved to github pages (since the devs can update it then) GitHub should focus on everything related to coding/contributing (what the devs see).

The SourceForge site should handle downloads and the forum (what the user sees) (--> remove all source code hosted there). Facebook (it's a private group. Therefore I don't see any issues). jamulus.org I hope they don't setup a phishing/malware site there. That has happened to a project I followed.

[gilgongo]

I guess if we can get what's on the wiki now to appear in Google searches first then we should be OK. The problem today may be that people are finding other sources of info that might be out of date or incomplete instead.

The domain name thing is a bit of a worry (same with jamulus.com, registered in 2013). But I guess there's nothing that can be done about that really.

[ann0see]

I guess if we can get what's on the wiki now to appear in Google searches first then we should be OK.

Agree

The domain name thing is a bit of a worry

Kind of. We could of course register something like jamulus.app jamulus.music

I assume we can’t really find the owner (we can of course try via Whois)

[ann0see]

I think we all agree that the wiki should be moved to github pages. We could start a first try (with a robots.txt blocking google indexing) and we could declare the new wiki as experimental. @corrados should create a new repo e.g. JamulusDocumentation or JamulusWiki or JamulusHelp which is a clone of the current wiki git repo. and setup GitHub pages for it. Tests can be done there

[gilgongo]

I would suggest calling the new repo JamulusHome to avoid any implication about the type of content.

[ann0see]

Yeah. That’s ok too. But keep in mind that the url would then probably be something like corrados.github.io/JamulusHome

[ann0see]

Another option would be orphan branch on the main jamulus repo named e.g. gh-pages.

https://stackoverflow.com/questions/5086833/how-to-create-a-branch-without-adding-all-the-existing-files

This would allow an url like https://corrados.github.io/jamulus

(Actually that's what I'd prefer)

[corrados]

@corrados should create a new repo e.g. JamulusDocumentation or JamulusWiki or JamulusHelp which is a clone of the current wiki git repo. and setup GitHub pages for it. Tests can be done there

You could create that repo in your account. If it is stable, I can create a fork of that in my account.

[ann0see]

Yeah. But since @gilgongo is the Wiki Manager, I‘d propose he creates the repo on his account and gives access to us.

Later, I‘d prefer to use an orphan branch on the main repo to have a central place for the wiki and the code.

PRs on this repo would then also be possible for the documentation.

[gilgongo]

OK so I've created https://github.com/gilgongo/jamulushome and made corrados and ann0see collaborators

[chrisrimple]

I'd like to contribute to the Wiki. Lots of good content in my doc that I can move over...

https://docs.google.com/document/d/1smcvsxdaaViPQvGMQHmah_6BQeqowhmGSFMHfnlY2FI/

[gilgongo]

OK @chrisrimple I added you too.

[ann0see]

Thanks!

[ann0see]

It shouldn’t be too difficult to setup Jekyll (but I have also no knowledge of it):

https://jekyllrb.com/docs/

Should the llcon.sourceforge.io homepage also be moved there (my suggestion)? This would remove one more spot where information can be found.

What about style/layout? I‘d prefer to use the same framework/colours as the website currently uses to remain consistent.

[ann0see]

I just uploaded the website. Edit: and setup basic Jekyll templates (style, translations,...). @gilgongo should have a look at it since he should know how to handle jekyll if he also handles the wiki. I can help with setting up HTML and CSS.

[gilgongo]

OK thanks I'll see if I can get the basics of Jekyll. We also need to think about the i18n with that too I guess.

[ann0see]

also need to think about the i18n with that too I guess.

I‘ve already setup a little bit.

Edit1: There’s currently duplicate code in the index.html and wiki Layout/templates pages.

[gilgongo]

OK so I've got the repo locally (for some reason I get a permissions error when I try to clone it, so I had to get the .zip instead) and using jeckyll serve I can see it's got the home page and the gettingstarted.md

So what's next?

[ann0see]

Next steps are

• Enable GitHub Pages on your repo
• homepage translation (without breaking the structured data for SEO)
• template unification (currently the wiki has a template while the index page doesn’t have one). They should at least share the <!DOCTYPE html> (to some extent) and footer.
• wiki navigation

[gilgongo]

Enable GitHub Pages on your repo

Done that (on /root), but: "Your site is having problems building: The tag tf on line 1 in gettingstarted.md is not a recognized Liquid tag. For more information, see https://docs.github.com/github/working-with-github-pages/troubleshooting-jekyll-build-errors-for-github-pages-sites#unknown-tag-error."

So it's not building.

[ann0see]

Probably the translation plugin is unsupported. Maybe we can change it or build on a local machine.

GitHub Actions might also be a way out.

See https://github.com/helaili/jekyll-action

https://github.com/BryanSchuetz/jekyll-deploy-gh-pages

[ann0see]

Ok. The page is now partly working.

homepage translation (without breaking the structured data for SEO)

Done. At least the technical part

wiki navigation

Basic work is done

There is still a lot of room for improvement. I don't want to be the person responsible for the wiki ;-). Of course I can do basic HTML, CSS, Webdesign but not as the only one. Maybe somebody else also knows basic webdesign?

[gilgongo]

I've asked about the unsupported tag https://github.com/kurtsson/jekyll-multiple-languages-plugin/issues/180

Meanwhile, there is this:

http://polyglot.untra.io/

[ann0see]

Polyglot looks easier, so probably this one is better. But I don't think it's supported natively either.

[gilgongo]

Or this approach? https://www.sylvaindurand.org/making-jekyll-multilingual/

[ann0see]

Yeah, this could be a good option too. I hope it does everything needed.

[gilgongo]

My understanding of Jekyll is very limited right now, but it seems like it might be best to customise a Liquid theme that supports both i18n and GH Pages (Minimal Mistakes?) and go from there.

After all, we have some good assets already (logo, banner, colourways) and have a reasonable information architecture (although some aspects could be improved, obviously). What we lack are the more advanced aspects of front-end architecture that a theme might provide. What I don't know is the degree of limitation a theme might impose though.

[ann0see]

For me, it sounds like the theme only supports translation of UI elements, not whole .md files (in our case wiki pages). I‘d go with a custom GitHub action probably.

GitHub actions also allow HTML&CSS minification: https://github.com/nizarmah/auto-minify

[ann0see]

Ok. I've setup a branch with polyglot. For me, it's a bit messy (development) since it automatically rewrites relative links and (at least for me) does too much automatically. E.g. I had to add spaces in the translation picker which is not really dev friendly.

But there are also some pros: It's easy to translate the title (but that's probably also possible with the other plugin)

All in all, it might be easier later for translation of single pages (since there are less folders --> the structure might be a little bit easier).

What do you think?

[gilgongo]

Not sure as for some reason I get "Could not read from remote repository" when I try to git clone (was getting that before too).

[ann0see]

That’s strange. Since you own the repo you should also be able to read it? Do you use http or ssh? I can clone it via ssh.

[gilgongo]

git clone git@github.com:gilgongo/jamulushome.git says I don't have permission.

git clone https://github.com/gilgongo/jamulushome.git lets me clone it,

Weird.

[ann0see]

Is your SSH key invalid?

But I‘m glad you "fixed" the problem.

[ann0see]

I‘ve now included the navigation.

The homepage is still missing and a link to edit the page. But all in all it can be considered as first (working) beta.

[gilgongo]

Now getting "The tag tf on line 19 in /_layouts/wiki.html is not a recognized Liquid tag." from GitHub Pages though