Next-translate: Don't generate pages for default locale

[mxmtsk]

I've set redirectToDefaultLang to false because I want to have my default locale without language prefix in the URLs. In fact, I don't want to have my default locale callable with the language code in the URL at all.

In my opinion it's safe to assume that if redirectToDefaultLang is set to false, that a developer doesn't need generated pages for the default locale with prefix (e.g. /en/page).

If this can't be assumed from this configuration property, I would propose a new feature that makes this possible by adding a new property for it.

Steps to make it possible:

1. (Add new configuration option)
2. Don't generate pages pages in language code folder for default locale
3. Don't add language prefix for default locale when Link is used

Is this something that would be merged? If so, I can look into it and open a PR.

[aralroca]

Hi @mxmtsk,

Thank you so much for report this.

I agree that the redirectToDefaultLang set to false doesn't make sense to build the default language pages. Perhaps we can assume directly this.

Steps to make it possible:

1. (Add new configuration option)
2. Don't generate pages pages in language code folder for default locale
3. Don't add language prefix for default locale when Link is used

👍

There is no open PR for this right now. So let's go to implement this. Maybe instead of release this on 1.0.0 we can release on 0.15.0 because although it is a "breaking change", the old behavior is wrong.

As a workaround meanwhile this is not implemented, you can add something like this in your package.json:

{
  "scripts": {
    "dev": "yarn translate && next dev",
    "build": "yarn translate && next build",
    "translate": "next-translate && rm -rf pages/en"
  }
}

[davidhellsing]

+1

As long as the <Link> element redirects to the prefixed language URL, I assume that the language needs to be built anyway.

What we need besides not building the default language subpath, is the option to say that the default language should be present at the root URL / and that the Link and Router should respect that.

[aralroca]

@mxmtsk @davidhellsing This will be released on 0.15.0, but I did a pre-release under 0.15.0-canary.1 version. Can you verify that it is working in your case? 😄Thanks!

[justincy]

@aralroca I love how responsive you are. That's one of this lib's greatest strengths.

[mxmtsk]

@mxmtsk Thanks from me for the quick response as well - the update works perfect for me!

[neslinesli93]

Awesome mate, the canary version really solved an issue for me! Keep it up :heart: