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

HTML "lang" attribute support #133

Closed
neslinesli93 opened this issue Apr 25, 2020 · 6 comments · Fixed by #137
Closed

HTML "lang" attribute support #133

neslinesli93 opened this issue Apr 25, 2020 · 6 comments · Fixed by #137

Comments

@neslinesli93
Copy link

Hi,
is it possible to set a custom lang attribute for the html tag inside a custom _document.js, while keeping static site generation support? I think it could be fairly easy to inject it at build time in the generated html...

@aralroca
Copy link
Owner

There isn't any helper of this library right now for this. (Maybe we can consider to add it 🙂).

Meanwhile, you can handle this with this:

import Document, { Html, Head, Main, NextScript } from 'next/document'
import i18nConfig from '../i18n.json'

function documentLang({ __NEXT_DATA__}) {
  const { page } = __NEXT_DATA__
  const [,langQuery] = page.split('/')
  const lang = i18nConfig.allLanguages.find(l => l === langQuery)

  return lang || i18nConfig.defaultLanguage
}

export default class MyDocument extends Document {
  render() {
    return (
      <Html lang={documentLang(this.props)}>
        <Head />
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    )
  }
}

@neslinesli93
Copy link
Author

Thanks for the quick feedback. I was wondering, why it's not possible to use clientSideLang? It seems easier and more straightforward...

@aralroca
Copy link
Owner

The reason is that clientSideLang is a global variable. In the browser this is not a problem but in node.js it can have conflicts with concurrent users visiting the same page.

@neslinesli93
Copy link
Author

I'm exporting the next project using static html, so it shouldn't be an issue for this use case. Thanks anyway!

@aralroca
Copy link
Owner

In this case, is not a problem and you can use clientSideLang directly.

However, using SSR on some page (getServerSideProps) you can have conflicts and the only way is using documentLang, that this works in all cases.

@aralroca
Copy link
Owner

@neslinesli93 on 0.17.0-canary.1 is available the helper:

import Document, { Html, Head, Main, NextScript } from 'next/document'
import documentLang from 'next-translate/documentLang'

export default class MyDocument extends Document {
  render() {
    return (
      <Html lang={documentLang(this.props)}>
        <Head />
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    )
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants