And a Hugo global variable which contains the site under build.
This is really needed to get some level of control of the "multiple languages" in play.
There are still work related to this scattered around, but that will come.
With this commit, the multilingual feature is starting to work.
Implements:
* support to render:
* content/post/whatever.en.md to /en/2015/12/22/whatever/index.html
* content/post/whatever.fr.md to /fr/2015/12/22/whatever/index.html
* gets enabled when `Multilingual:` is specified in config.
* support having language switchers in templates, that know
where the translated page is (with .Page.Translations)
(when you're on /en/about/, you can have a "Francais" link pointing to
/fr/a-propos/)
* all translations are in the `.Page.Translations` map, including the current one.
* easily tweak themes to support Multilingual mode
* renders in a single swift, no need for two config files.
Adds a couple of variables useful for multilingual sites
Adds documentation (content/multilingual.md)
Added language prefixing for all URL generation/permalinking see in the
code base.
Implements i18n. Leverages the great github.com/nicksnyder/go-i18n lib.. thanks Nick.
* Adds "i18n" and "T" template functions..
Hugo seems to ignore the meminterval I specify and always uses it's default of 100ms.
This seems to be because Hugo tries to take the meminterval from the command line
(an Int) and converts it to a String and passes it to time.ParseDuration. If you pass a
different meminterval (such as `1000` as above) it will fail (time.ParseDuration requires
some units) and use the default instead.
Changed `meminterval` to be a String and added better documentation for valid time units.
Resolves: #2325
On 4679fbee41, rebuild was disabled on
CHMOD filesystem events, but the code is overly aggressive.
In some situations, specially with older Mac's (using a Late 2008
Macbook), the events we receive might be aggregated. On my
particular laptop, I get this events:
INFO: 2016/07/26 18:08:51 hugo.go:737: Received System Events: ["<path>": WRITE|CHMOD]
These events are ignored because the code only checks for Chmod. This
commit fixes this by checking that the event is also not a Write or Create.
Related to #1587.
Meny people, including me, have a custom robots.txt in static.
Also remove that option from the command line; it doesn't feel
important enough.
Fixes ##2049
This disables highlighting for fenced code blocks without explicitly specified language. It also introduces a new `PygmentsCodeFencesGuessSyntax` config option (defaulting to false).
To enable syntax guessing again, add the following to your config file: `PygmentsCodeFencesGuessSyntax = true`
This is a breaking change.
This also includes a refactor of the hugofs package and its usage.
The motivation for that is:
The Afero filesystems are brilliant. Hugo's way of adding a dozen of global variables for the different filesystems was a mistake. In readFile (and also in some other places in Hugo today) we need a way to restrict the access inside the working dir. We could use ioutil.ReadFile and implement the path checking, checking the base path and the dots ("..") etc. But it is obviously better to use an Afero BasePathFs combined witha ReadOnlyFs. We could create a use-once-filesystem and handle the initialization ourselves, but since this is also useful to others and the initialization depends on some other global state (which would mean to create a new file system on every invocation), we might as well do it properly and encapsulate the predefined set of filesystems. This change also leads the way, if needed, to encapsulate the file systems in a struct, making it possible to have several file system sets in action at once (parallel multilanguage site building? With Moore's law and all...)
Fixes#1551
NewContent is refactored to use the afero.Fs interface that should allow
full testing. This commit also pulls the metadata creation logic out of
NewContent and into a separate function to decrease the cyclomatic
complexity of NewContent.
This uses the Emoji map from https://github.com/kyokomi/emoji -- but with a custom replacement implementation.
The built-in are fine for most use cases, but in Hugo we do care about pure speed.
The benchmarks below are skewed in Hugo's direction as the source and result is a byte slice,
Kyokomi's implementation works best with strings.
Curious: The easy-to-use `strings.Replacer` is also plenty fast.
```
BenchmarkEmojiKyokomiFprint-4 20000 86038 ns/op 33960 B/op 117 allocs/op
BenchmarkEmojiKyokomiSprint-4 20000 83252 ns/op 38232 B/op 122 allocs/op
BenchmarkEmojiStringsReplacer-4 100000 21092 ns/op 17248 B/op 25 allocs/op
BenchmarkHugoEmoji-4 500000 5728 ns/op 624 B/op 13 allocs/op
```
Fixes#1891
