Support Wildcard * in dynamic keys

[muuvmuuv]

Is your feature request related to a problem? Please describe.

We have a scope FORM.ERROR.XXX and would like to avoid adding every scope here because it would be too difficult to maintain, can we have a wildcard for the last scope so that its ignored?

Describe the solution you'd like

A wildcard *: FORM.ERROR.*

Describe alternatives you've considered

Something like "ignore scope FORM"

Additional context

Add any other context or screenshots about the feature request here.

Contribution

I would like to make a pull request for this feature:
[ ] Yes! 🚀
[x] Maybe next time – too much todo atm maybe earlier next year

[shaharkazaz]

@muuvmuuv Hey,
I don't understand the situation you are describing.
Can you please provide an example? with what you expect to happen? ignored by who? the issue is the something gets extracted when you don't want it to? (inputs & outputs)

[muuvmuuv]

That is what I want to do so it does not show it when I use the find command:

  /**
   * t(FORM.ERROR.*)
   */
  getErrors(): void {
	// ...
    for (const [key, value] of Object.entries(this.control.errors)) {
      if (this.config.errors && this.config.errors[key]) {
        // ....
      } else {
        this.errors.push({
          type: 'error',
          message: marker(`FORM.ERROR.${key.toUpperCase()}`),
          value,
        })
      }
    }
  }

I would like to avoid adding every case into t(..).

[shaharkazaz]

@muuvmuuv The issue is that these keys are getting extracted and you don't want them extracted?
Or they are not extracted and you want them to?
Can you add a current json example and an expected json example?

[muuvmuuv]

I don't use extract at all because we have a tool to manage our translations, but I would like to find translations that we might have forgotten. So, yes, I want to ignore those because they are impossible to fetch since they are dynamic.

[shaharkazaz]

@muuvmuuv a few questions:

1. Have you seen the dynamic keys section?
2. If you are not using the extract, and you want to ignore these values, why use the marker function?
3. Currently when you are running find, what is the result?

[muuvmuuv]

1. Yes.. this is a proposal for dynamic keys
2. I just started using this CLI and just didn't notice. Thanks for the hint, will replace it with the comment.
3. It shows some missing keys and extra keys:

│ File Name │ Missing Keys             │ Extra Keys                       │
├───────────┼──────────────────────────┼──────────────────────────────────┤
│ de-DE     │ 'NO_COMMENTS_YET'        │ '__00'                           │
│           │ 'FRIENDS.REQUEST_SEND'   │ '__01'                           │
│           │ 'FORM.ERROR.'            │ '__02'                           │
.............................. + 40 and more 
│           │                          │ 'FORM.ERROR.EMAIL'               │
│           │                          │ 'FORM.ERROR.MAX'                 │
│           │                          │ 'FORM.ERROR.MIN'                 │
│           │                          │ 'FORM.ERROR.MINLENGTH'

I would like to reduce the "extra keys" section.

[shaharkazaz]

@muuvmuuv I see what you mean. The thing is that the extract and find use the same mechanism, and adding this wildcard could be problematic.

The correct way to handle this is by adding all those dynamic keys in the supported conventions, as the keys manager expects you to.

I'll think about it a little more, but in the meantime, that's the approach I'm suggesting.

[vincent-benbria]

I'm also interested in the ability to mark a section to ignore, as a way to keep a clean "find" report when using dynamic keys that I simply don't want to write a 500 lines comment for.

[guilhermetod]

A question here: shouldn't the validation part of this project be put on transloco-validator?

I think more people may have this use case of "I don't want extract, I only want to validate my translation keys" and tbh I thought that the validator would do this when I first found out about it.

Maybe this separation would put each project to its responsibility and allow this issue to be solved.

[shaharkazaz]

@guilhermetod The detective and the extractor share the same code, they belong in the same repo.