next-translate

[rsipakov]

Hey there! I am trying to integrate internalization for this project using the "next-translate" plugin. I understand how to translate basic pages, but I don't know how to deal with blog pages wich are use .md and .mdx formats. Can somebody help to implement this future for the blog pages?

Next.js Starter Blog + next-translate - Watch Video

[timlrx]

Can't really help since I have no experience with the package but if I were to try something, I guess the translate function would have to act on mdxSource returned at the blog page

[timlrx]

This stackoverflow post should be helpful but seem quite tedious. An alternative approach would be to have different translated markdown files in separate folders within data/blog e.g. en or ru and detect the users language and display the correct post. This is supported with our nested route approach.

[rsipakov]

Hi! Thank you for your advice. I will try with separate folders.

[GautierArcin]

Is it still under discussion ? I might be interested to also participate, I might need it for my personnal blog.

[timlrx]

Hi, no plans to include i18n into the template, but it should be reasonably easy to add next-translate and separate the markdown content in different language folders or change the parsing of the markdown slug to detect different file extensions like blog-post.en.md vs blog.post.ru.md

If anyone has it nicely setup, I will be happy to link it as an example in the readme.

[vahidtakro]

Is it still under discussion ? I might be interested to also participate, I might need it for my personnal blog.

I am also busy with this,
what I could do so far was the changes I've done to mdx.js file, nothing changed

 const {defaultlocale} = require('../i18n.json')
.
.
.
export async function getFileBySlug(type, slug, locale) {
 const filename = locale === defaultlocale ? 'index.md' : `index.${locale}.md`
 const filenameMdx = locale === defaultlocale ? 'index.mdx' : `index.${locale}.mdx`

  const mdxPath = path.join(root, 'data', type, `${slug}`, filenameMdx)
  const mdPath = path.join(root, 'data', type, `${slug}`, filename)
  const source = fs.existsSync(mdxPath)
    ? fs.readFileSync(mdxPath, 'utf8')
    : fs.readFileSync(mdPath, 'utf8')

if somebody knows what changes, and where should I change, to internationalize my markdown blog, I will be thankful, I am also using next-translate for basic titles, pages, etc. but still for markdown part, some changes need to be done in the codes.

[timlrx]

Take a look at the demo/translate branch for an example of getting i18n to work and translating the blog posts. Here's the deployed website:

• English
• French

More information in #160. Hope that helps!

[timlrx]

@GautierArcin happy to add a link in the readme to your repo when you are done. Thanks to you and @rsipakov as well for chipping in. Not sure, whether we should enable more "out of the box" support for i18n since it makes the codebase more opinionated and less flexible, but having a model reference will surely help people who are looking to achieve the same!

@vahidtakro you have to make similar adjustments to the tags page for it to work. I updated my demo/translate to patch that. Yes, this setup assumes that you have a translated blog post for each post you create. Yes, i18n is relatively tedious, since you have to translate each piece of content / text that exist.

[vahidtakro]

@GautierArcin happy to add a link in the readme to your repo when you are done. Thanks to you and @rsipakov as well for chipping in. Not sure, whether we should enable more "out of the box" support for i18n since it makes the codebase more opinionated and less flexible, but having a model reference will surely help people who are looking to achieve the same!

@vahidtakro you have to make similar adjustments to the tags page for it to work. I updated my demo/translate to patch that. Yes, this setup assumes that you have a translated blog post for each post you create. Yes, i18n is relatively tedious, since you have to translate each piece of content / text that exist.

Thanks! I see no more problem with opening tags, the problem is only tag counts, and "tag" page shows all tags in any other languages, and the number of tags are wrong, so if I write one post in two languages with same tag, it shows --tag (2)--
(for now all tags must be similar to work, I mean common tags for both languages, which is not a good logic)

also the biggest problem on this demo is second page of blog, which should be related to pages/blog/page/[page].js I think, it gets 404 when going to next pages, and author pages are not translated, (for me I could do it, with the code below, but still when I go to translated posts where authordetails are, it's not showing the translated author)
and also, when a post is only available in one language, there will be a problem, maybe there can be a md 404 default page to refer, with the posts that are not available in other language?
I think this is easy to fix, but I am not so professional to fix. maybe one of you guys can? @rsipakov @timlrx @GautierArcin

thanks.

about.js file changes:

export async function getStaticProps({ locale, filename }) {
  filename = locale === 'en' ? ['default'] : ['default.fr']
  const authorDetails = await getFileBySlug('authors', filename)
  return { props: { authorDetails } }
}

also @GautierArcin changed it like this:

export async function getStaticProps({ locale, defaultLocale }) {
  const authorDetails = await getFileBySlug('authors', [
    `default${defaultLocale !== locale ? `.${locale}` : ''}`,
  ])
  return { props: { authorDetails } }
}

[rsipakov]

Nice job adding on to my demo! Yes, I just used nextjs default i18n routing with no additional packages. But, to manage the different content for the title, menu navigation etc., it might be easier to use one of those packages you listed.

No need for a new demo branch? I don't mind merging your demo with next-translate to my demo/translate branch.

Using next-compose-plugins is probably cleaner.

Thank you for your feedback!)

[rsipakov]

Nice ! I think next-translate is indeed a good (and lightweight) choice. I tried to do the internalization of the blog with next-i18next before, and encountered some issues because of webpack version (see here).

@rsipakov I added navBar translation and translation of the About page on your branch. Live preview is here. I'm not sure about the About page though: it might be smarter to do it with SSR now. What do you think ?

I think I might begin to do the full internalization (with en and fr locales) of my blog pretty soon Thanks a lot for the help both of you provided. 😃

@GautierArcin Thank you for your feedback! ;) I tried to do with "react-intl" before too, and I believe that "next-translate" better. Also, in this case you can use for manage .json this service (Translation editor) BabelEdit

[rsipakov]

Nice ! I think next-translate is indeed a good (and lightweight) choice. I tried to do the internalization of the blog with next-i18next before, and encountered some issues because of webpack version (see here).

@rsipakov I added navBar translation and translation of the About page on your branch. Live preview is here. I'm not sure about the About page though: it might be smarter to do it with SSR now. What do you think ?

I think I might begin to do the full internalization (with en and fr locales) of my blog pretty soon Thanks a lot for the help both of you provided. 😃

@GautierArcin "I'm not sure about the About page though: it might be smarter to do it with SSR now. What do you think ?" - for this question I will back on Sunday.

[GautierArcin]

Hello everyone,

I finished a first version of the translation. Locales are en and fr. Sources branch github & Preview .

I'm not super sure about some part of my code (using imperative code instead of functional in some getStaticProps(), for example, or maybe using SSG instead of hooks, for performances). I also tried to made it as generic as possible, replacing hard-coded en-us by defaultLangage when possible.

There two kinds of behaviors:

1. You can have a fully "multi-langage" SSR blog. If there is an article article.mdx, you can put an article for each language defined in languages (for example, it would be article.fr.mdx for french and articles.mdx for english if there is [fr,en] locales & defaultLocale is en ).
2. When there is no corresponding article for the locales ( in our previous case, article.fr.mdx is missing), the blog is gonna use the defaultLocale article for the article corresponding to the missing locale. To be more explicit, in my case, I plan to write my blog in english, therefore I plan to use en as default language.

@timlrx

I think it's a good idea to just keep the branch as a demo, because my implementation is pretty opinionated.
At the same time, the second behavior might allow to just put one locale (english) and use it as defaultLocale. Therefore, for user that wants only an english blog, it would not change anything, but users that wants a blog in their langage would be able to do so in minimum time (2 to 3 hours ?)

Let me know what you think ?

(Totally unrelated, but you begun an implementation of analytics ? I'm interested in it 😅)

@vahidtakro @rsipakov It should be better, let me know what you think.

Let me know what you think / what I might have missed.

[vahidtakro]

@GautierArcin okay I just copied the repo, and added the posts. you can check now:
live version and repo

[GautierArcin]

@vahidtakro Nice find ! Indeed, there was a bug.

I fixed it on my repo. I can't change it on yours.

Replace both occurence of

 : getAllFilesRecursively(prefixPaths).filter((path) => path.includes(otherLocale))

by

 : getAllFilesRecursively(prefixPaths).filter((path) => path.includes(`.${otherLocale}.`))

in lib/mdx.js

Basically, the filter was not strict enough.

[vahidtakro]

@vahidtakro Nice find ! Indeed, there was a bug.

I fixed it on my repo. I can't change it on yours.

Replace both occurence of

 : getAllFilesRecursively(prefixPaths).filter((path) => path.includes(otherLocale))

by

 : getAllFilesRecursively(prefixPaths).filter((path) => path.includes(`.${otherLocale}.`))

in lib/mdx.js

Basically, the filter was not strict enough.

Thanks! it works very good now!
I just wonder why you added

import remarkTocHeadings from './remark-toc-headings'

in your code? It's not working for me when I include it. even after installing that package. it works perfectly without it, anyway.

[GautierArcin]

It's not me that added that line. Please check the commit history.

[vahidtakro]

@GautierArcin Thanks Gautier for the sitemap generator, do you think RSS generator and SEO.js must change too?

[rsipakov]

@GautierArcin Regarding newsletter subscription I created a new topic in discussion #177 and provided some ideas for this case on this branch demo/translate.

Also, I created discussion topic #179 for your idea with DeepL API.

[vahidtakro]

@rsipakov maybe this one for Buttondown or this one for Mailchimp ?

[GautierArcin]

Thank you a lot for both topics you created.

[rsipakov]

@rsipakov maybe this one for Buttondown or this one for Mailchimp ?

Mailchimp, See more here #177

[vahidtakro]

Anyone knows what are better commenting system alternatives?
I don't want to ask users to log into github to be able to comment, so they can easily comment just by their emails and names, with a self hosted data / google firebase database. Do you know any packages? I found one but it seems that it's not sending notifications to users when their comments are being replied.

[timlrx]

@vahidtakro, I would appreciate it if you could open a new thread for a new topic - keeps things cleaner and makes it easier for people to find similar issues. Anyway, if you had checked out the readme or the config file, you would have seen that disqus is supported out of the box. That's probably the most widely used blog commenting system and supports multiple identity providers beyond Github.

[vahidtakro]

@vahidtakro, I would appreciate it if you could open a new thread for a new topic - keeps things cleaner and makes it easier for people to find similar issues. Anyway, if you had checked out the readme or the config file, you would have seen that disqus is supported out of the box. That's probably the most widely used blog commenting system and supports multiple identity providers beyond Github.

Sure thing! thanks. I will repost it there,
Yes, I've checked Disqus, it's good , but I think it's not possible to customize? I want a more simple one. anyway I will check Disqus, to make sure, if it's not what I exactly want, I will open a new thread.

[miryamfv]

hello, this is exactly what I need, has anyone tried using Tina CMS with this template? I did but got the error: npm ERR! Failed at the [email protected] dev script. any ideas?