When the name of the view in `routes.json` does not match the name of the resource in transifex there needs to be a mapping added to the script that generates translations. _Note: the resource name in transifex is usually based on the name of the source file in the `views` directory. Usually the name of the view in the routes file matches._
Since `routes.json` is a JSON file that does not support comments there’s no way to add a warning to the file when someone is adding a route.
The sympton was the message that there were no translations for ‘vernier’ or ‘embed’ when running translate. The `vernier` route is actually the `gdxfor` view, and `embed` is just another version of `preview`
start to depend on `scratch-l10n`
So far only the supported locales is used.
There is one small difference between scratch-l10n and the `languages.json` that was removed.
languages was:
`{locale: ‘languagename’, …}` key value pairs.
l10n exports:
`{locale: {name: ‘languagename’},…}
That required an additional change to the language chooser.
* Add error checking and testing for translations. Also make build-locales quieter if there are no problems.
* Allow build with broken translations (to allow development), but fail test so that broken translations don't get merged or deployed
New of tips page, uses cards from new resources server (s3)
* added get-localized-urls script to get the generated json from the s3 bucket
* added /tips route
* correct localized-urls for other pages
* remove thingstotry
* redirect /go
* fix up /info/cards view to use resources (s3).
* redirect /go to /tips
* change /hoc redirect from /go to /tips
* Add full set of cards pdf download to tips localization
* removed cards and guides from static PDFs, they are all coming from resources.scratch.mit.edu now.
* removed things to try view
Corrections for reviews:
* decided to pretty print the localized URLs
* replaced console.errors with process.stdout and fail with exit(1)
* formatted localized-urls to make it easier to read
* moved link outside `<Button…` makes whole button clickable instead of just text
* fixed up css styles, removed unnecessary classes
* corrected “unused” resource links
Fixes#1199 by continuing the iteration over languages even if a view doesn’t have an l10n file. The issue was that only the `en` language object was getting added when the view didn’t have an l10n file, because of the `hasOwnProperty` check. This adjusts it to iterate over languages anyways, and only ouput the `No translations for…` message if it’s for a language of a view that does have an l10n file.
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.
Most problems were due to strings being duplicated and overwriting each other. Updated the build-locales script to keep track of duplicates.
Project Curated by on the splash page was just missing the formatMessage call.
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.
The catch there before is meant to just continue if it comes across a file that doesn't exist (in which case the language will default to english). However, it was not specific enough – now, it only catches the error if the file doesn't exist, and throws anything else, preveting a build.
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.
1. Load locale strings into `window._messages` in a separate file added to `template.html`, which contains view-specific and general strings
2. Update build-locales to compile separate files
