Ngx Translate with Angular 9

[Al-Sharif]

Ngx Translate is not wokring perfectly on Angular 9 while the translate pipe is not working.
so in your standard component you should add 'translate' as directive on each translatable field.
like this
<span translate>GENERAL.ERRORS.REQUIRED</span>

[Al-Sharif]

I'm sorry, translate pipe is working from ngx-translate
but still no translation from validation errors component

[rams23]

hi @Al-Sharif can you show me your configuration? as with the issue with #17 I have to improve the compatibility of the angular 9 but i don't think that you error is related

[rraksi]

I encountered the same problem although with Angular 10 and Material input fields. If I translate by hand like below, the translation works. Also GENERAL keys are not used if a key does not exist for the field.

<mat-form-field *ngxValidationErrors="form.get('title'); errors as errors">
    <input matInput placeholder="Title" formControlName="title">
    <mat-error *ngIf="errors">{{errors[0] | translate}}</mat-error>
</mat-form-field>

[rams23]

hi @rraksi The behaviour for the material input is the intedend one. Do you expect to see the translated message directly? if you see the demo project there are in fact the keys

Maybe i can add a parameter in the structural directive to receive the translated message.

On the contrary I don't understand the problem with the "GENERAL" key, can you give me an example?

[rraksi]

Yes, I was expecting to get the translated message as for the non material input components. If you could make a parameter for it, t would be great.

As I understood from the documentation if a message translation is not available in the specified validation context than the translations from the default context are used. Seeing that the translation currently does not occur for material inputs, the implementation of this logic would be the component's user's task.

[rams23]

@rraksi The non material example has a default error component that uses the translation pipe that is injected into the formFieldContainer, as explained in the readme this approach is not feasible for material input (or at least I was not able to do it). That's why there is a strucrural directive that exposes the errors keys. the keys should aready have a fallback, if you don't find the correct translation you will have the error key with the GENERAL prefix but still you have to use explicitly the translation pipe. I will try to add an export for the translated message, injecting the translation context into the material directive