Fix types + improve config loader #893
Conversation
| @@ -50,11 +51,10 @@ export default function nextTranslate(nextConfig: any = {}) { | |||
| ...nextConfig, | |||
| i18n: { | |||
| ...i18n, | |||
| ...restI18n, | |||
There was a problem hiding this comment.
this should not be deleted. What should be done is to remove the restI18n properties that are next-translate properties and not i18n properties. That is, make sure that everything in restI18n are properties of i18n's Next.js.
There was a problem hiding this comment.
this should not be deleted. What should be done is to remove the restI18n properties that are next-translate properties and not i18n properties. That is, make sure that everything in restI18n are properties of i18n's Next.js.
restI18n has no properties that are valid for Next.js. locales & defaultLocale are added seperately afterwards, domains & localeDetection are not used by next-translate and will be within the i18n spread (not restI18n).
There was a problem hiding this comment.
Many people use the i18n.js file to put all the features of Next-translate and Next.js, to have it together in one place.
For example localeDetection: false, or domains. https://nextjs.org/docs/advanced-features/i18n-routing
The thing is that here we should remove the Next-translate ones so that only the Next.js ones are passed.
There was a problem hiding this comment.
I see now. Never realised that next.js properties could be declared in next-translate instead, even though the plugin has no use for them. I'll update the PR soon enough.
|
@all-contributors please add @Dragate for code |
|
I've put up a pull request to add @Dragate! 🎉 |
|
@Dragate I prereleased 1.6.0-canary.1 with your changes. |
NextConfig,I18nConfigtypespagesInDirtoI18nConfigtype