-
-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optional translations #88
Comments
Can we have these two features:
|
I use this code to implement the logic: import merge from "deepmerge";
import { getRequestConfig } from "next-intl/server";
export default getRequestConfig(async ({ locale }) => {
const localeMessages = (await import(`./messages/${locale}.json`)).default;
const localeGeneralMessages =
locale.split("-").length > 1
? (await import(`./messages/${locale.split("-")[0]}.json`)).default
: {};
const defaultMessages = (await import(`./messages/en.json`)).default;
const messages = merge.all([
defaultMessages,
localeGeneralMessages,
localeMessages,
]);
return {
messages,
};
}); It can run successfully, but give me the type warning for
anyone know how to solve this? |
Merging messages from another locale as a fallback is absolutely fine and also mentioned in the messages docs ("How can I use messages from another locale as fallbacks?"). |
I've solved the issue like this, but I only have two elements, maybe you can do two steps
|
My usecase: Our backend is returning a However, it is possible that a new value comes down the line. As far as I can tell, this isn't supported by this library? |
@philipbjorge Have you considered using select for this use case?
|
Mmm interesting solution... We have 900 selections, so I feel like that string might become unwieldy. I think we might go with something like this since the key name is well-defined.
|
Is your feature request related to a problem? Please describe.
It would be good if some translations could be marked as optional, so no error is reported.
Describe the solution you'd like
Either an API to ask if a translation is available to conditionally render it, or an API to suppress the error in this case.
Probably
t.has(…)
would be the best option here as it can be used to check for translations before using eithert
,t.rich
,t.raw
etc.Describe alternatives you've considered
Adding empty strings in the messages if the label is not relevant for a particular scenario (i.e.
"message": ""
).If you're using the VSCode integration for
next-intl
via i18n Ally, you can add empty messages for new keys via"i18n-ally.keepFulfilled": true
.I'm currently unsure if
next-intl
needs built-in support for this, or if it can be solved with tooling. I guess the question is: "Is this translation missing currently or is it not intended at all?".This could also be solved via a combination of
useMessages
andlodash/get
, e.g. in a custom hook.The text was updated successfully, but these errors were encountered: