Allow to override getValue method

[JulienBier]

Current behavior

Cannot override getValue() method

Expected behavior

Define my own getValue() method

What is the motivation / use case for changing the behavior?

In the previous version 15.0.0, I could override the getValue method in TranslateDefaultParser, to have my own local override implementation. But in the version 16.0.0, the getValue() cannot be overriden anymore
https://ngx-translate.org/getting-started/migration-guide/#24-translateparser-getvalue

How do you think that we should implement this?

Is there a way to inject my own getValue method in the app ?

Thank you for that nice library.

[CodeAndWeb]

Currently there's no way to override it.

I've removed it from the parser because the idea of the parser is about parsing/interpolating the translation message.

The getValue() method was misplaced in this class - and even worse was used for 2 purposes:

• finding a specific translation in your translation data
• finding an interpolation value in a parameter

Which of the functionality do you want to override?

[JulienBier]

The goal is to be able to override a key.
For example, we have keys defined as such:
'shared.component.button.label' and we want, in some cases depending on the context, to have an override as such:
'overrides.some_key.shared.component.button.label'
And the best place to do that seemed to me to be the getValue() method.

[CodeAndWeb]

That is indeed not accessible at the moment.

The probably best way to do that currently would be in the loader by merging both objects into a single one, where the overrides "win".

I might also come up with a new class that will be responsible for storing and accessing the translations instead of keeping that code spread in the service itself.

[JulienBier]

The probably best way to do that currently would be in the loader by merging both objects into a single one, where the overrides "win".

The problem is that we want to have the overrides or not, without having to reload the locales.

I might also come up with a new class that will be responsible for storing and accessing the translations instead of keeping that code spread in the service itself.

Having a service for this would be amazing.

In the meantime, I will stay with the previous version and continue to think about an alternative.

[inmativ]

We are faced with the same problem. To solve it, I had to copy the TranslateDefaultParser and in a copied option to add the logic around getValue.

[6796524]

We face also this issue. Custom extended version of TranslateDefaultParser with specific handling on keys (override getValue).

[wamasimba]

We also face this issue. We use the TranslateParser.getValue to parse a multi-label translation string; we prefix labels in that type of string with '@', for example '@FIRST_LABEL / @SECOND_LABEL', or more elaborate constructs... Each label can be translated separately using the TranslateService (and yes we solved the circular dependency issue quite nicely).

[wvankoppen]

The getValue() method was misplaced in this class - and even worse was used for 2 purposes:

@JulienBier I understand your motivation for this change. Though I also think it severly limits the use of providing custom behavior to the library (in this case a custom TranslateParser).

A simple solution might be to isolate getValue in a separate class, that can be overriden as well?

[JulienBier]

A simple solution might be to isolate getValue in a separate class, that can be overriden as well?

Yes, as long as there is a way to override it.

[CodeAndWeb]

4562aef

• I've made all methods in the default parser protected so that you can override them
• I've isolated the replacement in the interpolation function into a separate function

  protected getInterpolationReplacement(params: InterpolationParameters, key: string): string
  {
    return this.formatValue(getValue(params, key), key);
  }

So - this changes the "getValue()" which is part of the parser to implement the interpolation. It should help those cloning the TranslateParser to modify how a key is replaced / formatted.

I'm now also using a separate formatValue() function that renders objects that don't provide in toString() function into JSON instead of [object Object].

But this is not yet the change @JulienBier wanted as I understand it - that would be the selection of a key - but that is not part of the parser anymore.

[CodeAndWeb]

ae09020

This is still a work in progress.

getValue() is now available in the TranslateStore and can be overwritten with custom functionality.

This should allow the customizations @JulienBier wanted.

[wamasimba]

ae09020

This is still a work in progress.

getValue() is now available in the TranslateStore and can be overwritten with custom functionality.

This should allow the customizations @JulienBier wanted.

This sounds like it might work; is there some way to obtain (release candidate) packages with the suggested addition (or should I say: revert)?

[JulienBier]

Amazing. I am looking at the changes and I try to figure how I could override the getValue in the store service?

[CodeAndWeb]

Just derive from the store...

[wamasimba]

By now, I tested this, and concluded that it works just as well. Right now, I juggled a local build, but would like to see this in a released package. I already forked this, and am contemplating publishing this version via npm on my own. We need this to go forward with upgrades of several packages and apps, for this we can't wait much longer! So... @CodeAndWeb , publish this as a new version ASAP, please!

[wvankoppen]

@CodeAndWeb we are also eagerly waiting for a package release of this change!

@wamasimba let me know if you deployed it, such that we have an alternative to use

[joepvl]

@CodeAndWeb anything we can help you out with wrt the merged changes? E.g. tests, docs, examples...

[wamasimba]

As the next release is taking waaaay too long, I released the current state of this repo as @wamasimba/ngx-translate-core, version 16.0.5, see also https://www.npmjs.com/package/@wamasimba/ngx-translate-core