Make all components with English text functional client components

[danielhjacobs]

This unlocks client-side translations (#358) and will be necessary whether we use next-export-i18n or custom translation code. I feel like no one wants to accept #358 yet, but doing this first can make the commits there a lot cleaner.

[danielhjacobs]

Why this will be needed:

Assuming we want to keep serving the website client-side, the website language needs to be checked client-side in order to apply translations. That means changing the language needs to, in some way, be done by JavaScript. next-export-i18n has two ways to do that: check the window.location.search or window.localStorage, and as window is only available client-side, either way it will only work on client components. Therefore, every component with English text (including the header and footer) needs to be a client component.

[danielhjacobs]

For a draft with translations that build upon this, see danielhjacobs#4

[torokati44]

Since the current website was mostly your work originally, do you think you could spare some minutes to review this, @Dinnerbone? Only if your time and energy allows it, of course!

[danielhjacobs]

Of note is there's something, previously discussed on Discord, that should probably be done to improve the performance of this, specifically when it comes to the compatibility and AVM2 compatibility pages. Namely, the avm2-report should be copied to the website's static files folder (https://github.com/ruffle-rs/ruffle-rs.github.io/tree/master/public) in a pre-build step, instead of using the new fetch-report route.

The two places with const reportReq = await fetch("/compatibility/fetch-report"); can then const reportReq = await fetch("/avm2-report.json"); instead.

Edit: Done

[Dinnerbone]

I can't build this 🤔 Does it change our node version requirement or something else?

❯ npm run build

> [email protected] prebuild
> node scripts/fetch-ruffle-report.js

scripts\fetch-ruffle-report.js:4
const { Octokit } = require("octokit");
                    ^

Error [ERR_REQUIRE_ESM]: require() of ES Module node_modules\octokit\dist-bundle\index.js from scripts\fetch-ruffle-report.js not supported.
Instead change the require of index.js in scripts\fetch-ruffle-report.js to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (scripts\fetch-ruffle-report.js:4:21) {
  code: 'ERR_REQUIRE_ESM'
}

Node.js v20.13.1

Edit: Updating to node 22 worked :D

[danielhjacobs]

Weird, I'm on Node 20.19.0 and it worked fine. I can switch to import modules but I thought node scripts/fetch-ruffle-report.js would be more likely to fail with those.

[danielhjacobs]

Switched to ESM, it works but resulted in this error:

(node:2984436) [MODULE_TYPELESS_PACKAGE_JSON] Warning: Module type of file:///home/dj/work/rust/ruffle_website/ruffle-rs.github.io/scripts/fetch-ruffle-report.js is not specified and it doesn't parse as CommonJS.
Reparsing as ES module because module syntax was detected. This incurs a performance overhead.
To eliminate this warning, add "type": "module" to /home/dj/work/rust/ruffle_website/ruffle-rs.github.io/package.json.
(Use `node --trace-warnings ...` to show where the warning was created)

[Dinnerbone]

I'm fine with keeping it 22+ only, the method you had was okay, was just surprised.

No need to support anything older than "current LTS" for website, I think.

[Dinnerbone]

Regarding the PR itself: I'm a little concerned about making everything client only though, that just increases load times and makes it harder for tools to scrape us. Is it truly necessary?

[danielhjacobs]

We want to translate, and I know you've previously expressed a possible desire to host the website not on GitHub pages, but most of the other people who've weighted in say they wouldn't want to move off of GitHub pages just for this. GitHub pages uses a static website, which is why we use next export. The only internationalization I've found for that is next-export-i18n: https://www.npmjs.com/package/next-export-i18n#user-content-the-usecase-for-next-export-i18n.

In general, translations on a static site will have to use either the path, the query string, or, my preferred version, localStorage.

[danielhjacobs]

martinkr/next-export-i18n#7