TranslateService.set breaks the localization keys with . inside

[matthieu-crouzet]

Current behavior

In our application we provide our localization with the following format

{
   "my-component-selector.key1": "value1",
   "my-component-selector.key2": "value2"
}

If I call TranslateService.set('my-component-selector.key1', 'new value').
It updates correctly my-component-selector.key1 but I lost the localization of my-component-selector.key2.
From what I understood it is because now localization keys are handled with hierarchy.
So after the update we should have something like:

{
  "my-component-selector": {
     "key1": "new value"
   },
   "my-component-selector.key2": "value2"
}

and now the translate service for my-component-selector.key2 returns undefined.

Expected behavior

I would expect my-component-selector.key2 to still be translated correctly as it works before the call to TranslateService.set

How do you think that we should fix this?

I think 2 options are possible here:

• The resolution of keys should first check the hierarchy as for now, and if undefined then check for the key as is.
• TranslateService.set could take an extra parameter to keep the format, in the example my-component-selector.key1 instead of {my-component-selector: {key1: 'new value'}}

Minimal reproduction of the problem with instructions

• Define differents localization keys with the same prefix and . as separator.
• Call TranslateService.set

Environment

ngx-translate version: 16.0.0
Angular version: 19.0.0

Browser:
- [x] Chrome (desktop) version XX
- [x] Chrome (Android) version XX
- [x] Chrome (iOS) version XX
- [x] Firefox version XX
- [x] Safari (desktop) version XX
- [x] Safari (iOS) version XX
- [x] IE version XX
- [x] Edge version XX
 
For Tooling issues:
- Node version: 20 || 22  
- Platform:   Mac, Linux, Windows

Others:
N/A

[CodeAndWeb]

See 66964cf

[CodeAndWeb]

This is indeed a bigger issue — depending on the file format you are using. Unfortunately, we do not have a simple solution for this yet.

Currently, these two cases are equivalent — and using a file like this is possible. However, I'm not sure which of the keys would be used in this case. Both keys can be retrieved using a.b:

{
   "a": {
      "b": "test"
   },
   "a.b": "test"
}

The set() function tries to convert the string into a nested form and then deep-merges the trees — which might also lead to a similar structure (your issue).

To fix this, the only approach I currently see is to normalize all translations into the flat "a.b" format, since normalizing into a tree structure might not work. For example, "a" and "a.b" can both exist in a flat file, but you can't build a nested form from it:

{
    "a": "test 1",
    "a.b": "test 2"
}

However, forcing the flat structure has its drawbacks. When using the nested version, calling get("a") returns an object with both keys:

{
   "a": {
      "b": "test 1",
      "c": "test 2"
   }
}

But in the flat version, get("a") returns nothing.

In short: Fixing this is quite complex and could introduce subtle bugs for existing users — potentially breaking projects in ways that are hard to detect. I would really like to avoid that.