Skip to content
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

How to get astro-i18next to work in React Components inside Astro #46

Closed
bobcafedev opened this issue Sep 30, 2022 · 6 comments
Closed
Labels
enhancement New feature or request released on @beta

Comments

@bobcafedev
Copy link

What works inside .astro components doesn't in React components (.tsx) in SSR mode.
Is there any plan to make it work ? or some work around ?

@yassinedoghri
Copy link
Owner

yassinedoghri commented Oct 1, 2022

Hey, thanks for the issue. I've setup an example for react using the react-i18next plugin.

Here's the stackblitz: https://stackblitz.com/edit/github-xdzdkv?file=src/components/Counter.tsx

It doesn't work because i18next is only initialized server side.

Getting these errors:
image

So when using the client:visible directive, the react component cannot locate the translation string. astro-i18next may need to load i18next both on client and server side.

@selemessaied
Copy link

astro-i18next may need to load i18next both on client and server side.

Any ideas on how to achieve this?

@riolly
Copy link

riolly commented Oct 5, 2022

And also, what about other frameworks like solidjs etc?

@yassinedoghri
Copy link
Owner

Any ideas on how to achieve this?

I've started implementing client side translations, I've created some example folders on the develop branch (including react). Trying things out for now.

And also, what about other frameworks like solidjs etc?

I think my experimenting with react will solve the same issues for other frameworks. Basically, frameworks render client side js, so the i18next instance should exist client side as well to retrieve translation keys.

It's not ideal to have all translations handled client side in my opinion because it would hurt SEO. So I'll have to think of ways to make SSR and client side rendering work together for i18n.

I have some questions that need more investigating:

  • Would SSR and client side i18next instances share the same config? Same plugins?
  • Should they both load the same translation keys? (some keys are likely to be used only on SSR, and others for client side)

Anyways, thank you for your interest. If you have any insight, I'm all ears!

@riolly
Copy link

riolly commented Oct 7, 2022

On astro docs website, they create dedicated pages for each translation (using md files). Only the UI part that using the translation key. And I will follow that convention.

yassinedoghri added a commit that referenced this issue Oct 30, 2022
…side

- update config naming
- abstract i18next config + make it overridable for server and client
  configs
- fix route translations to discard page extensions
- update README to account for new route features and easier setup
- add i18next-fs-backend, i18next-http-backend and
  i18next-browser-languagedetector packages to abstract locales
  detection and loading
- automatically require react-i18next when @astrojs/react integration
  is installed

BREAKING CHANGE:
- defaultLanguage is now defaultLocale
- supportedLanguages is now locales
- i18next config is now split into two configs: `i18nextServer`
and `i18nextClient`

fixes #57, closes #46, #37
@yassinedoghri yassinedoghri added the enhancement New feature or request label Nov 6, 2022
yassinedoghri added a commit that referenced this issue Nov 6, 2022
…side

- update config naming
- abstract i18next config + make it overridable for server and client
  configs
- fix route translations to discard page extensions
- update README to account for new route features and easier setup
- add i18next-fs-backend, i18next-http-backend and
  i18next-browser-languagedetector packages to abstract locales
  detection and loading
- automatically require react-i18next when @astrojs/react integration
  is installed

BREAKING CHANGE:
- defaultLanguage is now defaultLocale
- supportedLanguages is now locales
- i18next config is now split into two configs: `i18nextServer`
and `i18nextClient`

fixes #57, closes #46, #37
yassinedoghri pushed a commit that referenced this issue Nov 6, 2022
# [1.0.0-beta.13](v1.0.0-beta.12...v1.0.0-beta.13) (2022-11-06)

### Bug Fixes

* add isFileHidden function + tests to prevent missing hidden files ([7dcd0aa](7dcd0aa))
* **generate:** replace isLocale check with user defined locales to prevent nested folders generation ([a598e2e](a598e2e)), closes [#56](#56)
* **i18next-server:** load locale files synchronously ([e7892e2](e7892e2))
* update types import to relative ([#58](#58)) ([44a5422](44a5422))

### Features

* add option to show the default locale in the url ([#51](#51)) ([ea939db](ea939db)), closes [#54](#54)
* add support for route translations ([db5200b](db5200b)), closes [#50](#50) [#29](#29)
* allow implicit key for <Trans> when omitting i18nKey prop ([ff14354](ff14354)), closes [#53](#53)
* simplified API + instanciate i18next both in server and client side ([ed44510](ed44510)), closes [#57](#57) [#46](#46) [#37](#37)

### BREAKING CHANGES

* - defaultLanguage is now defaultLocale
- supportedLanguages is now locales
- i18next config is now split into two configs: `i18nextServer`
and `i18nextClient`
@github-actions
Copy link

github-actions bot commented Nov 6, 2022

🎉 This issue has been resolved in version 1.0.0-beta.13 🎉

The release is available on:

Your semantic-release bot 📦🚀

AliLee0923 pushed a commit to AliLee0923/astro-i18N that referenced this issue Dec 2, 2023
# [1.0.0-beta.13](yassinedoghri/astro-i18next@v1.0.0-beta.12...v1.0.0-beta.13) (2022-11-06)

### Bug Fixes

* add isFileHidden function + tests to prevent missing hidden files ([7dcd0aa](yassinedoghri/astro-i18next@7dcd0aa))
* **generate:** replace isLocale check with user defined locales to prevent nested folders generation ([a598e2e](yassinedoghri/astro-i18next@a598e2e)), closes [#56](yassinedoghri/astro-i18next#56)
* **i18next-server:** load locale files synchronously ([e7892e2](yassinedoghri/astro-i18next@e7892e2))
* update types import to relative ([#58](yassinedoghri/astro-i18next#58)) ([44a5422](yassinedoghri/astro-i18next@44a5422))

### Features

* add option to show the default locale in the url ([#51](yassinedoghri/astro-i18next#51)) ([ea939db](yassinedoghri/astro-i18next@ea939db)), closes [#54](yassinedoghri/astro-i18next#54)
* add support for route translations ([db5200b](yassinedoghri/astro-i18next@db5200b)), closes [#50](yassinedoghri/astro-i18next#50) [#29](yassinedoghri/astro-i18next#29)
* allow implicit key for <Trans> when omitting i18nKey prop ([ff14354](yassinedoghri/astro-i18next@ff14354)), closes [#53](yassinedoghri/astro-i18next#53)
* simplified API + instanciate i18next both in server and client side ([ed44510](yassinedoghri/astro-i18next@ed44510)), closes [#57](yassinedoghri/astro-i18next#57) [#46](yassinedoghri/astro-i18next#46) [#37](yassinedoghri/astro-i18next#37)

### BREAKING CHANGES

* - defaultLanguage is now defaultLocale
- supportedLanguages is now locales
- i18next config is now split into two configs: `i18nextServer`
and `i18nextClient`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request released on @beta
Projects
None yet
Development

No branches or pull requests

4 participants