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)
No one really understood what they meant.
Also, please stop removing chekoopa's localizer package from
dependencies. It keeps coming back when I make dev.
This weird hack did that:
* Contained two packages in one folder (main and tools)
* Imported two commands, which is illegal in Go
It seems that the hack ensured that the go generate dependencies were installed. Well, why should that be ensured?
It's not actually needed for the program itself. It's needed for the
generation, and it doesn't matter if you install it using go get or not;
you need to install it manually using go install.
It allows for interactive creation of admin account from the terminal
for new wikis. Because we have a chicken-and-egg problem here with the
user panel -- you need an admin account to appoint someone as an admin,
right?
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).
