Reference to different key

[Tockra]

Hey everyone,

I want to structure my translation keys based on my page structure, like this:

{
    "page1": {
       "myKeyForSomeTextfield": "MyTranslation"
    },
    "page2": {
        "mySecondKeyForSomeTextfield": "$page1.myKeyForSomeTextfield"
    }
}

Is there a way to reference one translation key from another, so I don’t have to duplicate the same translation in multiple places? The goal is to avoid maintaining multiple identical translations and ensure consistency when updating them.

Any suggestions or best practices for this?

Thanks!

[amannn]

next-intl doesn't provide a feature to cross-reference keys from another namespace. Based on conversations I had with developers who have worked on large i18n projects, the best practice is to never reuse keys—even if it appears to be the same currently. This ensures that if you change the message in the future that it doesn't have any unintended side effects. I'd recommend to either use a separate message or to consider if you can meaningfully extract a shared component and use that for key reuse.

Hope this helps!

[Tockra]

I appreciate the recommendation, but I still prefer a page-oriented approach to keep my project structure aligned with my Next.js folder organization. For example, several pages in my app display a sum value, and I’d like to ensure it’s consistently translated as, say, “Sum” (or “Total Sum,” etc.) across all pages.

Maintaining this term in multiple JSON objects feels redundant and error-prone—especially if I decide to rename it in the future and miss an instance. However, placing a global translation key in a single “root” object for just one term also feels inconsistent with my otherwise page-based structure.

For instance, I end up needing something like:

const tRoot = useTranslation(); // to address the global key
const t = useTranslation('mySubPage.some');

I understand next-intl doesn’t currently support referencing keys across namespaces, so I’m looking for any additional guidance or patterns that could help manage this scenario without scattering identical translation keys throughout different JSON files. Any further thoughts or recommendations would be greatly appreciated!

[amannn]

If you have a label where consistency is really important, you can also consider extracting the shared message to a hook (see the docs on messages reuse).

I'd try to approach it from this angle: If the app would only support a single, hard-coded language, would you:
a) share the label at all?
b) if you decide to share it, how would you do it?

The same answer should usually apply to using a translation with next-intl I'd say.

[Tockra]

I'd try to approach it from this angle: If the app would only support a single, hard-coded language, would you: a) share the label at all? b) if you decide to share it, how would you do it?

I’m not entirely sure what changes when you only have one language. Even in a single-language scenario, the problem of maintaining consistency across multiple pages still exists. You could argue that a shared component makes sense if you need to reuse UI or behavior, but in my case, this is merely a label—there’s no reason to wrap it in its own component just for translation purposes.

To illustrate my challenge more concretely:

• Multiple Pages, One Label: I have different pages that display the same “Sum” label (or “Total,” “Sum after tax,” etc.). The design is consistent, but I don’t want to duplicate the string in multiple places.
• Structured Organization: I’m using a page-oriented JSON structure that parallels my Next.js folder setup. It feels unnatural to define a separate “global” key for a single label, as it disrupts this structure.
• Future-Proofing: Even if I only had one language today, I still need a sustainable approach for when I add additional languages. Duplicating keys across files means higher risk of overlooking updates in the future.
• Desired Solution: I’d like to reference key A from key B within the translation file itself, so each language file can independently decide whether to reuse an existing translation or provide its own. If someone believes that’s bad design, they’re free to structure it differently—but the flexibility would be really helpful.

I hope that clarifies why a single-language context doesn’t fundamentally change my situation and why I’m looking for a mechanism to reference translation keys directly rather than duplicating them or creating unnecessary components. If you have any further suggestions or insights, I’d love to hear them!

[amannn]

I’m not entirely sure what changes when you only have one language. Even in a single-language scenario, the problem of maintaining consistency across multiple pages still exists.

Right, it's more about gaining clarity if it's a label you absolutely want to share or not.

I’m using a page-oriented JSON structure that parallels my Next.js folder setup. It feels unnatural to define a separate “global” key for a single label, as it disrupts this structure.

I think if you decide to organize messages purely by pages, you'll have to end up with some exceptions. Here's an example from a project that organizes messages by page (if possible), with some global exceptions: yournextstore.

E.g. if you consider global elements like a navigation or a footer, you definitely don't want to define either the labels or the code for each page. Due to this, at least some kind of component-scoped messages will likely be necessary IMO. If you consider this situation in a non-internationalized, single-language context, I think it's obvious that you'd simply the labels in the navigation/footer—that's what I meant above.