Weird behaviour of tap:i18n package

I am using tap:i18n for internationalization for quite a while, and it worked quite well. But now I am facing a weird behaviour which is driving me crazy. If I add more i18n keys to a language file for DE, they are just ignored and the package falls back to EN, even if other DE language keys can be retrieved from the very same JSON file. So I end up with a strange mix of language in my app. It started in one dialog, but now also other, newer dialogs are affected.

Strange thing is that this behaviour is indeterministic. For instance, the language shows up fine if Meteor just refreshes after the change. But as soon as I stop and restart the server, the language mix appears. It can also happen that some of the keys have been translated properly, while others don’t.

I debugged the package and found out that in the case that the keys are not translated, they are missing in the internal “resStore” for “de”. Other keys from the same JSON file are there, so only some keys are missing (but only in the DE translation, not in the EN base language). I double-checked the JSON, and also my linter does not complain about the syntax, so I think the JSON file itself is just fine. The English file has the very same structure, so I can just not understand why some keys are missing in the translation.

Did anybody else face this strange behaviour and may have an explanation for this - or is it just me who is affected?

I only had this issue on JS generated elements, f.e I’m using Materialize as Ui framework and sometimes my select elements have a language mix, because language was set after initialization.

This is not the case here. I am using the standard Blaze helper _ to get the language keys.

Yep, I have seen the same behavior. A couple of keys will fail to get registered with no apparent rhyme or reason. I haven’t had a chance to look into what’s causing it. My linter says the JSON is fine as well. For the short term I’ll trick the package into rebuilding the store by making an artificial change. That solves things for a while. But the behavior makes me uneasy.

1 Like

Yep, it makes me uneasy as well.

It started when I included html <span> tags in the values. Maybe this is a coincidence, but I removed them now and monitor if this changes something. Before, I even tried to escape the end tags with <\/span>, as defined by the JSON standard, but this did not help.

At the moment, I rather have the feeling that the package fails if the amount of keys or JSON files gets too high, for whatever reason. I hope that I won’t have to swap it, because in principle I like this package.

BTW: Did anybody succeed in using the namespacing feature? I tried as suggested in the docs, but the package behaved quite weird in this case as well. If you add the package-tap.i18n file without any content, the namespace is activated (which per se is a bit strange to me, but obviously this is the trigger). But the _ helper still referenced the project namespace. I tried to define a new helper name, as documented in the description, but this only threw an error. I had a look at other projects like Telescope, but they just force the package to the project namespace.

Update: Removing the HTML tags did not help. The problem still occurs (in an indeterministic fashion).

Yeah this wouldn’t be cool, in particular because tap:i18n is currently the Meteor Guide’s recommended internationalization package. I’m planning to check if anyone has submitted the issue on gh and if not, to do so.

I already submitted an issue. But reaction times of the maintainers are pretty slow, this was the reason why I also posted to this forum.

It’s now getting even weirder. Because I suspected that the problem might have something to do with HTML tags I included in some of the translations, I removed all of them. But they still show up in the app!

They are definitely gone in all of the files, but I can still see them. I first thought this might be related to some browser caching, but this also happens on browsers on which I never had viewed my app before.

Maybe it’s some weird caching behaviour of Meteor’s build process? I remember Slava writing in one thread that tap:i18n is still using an “old” build API. I don’t know, but the phenomenon is really strange and makes me grow grey hairs now…

EDIT: Did a meteor reset now, and all translations are correct. Seems as if it is in fact a kind of server-side caching issue.

Had the same issue.
Edit to i18n.json shows correctly on initial refresh (intelij), then in subsequent restarts, reverts to old content.
I tracked it down to the .meteor/bundler-cache
I deleted it and my changes persist.

2 Likes

Thanks for that info! At least this is a better workaround than doing a full meteor reset, as I am doing now.