Open noahbald opened 1 month ago
@noahbald Thank you for your interest in my plugin.
I tested it with this example and found that by making some changes to the plugin's configuration and implementation, it can be used to some extent with next-intl.
The plugin configuration should be as follows.
opts = {
translation_source = { "**/messages/*.json" },
detect_language = function(path)
return path:match("([^/]+)%.json$")
end,
},
As with i18next, passing a namespace to useTranslations is not supported.
Therefore, you can rewrite it as shown in the image below to display virtual text.
src/app/[locale]/page.tsx (Original) |
src/app/[locale]/page.tsx (Edited) |
---|---|
If you need any specific features, please let me know.
Thanks, this seems to only work if the full translation path is passed to t
though
// Works
const t = useTranslation()
t('IndexPage.title')
// Doesn't work
const t = useTranslation('IndexPage')
t('title')
If you need any specific features, please let me know.
Were there any plans to allow next-intl's namespacing?
const t = useTranslation('my.namespace')
t('value') // my.namespace.value
you can rewrite it as shown
I won't have the power to do this across my organisation's project
Were there any plans to allow next-intl's namespacing?
Once the implementation of priority features is complete, I would like to support namespaces as well.
In order to support namespace features, the plugin requires a higher level of code analysis. So it may take some time to implement.
@noahbald Hello, I’ve improved support for next-intl and also added keyPrefix support. Please update to the latest version and give it a try. If you encounter any bugs or have further feedback, please report it.
Hello, just found this through the latest dotfyle.com newsletter and it looks really useful.
I’m using a very similar library, next-intl, which looks very similar to i18next.
I don’t mean to get in the way of your awesome work so far, but curious if this was something you were looking into? :)