I would say the second approach. But Maybe we can avoid log warnings in production.

2️⃣ too

@oriolpuig, great job, my KUDOS 😍

I agree with you and also with @carlosvillu. I think it's important for the teams to detect translation issues but maybe we could avoid show warnings on production to try to keep the production console cleaner. So I prefer 2️⃣

On the other hand, I understand that you want to avoid using @s-ui/i18n package and only make a wrapper of node-polyglot, am I right?

@jelowin On the other hand, I understand that you want to avoid using @s-ui/i18n package and only make a wrapper of node-polyglot, am I right?

No, we can't override the current version of node-polyglot because our forked version was iterated on our side, si if we override now, we may cause breaking changes in how our tools are using this library.

What I'm proposing is picking this onMissingKey feature from node-polyglot and putting it in our library. But NOT override all.

Thanks for your Kudos!

@carlosvillu I would say the second approach. But Maybe we can avoid log warnings in production.

Yes, actually it's not possible to pass a flag to let us skip this warning, but we can do it with a hack in our portals 👀 by doing this i18n.adapter.instance.allowMissing = true. It's not exactly what we want, but we can achieve it.

Reviewing your proposals, we can add a new prop avoidMissingKeyWarn: true|false to conditionally this from outside. What do you think?

cc/ @jelowin

excellent contribution, @oriolpuig !

Not sure if I'm missing some context here and perhaps my comment doesn't make sense at all but... if the idea is to capture those error messages from i18n, couldn't we just set up our FE logger so that it also sends or collects console.warn messages? 🤔

Not sure if I'm missing some context here and perhaps it doesn't make sense at all but... if the idea is to capture those error messages from i18n, couldn't we just set up our FE logger so that it also sends or collects console.warn messages? 🤔

Hello @jordevo, thanks for your time!

First of all, as a developer, I think warnings do not make sense to be displayed in production. To get it, we can add a specific flag (for example: avoidMissingKeyWarn: true|false), to skip in production, test CI, or wherever you desire.

But, why do I suggest allowing us to monitor those warnings? I have 2 scenarios in mind:

• Yes, we can keep those warnings in our lab environments (test or local), but for scenario 2, we may lose some cases.
• Sometimes we are building translation keys from production API responses, for example: CAR_MODEL_${car.typeId}. You are using a dynamic API response value to pass it to our translation dictionary and may not exist because we are passing an uncontrolled undefined or another value not translated.

For those 2 reasons, I suggest to enable this feature and empower teams to monitor uncontrolled translations.

Next Monday we can discuss it in a quick call with some specific demos if you need it, and add here some screenshots to enforce this proposal.

Have a nice weekend! ❤️

gotcha, @oriolpuig !

I'd even go for a third approach as you kind of point out in your response...

3️⃣ call onMissingKey if configured and allow for console.warn to be configured so that it can be sent or not (ie to be logMissingKey: true on development but logMissingKey: false on production

does it make sense to you?