Closed soblakulov closed 10 months ago
I'm not able to reproduce the problem, see: https://codesandbox.io/p/sandbox/next-international-app-router-forked-gwhv5q?file=%2Fapp%2F%5Blocale%5D%2Fpage.tsx%3A1%2C1
Instead of recognizing 'uz-latin' as a single locale, it seems to misinterpret the structure.
What do you mean by this?
Thanks bro. Now it works fine.
Introduction: Next.js 13 has introduced a plethora of features, making it one of the go-to frameworks for React developers. One of its standout features is its native support for internationalization. However, during our application development, we've encountered a minor hiccup related to the representation of locales in URLs.
Detailed Description of the Issue: Upon implementation of the internationalization package, it was noticed that there's a potential limitation or bug in the way the package handles locales in the URL that contain a dash (-).
Working scenario: When using a simple locale without a dash, such as 'uz', the package works seamlessly. The URL http://localhost:3000/uz/ is parsed correctly, and the application responds with the expected localized content.
Problem scenario: Issues arise when using a locale with a dash, like 'uz-latin'. The URL http://localhost:3000/uz-latin/ does not behave as anticipated. Instead of recognizing 'uz-latin' as a single locale, it seems to misinterpret the structure.
Impact on Development: For languages or regions that utilize a dash in their locale representation (e.g., en-US, zh-Hant), this could be a significant roadblock. It restricts the flexibility and the standard nomenclature for locale identifiers.
Potential Solutions/Workarounds: