Next-translate: Aslo wrap _app.js with I18nProvider

[BjoernRave]

In my _app file I am using a Layout component for persistent layout. The items in the layout do not get translated.

Is it maybe possible to apply the same to _app.js as you do to all other files?

[aralroca]

Right now we were just skipping the translation of _app.js, _document.js and _error.js.

However, yes, it's interesting to translate it... We need to study first how to do it well, because in case of _document for example it extends of Document, and _app.js can extend from App. And these cases need a different approach than pages.

I'm going to investigate and try to solve this issue during the next week. Thanks again to report it.

[BjoernRave]

@aralroca thanks, alot, cant wait on this, to finally replace my old lib with this :)

Also I am using a functional component in my _app.tsx, so it shouldn't be a big deal, but yeah a lot of people probably still extend from App

[aralroca]

@BjoernRave I need more time to investigate how to do it well. I started to work with that and I found more difficulties than I was expecting.

Unfortunately, today I'm going to release the 0.7.0 without this change. I hope that it will be released on 0.8.0.

Meanwhile, as an alternative maybe you can just wrap every page with the <Layout>?

[BjoernRave]

@aralroca okay, yea I already imagined, that it's probably not that easy with the current structure, because you can't just do a es/_app.tsx

Appreciate your effort nevertheless.

Meanwhile, as an alternative maybe you can just wrap every page with the ?

Yea I think I will just do that.

Also I was wondering if it isn't possible to just wrap _app.tsx with the I18nProvider. That way all components should receive their translations and doing the code transformation is not neccessary anymore. Just need a way to identify the current language and remove the language subpath from the url

[aralroca]

As an alternative to translate the _error page, can be used the DynamicNamspaces component:

• https://github.com/vinissimus/next-translate#dynamicnamespaces

However, I understand that for _app is better to provide some better alternative...

Also I was wondering if it isn't possible to just wrap _app.tsx with the I18nProvider. That way all components should receive their translations and doing the code transformation is not neccessary anymore. Just need a way to identify the current language and remove the language subpath from the url

I tried to wrap the app with I18nProvider and I get some troubles. Now I'm going to try it in a different way:

if _app is detected in the project and it's a function... _(For an extended class of App will be not supported, adding in the docs)_... Then, wrap every component with the app content:

import I18nProvider from 'next-translate/I18nProvider'
import React from 'react'
import C from '../../pages_'
import ns0 from '../../locales/en/common.json'
import ns1 from '../../locales/en/home.json'

const namespaces = { 'common': ns0, 'home': ns1 }

function App({ pageProps, Component }){
  // Here the _app code
}

export default function Page(p){
  return (
    <I18nProvider lang="en" namespaces={namespaces} >
      <App pageProps={p} Component={C} >
    </I18nProvider>
  )
}

I don't know if this way is feasible yet and how to move all the imports used inside the _app, and I want to study the pros and cons... but I think it should work... Except if you use a getInitialProps on the app... But in that case, appWithI18n is better alternative.

[aralroca]

Or perhaps in order to don't move all the _app imports and copy the App code in every component, we can just move the _app file to another place, or just rename it, and then just import it in every component...

[justincy]

Or perhaps in order to don't move all the _app imports and copy the App code in every component, we can just move the _app file to another place, or just rename it, and then just import it in every component...

👍 That's a good idea.

[aralroca]

I'm going to do a POC soon, I guess is feasible. Just I need time 😛

[OmarZeidan]

👍 For supporting this! I think will be a huge step and a great help.

[borispoehland]

Would also love to see Layout supporting translations

[PwnMonkey13]

Hi guys !
I recently went to i18n and I'm trying many libs includind this one
It looks very promising...
Good job :)

That's said, I quickly faced this issue when I tried to add a locales dropdown component into my navbar (btw in my Layout called in _app)

I read discussion and understand that isn't that easy..
So in aim to get my local, I tried using appwithi18n which is a serious temporary solution, and I faced another issue :

appWithI18n.js
function getLang (ctx, config) { const { req, asPath = '' } = ctx; if (req) return req.query.lang || config.defaultLanguage;

req.query.lang failed when no query exists

Would you like a PR for this ??

And do you have any news since last answer ?

TY

[aralroca]

@PwnMonkey13 feel free to PR to fix this 😊

About this issue; Is possible to get the language from the pathname (or default language if the pathname doesn't have it), in a similar way than documentLang does. However, getting the locales from the language is not so easy. It can be achieved using DynamicNamespaces... But not on prerender, unless you use getInitialProps, but is not recommended...

[mxmtsk]

Hi @aralroca what's the current status on this one? This is a serious blocker for us, because we don't want to rerender our Layout component on every page view. 😕

Can we help somehow in testing or getting the POC done?

[aralroca]

@mxmtsk This is still blocked for now. There's no good solution at the moment, or I won't be approached. If anyone has any ideas.

In all the pages, when we put them under the language as /en/somepage.js or /es/somepage.js it is easy to know which language the page has so we can just import the necessary namespaces for the current language.

The problem with app.js is that since it has to be in the root, it is not easy to do these imports. Because the same file works for all languages... So: either you make a dynamic import, or you import the namespaces with all the languages. And neither of the two convinces me...

[crash7]

Just tried the dynamic namespaces today and the problem that I see when wrapping the _app with the I18nProvider is that it breaks when I navigate from a page with a language en to a page that has a es, because it displays everything with en.
I'm currently using getInitialProps (because I have other things there) to return the lang/namespace.

If I refresh, the language changes, the problem is with client side navigation between languages.

[aralroca]

Closing this. Already implemented on 1.0.0-canary.1. The 1.0 will be released approximately 1-2 weeks. 😊