Feat: enable i18n

[sansx]

Enable i18n, once it merged we'll update Chinese version ASAP

1. The preview website is hosted in Vervel, we are using yarn build to generate files, cuz in nextjs i18n support is not compatible with next export. See here for more info on deploying: https://nextjs.org/docs/messages/export-no-custom-routes

2. The framework throws this error during the build: Build optimization failed: found pages without a React Component as default export. To resolve this, we need to change _meta.js to _meta.json. I checked the Nextra repository, and they are also using _meta.json. Once this feature is supported, we will switch back to JS files.

preview:
https://tact-docs-git-full-zh-example-townsquarexyz.vercel.app

[novusnota]

Left a couple of comments to resolve.

Also, the error in the tests is different from what you're describing. It's i18n support is not compatible with next export. — the very error that happens when using next export with i18n mode on. I've came across that error before, and it didn't seem to resolve unless one goes from static page generation to dynamic one with a web server. And that's unacceptable for our docs. Please, prove me wrong and fix that :)

P.S.:
My way to circumvent that was to come up with multiple builds, each without i18n enabled and targeting the pages in specific language as if the docs were written only in that language. After the build, the resulting pages would be merged in out/ under their language prefix, out/zh-CN for example, without adding the prefix to English docs. Finally, there would be a simple button switch in the UI, which would take the user to the correct prefix based on the language picked.

[sansx]

Left a couple of comments to resolve.

Also, the error in the tests is different from what you're describing. It's i18n support is not compatible with next export. — the very error that happens when using next export with i18n mode on. I've came across that error before, and it didn't seem to resolve unless one goes from static page generation to dynamic one with a web server. And that's unacceptable for our docs. Please, prove me wrong and fix that :)

P.S.: My way to circumvent that was to come up with multiple builds, each without i18n enabled and targeting the pages in specific language as if the docs were written only in that language. After the build, the resulting pages would be merged in out/ under their language prefix, out/zh-CN for example, without adding the prefix to English docs. Finally, there would be a simple button switch in the UI, which would take the user to the correct prefix based on the language picked.

Hey! thanks for the comments, and yeah, we're not using next export, according to docs in nextjs:
https://nextjs.org/docs/pages/building-your-application/routing/internationalization#how-does-this-work-with-static-generation

And nextra docs itself: https://github.com/shuding/nextra/blob/main/docs/next.config.mjs

Seems it's not that recommended to use next export in i18n. Of course, you provide a nice way to make it but we might also encounter some issues when we're making that static version.

Can I have more details about why we can't let docs work with dynamic routes, we can also discuss how to fix it in current mode, cuz it looks fine in the preview:
https://tact-docs-git-full-zh-example-townsquarexyz.vercel.app/

[novusnota]

Thanks for all your effort on this PR!

Recently, we've moved the docs from Nextra to Starlight, which means that they have i18n out of the box — one only needs to translate indivudual .mdx files per page to get everything (including menu items) translated and ready right away!

Also, this repo is slowly being archived now, because the docs were actually moved to the compiler repo, see docs/ folder in tact-lang/tact. That's done to be able to introduce quick additions to the docs as soon as the new features get developed :)

I'll close this PR now. To contribute translations, see tact-lang/tact#934 and make new PRs towards it (i.e. instead of Closes #934, if the PR doesn't cover all the pages at once, it should write Towards #934)

Once again, major props to you for pushing i18n issues further, that helped get unstuck :)