search

s00d / nuxt-i18n-micro

Nuxt I18n Micro is a fast, simple, and lightweight internationalization (i18n) module for Nuxt
https://s00d.github.io/nuxt-i18n-micro/
MIT License
87 stars 11 forks source link

Generating more routes than the ones needed #51

Closed Rigo-m closed 4 weeks ago

Rigo-m commented 4 weeks ago

https://github.com/Rigo-m/nuxt-i18n-micro-test

In this reproduction, I should theoretically have 2 routes, instead I have 4 image

Are / and /test routes required or can they be removed? When we have 50/60 routes inside an application, it can be good for the sake of performance to remove non-localized routes. Am I missing something?

Rigo-m commented 4 weeks ago

As a side note: @s00d, can I buy you a coffee for the amazing work you are doing? I don't see any sponsorship link in your github :D

s00d commented 4 weeks ago

No, they must not be deleted under any circumstances, it will break Nuxt.

s00d commented 4 weeks ago

buy you a coffee

As a side note: @s00d, can I buy you a coffee for the amazing work you are doing? I don't see any sponsorship link in your github :D

Regarding support, I would gladly add a support link, but unfortunately, I don't have the option to do so.

s00d commented 4 weeks ago

As a side note: @s00d, can I buy you a coffee for the amazing work you are doing? I don't see any sponsorship link in your github :D

added a support link

FlorianWerndl commented 3 weeks ago

No, they must not be deleted under any circumstances, it will break Nuxt.

@s00d is this really necessary? From my understanding nuxt-i18n had the same issue and they found a way to remove the unprefixed routes, see: https://github.com/nuxt-modules/i18n/pull/2538

Thanks for the work!

s00d commented 3 weeks ago

No, they must not be deleted under any circumstances, it will break Nuxt.

@s00d is this really necessary? From my understanding nuxt-i18n had the same issue and they found a way to remove the unprefixed routes, see: nuxt-modules/i18n#2538

Thanks for the work!

The main route definitely can't be deleted, the others can be tried, but I'm not sure how best to check it. Also, you need to keep in mind that there's a lot of functionality that could break.

s00d commented 3 weeks ago

No, they must not be deleted under any circumstances, it will break Nuxt.

@s00d is this really necessary? From my understanding nuxt-i18n had the same issue and they found a way to remove the unprefixed routes, see: nuxt-modules/i18n#2538

Thanks for the work!

Is it really critical for you to remove the default routes? I've basically implemented it, though I had to add some workarounds, and it seems to work. If it is important, could you please explain why you need this and what problems you're encountering? I'm still considering whether it's worth releasing.

FlorianWerndl commented 3 weeks ago

I wouldn't say it is critical but may make a difference.

E.g. I am maintaining an multilanguage application which is available in 27 languages. Right now it has about 1137 routes. Every new route - which is translated - will add 27 routes + 1 without a prefix. I would be happy for every route which is not added.

s00d commented 3 weeks ago

I wouldn't say it is critical but may make a difference.

E.g. I am maintaining an multilanguage application which is available in 27 languages. Right now it has about 1137 routes. Every new route - which is translated - will add 27 routes + 1 without a prefix. I would be happy for every route which is not added.

My module works differently; each new language does not add routes. You will always have the number of routes multiplied by 2. That was its main idea. So, if you have 100 routes, with my module, there will always be 200, regardless of how many locales you have, whether it's 2 or 202 (unless there are exceptions, such as using custom routing on pages).

The problem is that right now, I can't properly test the functionality of the new logic. I simply don't have a test project that could cover all of Nuxt's functionality and has a large number of routes and languages. If you are able to test its functionality after I release it, I can do that, but I will then need feedback from you.

s00d commented 3 weeks ago

Also, in your case, I would highly recommend looking into customRegexMatcher. It speeds up locale matching for the router. Thanks for this @Rigo-m The idea is that the regex becomes something like [a-z]{2}, and it makes it much easier for the router to handle routing.

Just a heads-up, this functionality will break integration with other modules. For example, if you're using an SEO module, it will stop working.

FlorianWerndl commented 3 weeks ago

I will create an simplified stackblitz example for my use-case. I am using globalLocaleRoutes for most of the routes (all the routes that needs to be translated). Maybe I did miss something.

FlorianWerndl commented 3 weeks ago

@s00d here you go: https://stackblitz.com/~/github.com/FlorianWerndl/n3-i18n-micro

s00d commented 3 weeks ago

@s00d here you go: https://stackblitz.com/~/github.com/FlorianWerndl/n3-i18n-micro

try v1.30.0 https://github.com/s00d/nuxt-i18n-micro/blob/main/test/n3.test.ts

Removed default routes and fixed links, also added your project to the tests.

FlorianWerndl commented 3 weeks ago

I've updated my repo to use 1.30.0 but I can't see any difference on the number of routes and unprefixed routes still exist.

Url encoding seems to be corrected though 👍

s00d commented 3 weeks ago

fixed, try v1.30.2

FlorianWerndl commented 3 weeks ago

With v1.30.2 just some unpefixed routes have been deleted. (all the unprefixed catch all, see screenshot for comparison)

v1.30.0

Bildschirmfoto 2024-10-24 um 15 52 39

v1.30.2

Bildschirmfoto 2024-10-24 um 15 53 41
s00d commented 3 weeks ago

With v1.30.2 just some unpefixed routes have been deleted. (all the unprefixed catch all, see screenshot for comparison)

v1.30.0 Bildschirmfoto 2024-10-24 um 15 52 39

v1.30.2 Bildschirmfoto 2024-10-24 um 15 53 41

It's impossible to delete the remaining routes; I need to somehow link a custom route with the original one, and the custom route should be found via the default route

s00d commented 3 weeks ago

With v1.30.2 just some unpefixed routes have been deleted. (all the unprefixed catch all, see screenshot for comparison)

v1.30.0 Bildschirmfoto 2024-10-24 um 15 52 39

v1.30.2 Bildschirmfoto 2024-10-24 um 15 53 41

I finally figured out how to remove almost all routes. Try version 1.31.0. I added a custom-fallback-route, which handles redirects for includeDefaultLocaleRoute. Now, there should only be local routes + 1 custom-fallback-route + the root route, and the disabled routes if you set false for the route in globalLocaleRoutes.

FlorianWerndl commented 3 weeks ago

I've did a POC on the application I mentioned earlier and - without final testing - it seems that I could reduce the number of routes from 1135 with nuxt-i18n to 850 with nuxt-i18n-micro. 🚀

I've updated my repo and I even see some more potential. Imagine passing something like the below to globalLocaleRoutes

...
info: { 
     de: '/info',
     fr: '/info',
     ru: '/информация',
    ...
},

This would create a route for every translation like /de/info and ru/информация and so on.. But some of the have overlapping translations like fr and de. This could be consolidated to (de|fr)/info. Maybe by just not adding de and fr to the object of info or by passing false as a value?

s00d commented 3 weeks ago

I've did a POC on the application I mentioned earlier and - without final testing - it seems that I could reduce the number of routes from 1135 with nuxt-i18n to 850 with nuxt-i18n-micro. 🚀

I've updated my repo and I even see some more potential. Imagine passing something like the below to globalLocaleRoutes

...
info: { 
     de: '/info',
     fr: '/info',
     ru: '/информация',
    ...
},

This would create a route for every translation like /de/info and ru/информация and so on.. But some of the have overlapping translations like fr and de. This could be consolidated to (de|fr)/info. Maybe by just not adding de and fr to the object of info or by passing false as a value?

I initially planned it this way, but there’s a problem: I’m searching for routes by name, and I need to come up with logic that would allow me to find the right route. Right now, I have no ideas, which is why it’s done this way.

So, it works in a way that, when creating a custom route, a new route is created from the locale-new route, for example, with the name locale-new-en. After that, when switching locales, the search occurs by name, either locale-new or locale-new + selected locale. But if you combine them, it’s unclear how to find the route. Path matching is not an option, as it’s custom. Coming up with a common name doesn’t work. Setting up metadata would increase routing complexity, so it’s unclear how to make it work.

Why, in your case, don’t you use parameters in the links? For instance, /:locale(en|de|ru)/:name/:key would work perfectly for you. This approach would solve all your issues. You could create a hidden page with all the links or a module that generates all the links, or fetch all values from the backend. In general, there are many options, and they’re all simpler than what you currently have.

FlorianWerndl commented 3 weeks ago

Right now, I think I don't really understand what you mean - but I will make my mind about it. btw. I have a page where these links are generated based on values from the backend.