This also moves all helper methods in `configure-fastly` into a separate utility file, and adds some additional unit tests for those utilities now that they are separated.
We’ve now exceeded our max number of characters for a condition in the Fastly API, and we need to make it larger to accommodate regex conditionals that can match on any of the routes in www currently.
This fixes the issue by moving the conditions – and the states that are affected by it, like setting the backend or cache ttls – to two custom vcl files that are updated via the Fastly API. One is for the `vcl_rev` config, and one is for the `vcl_fetch` config.
* automated tests for footer links
* renamed navbar test file and removed footer links to separate file
* run with make smoke
* added tests for join scratch and sign in in navbar
* fix linter errors & update www links
* addressed some of ray's comments
* fix failing test - projects row link
* maybe fix error?
* continue switching to click, convert so it runs with disabled selenium promise manager, and refactor to be less location dependent
* finish switching off of implicit reliance on selenium promise manager
Added tx-import, expects TX_TOKEN environment variable to be set to an API token for Transifex. If no API token exists it’ll just use the default English strings for everything.
Removed the localization spot checks because they were checking tha json got built from po files. With Tx-import the files are already json, and may possibly be missing.
* Don’t allow duplicate strings in a single l10n file
Added check_duplicate_strings to test for duplicates in a single file.
removed duplicates - tried to keep the more generic ‘key’
* revised test case for safer file reads
Since it's using `require` to get the localisation strings, check if the error is `MODULE_NOT_FOUND` before moving on – because if it isn't, then there is an unknown error that should be thrown. Thanks @rschamp for the suggestion!
Before we were using glob, which was about to start failing on subdirectories in views (which we started using in `conference`). Instead of searching for `l10n.json`, it seemed more appropriate to instead look for localization by using the configured pages that need to be localized.
1. checks the localization for a few reference languages for the nav bar
2. for our localized pages (splash, about, wedo2), it checks to see that there are locale strings, whether or not they're english (to make sure at least something is on the page).
This moves all locale/translation building to a dependency, `scratch-www-intl-loader`, as well as tests associated with it. Also gets rid of the `make translations` step.
