-
Notifications
You must be signed in to change notification settings - Fork 2.5k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Idea: Internationalization support #202
Comments
I just wanted to mention that I really hope that no matter what is built into remix will not be tightly linked to |
Just in case, I don’t want Remix to bundle i18next specifically, I used it but if it can work with any other lib would be great, or if has a built-in lib so there’s no need to add anything else. |
Internationalized Routing just works. ref |
just a ref to look into |
Hey ! I've done this experiment with these requirements in mind :
I think this is important to consider if remix provides something built-in. Language detection and routing should be customizable too I think. |
I was looking into this as well. I was having a hard time translating my meta tags as they got translated back into the fallback language upon hydration. Turns out the Digging into the Remix's source code, turns out the route's
|
@olavoasantos what I do is to get the title inside the loader, and return it as data, then read the data inside the meta function |
Hum... That's less bad than my hack I think haha |
@olavoasantos if you make the language switch submit a form (it should) then all loaders are going to be reloaded after the submit automatically so you don't lose the benefit. |
Makes sense. Thanks for the help! |
I hope this idea to go into reality. I do love remix and am ready for Korean translation! |
I just want to add a few things that I think are very important to consider if a Link, useNavigate, and redirect should support the
|
I would be amazing if Remix could allow routes to be marked as "English / default language only". I have always missed that feature in other frameworks. It would allow devs to translate applications gradually and to keep In
Remix then should remove the Not sure if there are any major downsides to this (apart from a lot of work obviously) but the feature would be really helpful, I think! |
I for myself prefer to add the language prefix to all, including the default/fallback, languages, although I know many don't like or do it that way, I prefer this ever since reading some Google Developers content on i18n or something, stating that it's not necessary but recommended for consistency and clarity, though can't find the page right now 😳😴 At the moment I'm doing i18n manually, tho so far I've got only english content 😅 (https://www.canrau.com) |
Some recent projects out there with
Neither happens to be based on
That would be awesome! What I haven't seen implemented in Remix yet is domain routing (like mysite.fr setting the language accordingly), but it wouldn't be far from those examples. Remix is uniquely suited for stuff like this. |
I think you can use the request.url to detect the domain and get the correct locale based on that |
That would be great to have a way to create routes like
And we would have to be able to set/detect a locale from request URL,domain, headers, (or whatever else) too:
I would have loved to try Remix over Next.js for a project, but the fact that routes can not be translated or associated/restricted to a locale 😭 Or maybe there is a way not simplified/config by Remix, but I did not get how to do it with custom code/config? 🤔 |
I'm doing `routes/$lang/$slug.tsx` for example then I get the lang from
params which I verify to be one of the supported languages and if it isn't
redirect to default (or something not exactly sure right now about the
logic) but you can check at https://github.com/CanRau/canrau.com
Also `routes/index.ts` redirects to default lang but I might add some
language detection in the future.
|
As someone who has used both i18next and lingui, I'd like to give a shoutout to lingui. They let you write your strings inline with React components, including pluralization, and then it extracts ICU strings for you so you don't have to know that syntax yourself. Unfortunately, it's based on Babel Macros, so if it were to be supported in Remix it would be through something like https://github.com/nativew/esbuild-plugin-babel (though I don't know if one must use the macro, possibly worth looking into or otherwise asking). |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
I have been playing with i18next to add i18n to a Remix app, I was able to make it work but there are a few things which are missing or Remix could help solve better.
/:locale
prefix automatically or change the whole URL based on the language) (missing)Loading localized strings
The approach I used to load the localized strings for React i18next was to detect the language the user wants based on the request and then read a JSON from disk, to detect the language I used the following approach:
?lng=:locale
I use thati18next
I use thataccept-language
header I use thatOnce I got the locale from query/cookie/header/default I use the package
accept-language-parser
to set an array of supported languages and check if the user expected language is there, and default again to English if it's not. This means if the browser accept-language comes withes
anden
and I only support English it will default to English.Then in
entry.server
I run this function to get the language and read the JSON from disk, the JSON is onpublic/locales/:locale.json
.Client-side, in
entry.client
I initialize i18next using thei18next-browser-languagedetector
plugins which will use the same approach to get the user preferred language and the plugini18next-http-backend
to load the locale from/locales/:locale.json
(this is why I put it on the public folder), once i18next has initialized I run the ReactDOM.hydrate function.I need to wait for i18next to finish so the app will render with the correct language and not using the default while it finish to initialize, detect the language and load the locales.
If Remix have a built-in way to do i18n I would be able to remove a lot of code here, I would expect Remix to see what locales JSON files I have in a folder at the build time and then use a similar approach to what I did to know what locale to load. So a localized Remix app would have this folder structure:
Another option, would be to allow routes to define how to get the locales based on the request, this will be great to avoid loading locales I don't really need but it could mean I have to see how to ask only for those loaders and not just load everything and duplicate all the messages.
Then Remix could call this along the loader, the result (of both approaches) could be passed to the meta function and to the component of the route (in a context), inside that component we could use something like this:
Route meta
The title and meta:description of a route should be localized too, with the approach I'm using I can't do it because I only have access to the translations in the view, I would have to load the translations again in every loader to pass them to the meta function.
If Remix automatically loads the locales it could inject it to the route meta function, this could work in a per page or global (all locales in a single file) approach.
URLs
Another things that Remix could support is to add a prefix to all the URLs of the app based on the language, so the
app/routes
folder could be like this:And Remix could generate the routes:
And basically add the locale before every route, then use that to detect the locale of the user, if the user access without that locale (e.g.
/about
) it could use the default language (defined in remix.config.js) and we could handle a redirect to the locale specific or not.Another thing Remix could allow is to enable translate the pathnames, so
/about
becomes/sobre-mi
in Spanish.The text was updated successfully, but these errors were encountered: