search

nuxt-modules / i18n

I18n module for Nuxt
https://i18n.nuxtjs.org
MIT License
1.71k stars 478 forks source link

feat: add new strategy prefix_regexp #2927

Open s00d opened 5 months ago

s00d commented 5 months ago

❓ Type of change

📚 Description

This pull request introduces a new routing strategy, prefix_regexp, to the nuxt/i18n module. This strategy is designed to streamline the generation of localized routes by reducing the number of routes needed for applications supporting multiple languages.

Key Advantages:

  1. Simplified Route Management: By consolidating non-default languages into a single route using a regular expression, this strategy significantly reduces the complexity and quantity of routes that need to be managed. This makes the application easier to maintain and debug.

  2. Improved Performance: Fewer routes mean quicker setup times for the router and faster re-rendering, which can lead to improvements in overall application performance, especially for larger projects with many supported locales.

  3. Reduced Bundle Size: Since only two routes are generated (one for the default language and one consolidated route for all other languages), the size of the application bundle is reduced. This minimizes the amount of code that needs to be loaded and parsed by the browser, enhancing load times and efficiency.

  4. Enhanced Flexibility: This strategy offers a flexible approach to handle locales by utilizing regular expressions, which can be adapted to various complex requirements without altering the core routing logic.

The implementation of this strategy provides a significant advantage by not only simplifying the management of routes but also by offering a more efficient, scalable, and performance-optimized approach to handling multilingual routing in Nuxt applications. It ensures a balance between user-friendly URLs and the technical requirements of a multilingual setup.

image

📝 Checklist

BobbieGoede commented 5 months ago

This is an interesting solution to the amount of routes scaling out of control with lots of locales, if there are no obvious drawbacks I think it would be preferable to change the other strategies to use this approach instead of adding it as a separate strategy, what do you think?

s00d commented 5 months ago

This is an interesting solution to the amount of routes scaling out of control with lots of locales, if there are no obvious drawbacks I think it would be preferable to change the other strategies to use this approach instead of adding it as a separate strategy, what do you think?

Initially, I considered implementing the approach you suggested, but I had concerns about potential risks that could significantly impact system stability. Therefore, it seems preferable to start with a separate strategy that will not affect the current functionality. This method will allow us to systematically conduct all necessary tests, adequately assess potential problems, and their impact on the system.

Moreover, it should be noted that modifying existing code presents a significant challenge due to its volume. A complete overhaul of the entire library would require substantial time resources, which could slow down the process of introducing new features and improvements. Therefore, for the sake of optimizing the development process and reducing risks, it is advisable to start with a separate and isolated approach that will allow for more controlled integration of new solutions.

BobbieGoede commented 5 months ago

Moreover, it should be noted that modifying existing code presents a significant challenge due to its volume. A complete overhaul of the entire library would require substantial time resources, which could slow down the process of introducing new features and improvements. Therefore, for the sake of optimizing the development process and reducing risks, it is advisable to start with a separate and isolated approach that will allow for more controlled integration of new solutions.

I understand what you mean, the codebase is quite large and adding functionality is more manageable this way. Originally the routing logic was split between this module and https://github.com/intlify/routing/tree/main/packages/vue-i18n-routing, which is one of the reasons why the routing logic is fragmented.

Since I integrated and (slightly) refactored that logic I'm quite familiar with it, if I have time I'll experiment to see if your approach can be used for the other strategies (perhaps making it opt-in with an experimental.regexRouting config), if this proves to be too involved I'm not opposed to adding the additional strategy as you suggest.

s00d commented 5 months ago

Moreover, it should be noted that modifying existing code presents a significant challenge due to its volume. A complete overhaul of the entire library would require substantial time resources, which could slow down the process of introducing new features and improvements. Therefore, for the sake of optimizing the development process and reducing risks, it is advisable to start with a separate and isolated approach that will allow for more controlled integration of new solutions.

I understand what you mean, the codebase is quite large and adding functionality is more manageable this way. Originally the routing logic was split between this module and https://github.com/intlify/routing/tree/main/packages/vue-i18n-routing, which is one of the reasons why the routing logic is fragmented.

Since I integrated and (slightly) refactored that logic I'm quite familiar with it, if I have time I'll experiment to see if your approach can be used for the other strategies (perhaps making it opt-in with an experimental.regexRouting config), if this proves to be too involved I'm not opposed to adding the additional strategy as you suggest.

I've uploaded a version here where I tried to switch the code to the new routing, but I didn't finish it. All the tests failed due to the route changes, and manually checking everything is very difficult.

s00d commented 5 months ago

@BobbieGoede I've fixed another part of the functionality in the full-regexp branch, but I'm stuck on custom pages and I don't know how to do it properly.

s00d commented 5 months ago

I've solved almost all the problems; there are just the last 8 tests left. However, I can't understand how some of them work, for example, the test specs/routing/prefix-and-default.spec.ts > localePath > route strategy: prefix_and_default > should be worked.