☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io
This is a harp.js project. All assets are automatically compiled by harp, there’s no build pipeline. The site is bilingual, since harp doesn’t explicitly support this, there are some extra things to be aware of, see the Development Guidelines section below.
To run the server with livereload/browsersync:
npm run server
To compile the site into www/ for looking at the output or serving that statically (without the FOUC, for example):
npm run build
and to serve the previously built version of the site from www/:
npm start
The structure of the site is defined in the two _data.json files, one in root for the english site, one in /de for the german one. The two versions of the site need their own translated copies of each partial they use, this is why some of the partials are stored in /en/partials and /de/partials, as opposed to the content, which lives in / for english and /de for german.
Any .ejs file that contains text should exist in both languages, except _customers.ejs, where the only text is company names that don’t need to be translated. This means that each language has its own _header.ejs and _footr.ejs partial, so if you change the navigation, you have to change that twice, too.
The _data.json files define which pages get rendered under which URL, and can define some vars for use in that page, take, for example, the german FAQ page entry:
"haeufige-fragen": {
"pageTitle": "Häufig gestellte Fragen",
"bodyClass": "faq gk-saas",
"locale": "de",
"otherLanguageURL": "/faq"
},pageTitleis used in_layout.js, which is the generic container template for all other templates.bodyClassis the same. These two are variables because<head>and<body>live in_layout.jsand not in the individual templates.localeis the local shortcode for the language that page is in. This is super redundant, but also the path of least resistance.otherLanguageURLis the url of the same page in the other language. There is probably a super-elaborate way to do this programmatically, but since we only ever want to support two languages, this is fine 🐶🔥 for now. This is the URL that gets used in each languages’s_header.ejspartial to render the language switching link. If we had identical URLs for both languages, we wouldn’t need this, but it’s more consistent this way.
ℹ️ There’s some UI text inside CSS pseudo elements that we can’t translate, for the image enlarge on tap, for example.
Just merge to master 👍
This runs travis, which runs deploy.js, which publishes a newly-built version of www to the gh-pages branch on GitHub.