* Update base-fr.yaml
All the update is not finished.
Also I have reorder some lines according to base-en.yaml to simplify the comparizon.
Based on base-en.yaml from the commit f584d9d93e
* Correction empty-lines
Correction of "too many blank lines (5 > 2) (empty-lines)"
Theses lines was to show where some line should be added in the future
* Text corrections
According to LeopoldTal remarks
* idiomatic
Sans nom -> Sans titre
* Painter description improuvement
* polish French translation
* fold long lines in French translation
* add missing French references
* Add last traduction
* Corrections after YAML Lint checks
723:5 error duplication of key "reward_splitter" in mapping (key-duplicates)
731:201 warning line too long (225 > 200 characters) (line-length)
752:9 error syntax error: could not find expected ':' (syntax)
* Bad indentation
816:9 error syntax error: could not find expected ':' (syntax)
Co-authored-by: Leopold Tal G <leopold.tal.dg@gmail.com>
Building the standalone with V8 v8 (Node v14) fails at step `sounds.musicHQ`, either by running out of memory or with the error "Invalid string length". Building with V8 v7 (Node v12) succeeds.
This is because `gulp-cache` builds a 994-MB string when [stringifying file contents](https://github.com/jgable/gulp-cache/blob/master/src/task-proxy.js#L262) to cache them. V8 v8 [limits string length to around 537 MB](https://github.com/v8/v8/blob/master/src/objects/string.h#L384), and thus cannot represent this string. (V8 v7 allows around 1074 MB, which is why the build passes on Node v12.)
But [`theme-full.mp3`](https://github.com/tobspr/shapez.io/blob/master/res_raw/sounds/music/theme-full.mp3) is only 79 MB: how did we get 1250% overhead?
Unlike plaintext files, binary files are read as buffers, but [by default](https://github.com/jgable/gulp-cache/blob/master/src/index.js#L46) `gulp-cache` stringifies them naively, producing the extremely inefficient representation:
````
[
{
"cwd": "/Users/tobspr/shapez.io/gulp",
"base": "/Users/tobspr/shapez.io/res_raw/sounds/music",
"contents": {
"type": "Buffer",
"data": [
73,
68,
51,
4,
0,
0,
…etc.
````
Fortunately, `gulp-cache` [can read base64-encoded cache files](https://github.com/jgable/gulp-cache/blob/master/src/index.js#L26).
Instead of using the default file transform function, **pass a `value` option to base64-encode the file contents**. This results in only 33% overhead on cache file size (106 MB for the largest file).
This has multiple benefits:
- Fixes the build failure
- Requires less memory (from 6 GB down to < 1 GB on my machine)
- When cache files are found, the `sounds.musicHQ` is much faster (from ~30 s down to ~4 s on my machine)
- Smaller cache files on disk