An esbuild rule that ran fine in a local repo (eg bazel build //:my_esbuild_rule)
fails when built externally (eg bazel build @other_workspace//:my_esbuild_rule).
By prepending the workspace root to the bin path, the resulting base
URL works correctly in both local and remote repo invocations, allowing
esbuild output to be consumed by a different repo.
This change fixes remote repos in Bazel 4.0.0. 3.7.0 seems to require a
workspace_root.replace("external/", "") call first in order
to get the correct location. So while this patch should not break anything
that was not already broken, it only fixes/adds support for remote repos
in 4.0+.
Instead of generating a fluent.proto file with a giant enum, create
a .json file representing the translations that downstream consumers
can use for code generation.
This enables the generation of a separate method for each translation,
with a docstring that shows the actual text, and any required arguments
listed in the function signature.
The codebase is still using the old enum for now; updating it will need
to come in future commits, and the old enum will need to be kept
around, as add-ons are referencing it.
Other changes:
- move translation code into a separate crate
- store the translations on a per-file/module basis, which will allow
us to avoid sending 1000+ strings on each JS page load in the future
- drop the undocumented support for external .ftl files, that we weren't
using
- duplicate strings in translation files are now checked for at build
time
- fix i18n test failing when run outside Bazel
- drop slog dependency in i18n module
- The previous commits moved the majority of the remaining global css
into components; move the remaining @emotion/css references into
ticks.scss and the styling of the Graph.svelte. This is not as elegant
as the emotion solution, but builds a whole lot faster, and most of
our styling can be scoped to a component anyway.
- Leave the .html files in ts/ for now. AnkiMobile uses them, and
AnkiDroid likely will in the future too. In the long run we'll likely
move to loading the JS into an existing page instead of loading a
separate page, but at that point we can just exclude the .html file from
copy_files_into_group() without affecting other clients.
Closes#1074
