It's funny how despite all those tricky tricks made previously, manual changes to the version number are still to be made. Do we really need those tricky tricks though?
All the remaining QTPL files were spread across the codebase. The plan is to get rid of them step by step and migrate to the new l10n approach, all based on Go std templates.
This has several advantages over using an external CLI tool to generate
the files, such as having fewer dependencies, less generated files bloat
and more flexibility over the localization code. "Sadly", this solution
doesn't check for validity of JSON files at compile-time (the only
advantage of using an external tool such as go-localize). However, I
easily fixed this huge "issue" by making the program crash at startup if
any locale files are invalid.
Also, no more "go-localize removed from go.mod" "go-localize added to
go.mod" "go-localize removed from go.mod" spam. A utility for making
sure all translation stay in sync soon! (not sure where to put it)
It allows for more control and things like listening on Unix sockets or
binding to 127.0.0.1 rather than 0.0.0.0.
Config changes:
- "Port = 1737" changed to "ListenAddr = 127.0.0.1:1737"
- new env variable LISTEN_ADDR
My view on this: it's too restrictive for Gemini. If you want to host
something in Gemini, you can't just dumb your content down. And
Mycomarkup is too robust for Gemini—images, tables and inline formatting
can't really be adapted to Gemtext.
assets.qtpl is no more! Now you can just add files to static/ folder,
make sure the extension is registered in static.go (a shortcoming
that'll be addressed in future Go versions), and you're done! It
searches the local file system first, then falls back to the files
embedded with the binary (in the static/ folder).
