Bug(scope): Transloco loads nested scopes in a wrong way.

[PavelTurk]

Is there an existing issue for this?

• I have searched the existing issues

Which Transloco package(s) are the source of the bug?

Transloco

Is this a regression?

No

Current behavior

I have nested scope:

i18n
    foo
        bar
            en.json 

To load and translate via code I use translocoService:

    translocoService.load("foo/bar/en");
    translocoService.translate("foo.bar.test")

However, when I try to translate, I get an error - Missing translation for 'foo.bar.test'. Using debugger I found out that at this line of the TranslocoService the following translations is returned:

{
   "fooBar.test": "some text"
}

As it is seen instead of "foo.bar.test": "some text" transloco created "fooBar.test": "some text".

Expected behavior

Transloco must create "foo.bar.test": "some text" instead of "fooBar.test": "some text".

Please provide a link to a minimal reproduction of the bug

Transloco Config

No response

Please provide the environment you discovered this bug in

Transloco: 4.0.0
Angular: 13.3.5
Node: 17.3.0
Package Manager: 8.3.0
OS: Ubuntu 20.04.3 LTS

Browser

Firefox 95.0.1

Additional context

I've started to use transloco recently, so, I am not sure if this is a bug.

I would like to make a pull request for this bug

No

[PavelTurk]

I think, that the problem is in these lines: https://github.com/ngneat/transloco/blob/master/libs/transloco/src/lib/transloco.service.ts#L531 and https://github.com/ngneat/transloco/blob/master/libs/transloco/src/lib/transloco.service.ts#L792

From https://github.com/ngneat/transloco/blob/master/BREAKING_CHANGES.md scopeMapping property was removed from TranslocoConfig in v.3, so, scopeMapping[scope] || toCamelCase(scope); has no sense, as it will always go toCamelCase().

[cs-pratap-nikam]

@PavelTurkish did you get any solution on this ? I am facing the same issue

[PavelTurk]

@cs-pratap-nikam As I remember I used some workaround. But I don't remember what it was, I even don't remember the project I used it in. Sorry.

[PavelTurk]

@cs-pratap-nikam Maybe I merged some folders into one. Something like this:

i18n
    foo.bar
            en.json 

But I am not sure

[cs-pratap-nikam]

@PavelTurkish thanks for the quick response. I am stuck in similar situation. I am thinking to go with camelCase approach because there are going to hundreds of such subfolders. so it will be difficult to in maintaining foo.bar structure.

[shaharkazaz]

@cs-pratap-nikam You are welcome to suggest a solution and open a PR 👍

[JordanW9232]

@shaharkazaz I added a new pull request for this here: #738

[shaharkazaz]

@cs-pratap-nikam @JordanW9232

After revisiting this issue, from what I see, when providing 'nested/scopes/admin-page' you get 'nestedScopesAdminPage'. what's the issue here? if you want it any other way you can provide an alias.
Any thoughts? if not I'm closing this.

[JordanW9232]

@cs-pratap-nikam @JordanW9232

After revisiting this issue, from what I see, when providing 'nested/scopes/admin-page' you get 'nestedScopesAdminPage'. what's the issue here? if you want it any other way you can provide an alias. Any thoughts? if not I'm closing this.

I know you can just change it with an alias, but having it generate like "nestedScopesAdminPage" by default makes zero sense. In your scenario, nested/scopes/admin-page would make way more sense to generate like "nested.scope.adminPage". Telling people "change it if you want" is not a solution.

[shaharkazaz]

@JordanW9232 makes zero sense in your opinion, if you ask someone else you might hear a different answer, Otherwise this issue would have had a lot more traffic.

As stated here depending on the nesting of the scopes, things can get pretty ugly pretty fast, this goes for the camel case strategy as well.

The camel case strategy is what Transloco provides OOTB, I think this is easily resolved with a pure helper function that gets a scope path and returns the scope definition:

export function translocoScope(scope: string) {
  return {
     scope,
     alias: // You define whatever you want
  }
}

I think that scopes are flexible enough for you to get the variation you want with very little effort.