Localization Support
This pull request adds support to localize the modpack as a part of the build process. It uses Github Actions and a localization JSON file to replace strings within the source code with their localized counterparts.
Additional languages can be added by creating a JSON file with translations within the locales/ directory, then editing the .github/workflows/rust.yml workflow file to accommodate the new language.
The JSON file must follow the specific format that's provided by en_US.json: an array of maps with the "find" key representing the original text within the source code and the "replace" key representing the localized text. Each of those entries MUST include an escaped leading quotation and an escaped trailing quotation. Any strings not included within this file will not be localized.
[
{
"find": "\"1-Winged Angel\"",
"replace": "\"1-翼の天使\""
},
{
"find": "\"Aerial Delay: How long to delay a Mash aerial attack\"",
"replace": "\"空中ディレイ: マッシュの空中攻撃のディレイ時間\""
}
]
The rust.yml file needs to have the following modifications. I'll use the en_US_lowercase language as an example.
- Add a new job which clones the
plugin_en_USjob, changes theLANGenvironment variable, and changes the plugin name:
...
plugin_en_US_lowercase:
name: Plugin NRO (en_US_lowercase)
runs-on: ubuntu-latest
env:
LANG: en_US_lowercase
steps:
- uses: actions/checkout@v4
- uses: dtolnay/rust-toolchain@nightly
...
- Change the
uploadjob, adding a dependency on the new job
...
upload:
name: Upload Beta Release
permissions: write-all
runs-on: ubuntu-latest
env:
RELEASE_DIR: release
SMASH_PLUGIN_DIR: atmosphere/contents/01006A800016E000/romfs/skyline/plugins
if: github.ref == 'refs/heads/main'
needs:
- plugin_en_US
- plugin_en_US_lowercase
steps:
- uses: actions/checkout@v4
...
- Add a new step to the
uploadjob which clones thePrepare zip (en_US)step with an updatedLANGenvironment variable
- name: Prepare zip (en_US)
env:
LANG: en_US
run: |
rm -f ${{env.SMASH_PLUGIN_DIR}}/libtraining_modpack*.nro
cp plugin-${{env.LANG}}/libtraining_modpack_${{env.LANG}}.nro ${{env.SMASH_PLUGIN_DIR}}/libtraining_modpack_${{env.LANG}}.nro
zip -r training_modpack_beta_${{env.LANG}}.zip atmosphere
mv training_modpack_beta_${{env.LANG}}.zip ${{env.RELEASE_DIR}}
- name: Prepare zip (en_US_lowercase)
env:
SMASH_PLUGIN_DIR: atmosphere/contents/01006A800016E000/romfs/skyline/plugins
LANG: en_US_lowercase
run: |
rm -f ${{env.SMASH_PLUGIN_DIR}}/libtraining_modpack*.nro
cp plugin-${{env.LANG}}/libtraining_modpack_${{env.LANG}}.nro ${{env.SMASH_PLUGIN_DIR}}/libtraining_modpack_${{env.LANG}}.nro
zip -r training_modpack_beta_${{env.LANG}}.zip atmosphere
mv training_modpack_beta_${{env.LANG}}.zip ${{env.RELEASE_DIR}}
...
- Add the new file name to the
Update Releasestep
...
- name: Update Release
uses: meeDamian/[email protected]
with:
token: ${{ secrets.GITHUB_TOKEN }}
prerelease: true
allow_override: true
gzip: false
files: |
release/training_modpack_beta_en_US.zip
release/training_modpack_beta_en_US_lowercase.zip
tag: beta
commitish: main
name: beta
...
Once complete, the new beta build will have an additional asset which includes a compiled binary for the new language. The installation process remains the same as before, with a simple unzip and drag+drop.
Several deprecated Github Actions were also updated in this pull request. I think some older node.js actions will stop working later this year.
I have a couple things I wanna call out here. I figured this might be a good place to do it instead of on discord.
I think we can probably handroll the replacements pretty easily with sed + jq or some other sumple bash scripting. The array syntax for the locale is pretty rough imo and it would be better if we could use key/value (text/translation) syntax i.e. "1-Winged Angel": ""1-翼の天使".
The other thing I wanna call out is that we can natively in Github actions run a job/step multiple times with a permutation. I can pull up an example for this later. This would allow us to simply run the job/step per localization without having to dupe the job.
I'd love to hear everyone else's thoughts on this. But we can discuss it more in depth at a better time.
How does adding a new nro interact with auto-update? Ideally the modpack would automatically identify the correct nro, but I'm not sure if that's feasible. I don't think we can solely rely on filenames, since they're bound to be changed anytime by the end user
EDIT: never mind I just read step 4
I hadn't thought about the auto updater...good catch. Will need to adjust things in code to grab the right asset.
Closing as won't do, probably the i18n solution is better.