This fix should appear in the next patch release 11.0.6, which should be released this week or next.

The PR and issue were closed because we merged in the fix from it.

Angular is able to display the proper text (with interpolated values) even though all the equiv-text are wrong

Yes, as you say, the equivText attributes play no part in the Angular translation process. They are only there to help translators understand where the placeholders come from.

There are a couple of fixes awaiting release (probably on Wednesday). Please try again when this is released.

Great news! When will the release be ready? Can we use the code right now?

Indeed it does appear that the \r\n line endings are triggering the bad extraction and the change described in https://github.com/angular/angular/issues/40169#issuecomment-747376871 fixes it.

Hi @terencehonles - thanks for this request and query.

There is already an open issue for adding support for merging of extracted translations at https://github.com/angular/angular/issues/37655. I suggest that we continue the discussion of that feature there.

(The short answer is that it is not a trivial tool to create since people can have a wide range of setups - e.g. where the translation files are stored, what to do when a translation has been added/changed/removed, and how to do notification - and so we don’t have capacity to implement that ourselves. But I am open to making the pieces of @angular/localize, such as the parsers and serializers, publicly available to allow a 3rd party to implement such a tool. This is basically what https://www.locl.app/ have been doing - but using the private APIs.)

Regarding the xml:space question. Let’s open up a new issue to track that. There was some initial implementation of support for this here https://github.com/angular/angular/pull/38737. And there was some discussion of it and in particular why it was not the default here https://github.com/angular/angular/issues/38679#issuecomment-688827241.

Hello, I have the same problem, after uprading to Angular 11 translations that contain interplations are not properly extracted anymore. Running ng extract-i18n on the following example: <span i18n="@@exampleId">Text to translate: {{ value }}</span>

generates this output in messages.xlf:

<trans-unit id="exampleId" datatype="html">
	<source>Text to translate: <x id="INTERPOLATION" equiv-text=" translate: {{ va"/></source>
	<context-group purpose="location">
	  <context context-type="sourcefile">src/app/modules/.../example.component.html</context>
	  <context context-type="linenumber">13</context>
	</context-group>
  </trans-unit>

I did try the version of angular/compiler you suggested and the result is the same, this is a part of my packages.json file:

...
"@angular/common": "^11.0.2",
"@angular/compiler": "https://github.com/angular/compiler-builds#0755e9b961b3633057c9f44792d39722bb097f70",
"@angular/core": "^11.0.2",
"@angular/localize": "~11.0.2",
...

Also, this same issue is present when translating messages in Typescript files. Here is an example, the following code:

this.translatedMessage = $localize`:@@exampleIdInTypescript:Message with interpolations ${this.test} included`;

generates this output in messages.xlf:

<trans-unit id="exampleIdInTypescript" datatype="html">
	<source>Message with interpolations <x id="PH" equiv-text="
con"/> included</source>
	<context-group purpose="location">
	  <context context-type="sourcefile">src/app/modules/.../test.component.ts</context>
	  <context context-type="linenumber">491</context>
	</context-group>
 </trans-unit>

Meaning that now every translation that contains interpolations in our application is broken. Do you think a fix will be available soon? Should I downgrade Angular in the meantime or is there any workaround I could use for this issue?

Thanks in advance