How to maintain translations file?

[vwong]

I'm using https://next-intl-docs.vercel.app/docs/usage/typescript to ensure that I only import valid translations.

However, I want to also know how to do this the other way around. Ie, if I delete an instance of t('mystring'), that I can safely remove this in ./messages/en.json, and not leave this file as append-only, and grow in size over time.

Is there a mechanism for doing this? Perhaps something like https://formatjs.io/docs/getting-started/message-extraction to try compare the translations file against code that actually consumes it?

[amannn]

That's an interesting point. Currently there's unfortunately no way to validate that you're only providing messages that are actually used.

The closest to this is probably to build up a list of used namespaces to filter any unused ones on a page out. However the unused messages would still be in your translations file.

[vwong]

I see, that's unfortunate. I'm already using the list of used namespaces. I suppose if I used more-but-smaller components and thus namespaces, the problem gets smaller, though never really disappears.

Identifying which namespaces are actually used is also tricky:

• I can bubble it upwards like in your example: Parent.messages = ["parentNamespace", ...Child.messages]. But this gets boilerplate-y very quickly especially when there are deep component trees with intermediate layers that don't even have anything to do with messages, but have to forward it upwards.
• I can skip the bubbling, and just "know" which namespaces are in play. This eliminates the boilerplate, but introduces magic instead.

Is there a another option that I haven't considered?

[amannn]

But this gets boilerplate-y very quickly especially when there are deep component trees with intermediate layers that don't even have anything to do with messages, but have to forward it upwards.

Yep, I see your point. I took inspiration from Relay where fragments are composed this way – however I think they introduced an automatic compiler now for the composition. It takes a few lines of code to compose these correctly together, but I found it not so bad in practice. Feature-wise a real limitation here is that this approach currently doesn't work for lazy loaded components. I'd be interested to explore Suspense-based lazy loading of messages once Suspense for data fetching ships.

Apart from that I'd certainly be interested in an automatic way of retrieving namespaces from a dependency tree but I haven't had time to look into that in more detail and for my personal needs the manual composition of namespaces worked fairly ok.

So to answer your question: I think you're aware of the options that are currently applicable.

[vwong]

Ok, thanks for the feedback.