-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate lang files at build time #174
base: main
Are you sure you want to change the base?
Generate lang files at build time #174
Conversation
In preparation for it also handling other data
3d0e514
to
dfd255f
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Modularise the tasks in preparation for adding more, and do some general cleanup: - Drop special jar names - Force ide to recognise `platform` & `variant` as `String`s - Split metadata & jar tasks
dfd255f
to
e99d931
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ModNameProcessor
& ModDescriptionProcessor
are implemented almost identically.
The only difference is how ModMenu's "summary" is handled, which assumes the summary should be the description without any variant-specific suffix.
We may prefer having separate long_description
and short_description
down the line?
There's probably a way to generalise them into a single implementation, but as I'm new to kotlin I'm not spending time designing that for the sake of two functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe some kinda factory or builder would help here?
- Move lang files from `:common` to `:data` - Build them using a new `LangTask` Gradle task type 👀 - Update Crowdin config - Removed Crowdin `languages_mapping` 😃 `LangTask` is used to build/process i18n lang files, allowing for more control over what is included and how.
Introduce `VariantTooltipProcessor`, which `LangTask`s use to process `VariantTooltip`s. This allows the runtime implementation to be greatly simplified, it now only handles differences in line `count`.
Move name & description definition from `gradle.properties` to a lang file in `:data`. Introduce `ModNameProcessor` & `ModDescriptionProcessor`, along with a new method `LangTask.getTranslation()` which can be used to get a specific translation after the task has finished running. Make use of this in `:data` to get the name & description from the translations into the mod metadata file. Fixes MinecraftFreecam#172
e99d931
to
754bae1
Compare
Added some basic unit tests for the |
754bae1
to
6e67fbb
Compare
Dropped the forge mixin for now, hopefully we'll get a proper upstream solution. |
Neoforge has added support in
I've also been thinking about better ways to approach the transformer funcs and "variant" translations, at risk of making this even more over-engineered. |
:metadata
into a more general:data
projectVariantTooltip
logic to the gradle task.properties
(not planned)main
&config
(low priority?)LangTask
LangProcessor
implementationsFixes #172