The reason for this move is the fact that our designer’s work feels too distant from Material Design and we’re not willing to swim against the flow. We feel like overriding all the Angular Material styles is not going to be easy and would be hacky (at best).
In this article, I’ll explain how we’ve managed to translate the PrimeNG menu dynamically.
The boon and bane of Prime’s menu system is that it is backed by a powerful menu model.
The nice thing about that model is that we can statically define the menu’s configuration, pass it as input to the p-menu and let it render everything for us.
What’s less nice is the fact that we have very limited control over how the menu items are rendered, as opposed to Angular Material’s mat-menu component, which uses content projection and thus lets us insert whatever we want into the menu easily.
This is problematic at least in the context of internationalization, because the labels that we pass to the menu aren’t dynamic. They’re set once and don’t get automatically updated. Bummer!
With mat-menu, we simply has to use ngx-translate’s translate pipe and it worked fine. With PrimeNG’s menu, we had resort to
translateService.instant(...), which does a one-time translation that doesn’t get updated automatically.
Here’s what our menu looks like once converted to PrimeNG:
And the template:
The problem is that with this in place, the menu translations are interpolated only once at construction time (during ngOnInit), but those don’t get re-evaluated when the language is changed. Bummer!
After looking into it a bit, only two solutions stood out:
- Fork PrimeNG’s menu to bend it to our will and be able to use the translate pipe directly against the labels provided in the menu model
- Rebuild the menu model whenever the language changes so that it contains the correct translated text
For now, we’ve started with the second option. The first one would be better for other reasons, but also problematic because it would introduce technical debt.
So here’s our plan: subscribe to language changes events and rebuild the whole menu each time the language changes.
In our application, we store the current language in the NGRX store and our facade simply exposes a selector to let us watch for value changes, which makes this really easy, but the same can be achieved using the
onTranslationChange event emitter exposed by the
TranslateService service of ngx-translate:
With this, we get warned whenever the language changes. When that happens, we need to rebuild the menu. Note that the example code above doesn’t handle the subscription correctly; don’t forget it for your applications though or you’ll introduce a memory leak ;-)
In order to do this easily, we’ve simply moved the construction code of our menu model in a factory method:
Whenever the language change callback is invoked, we just have to call our buildUserProfileMenu method to get a new version of the menu with the correct translations.
Here’s an overview of the code:
In this small article, I’ve described how we’ve handled the internationalization of our new PrimeNG menu.
I’m not really happy about how we had to do it, but this is the cleanest approach I could find.
That's it for today! ✨
Hello everyone! I'm Sébastien Dubois. I'm an author, founder, and CTO. I write books and articles about software development & IT, personal knowledge management, personal organization, and productivity. I also craft lovely digital products 🚀
If you've enjoyed this article and want to read more like this, then subscribe to my newsletter, check out my PKM Library and my collection of books about software development 🔥.
You can follow me on Twitter 🐦
If you want to discuss, then don't hesitate to join one of my communities: the Software Crafters community, the Personal Knowledge Management community, and the focusd Productivity community