Closed daniel-sc closed 10 months ago
@reifi are you sure that pre 2.8.0 the red part of the screenshot was generated and with 2.8.0 it changed to the green? Which pre 2.8.0 version did you use? Can you add a screenshot of the same unit from the messages.xlf? Your help is much appreciated :)
@daniel-sc Yes. I verified it by checking out my former source, with a fresh install of all npm packages - using ng-extract-i18n-merge v2.7.1.
Following values are from the previous build that was done with with v2.7.1:
The html source remained unchanged before and after I upgraded to v.2.8.0 (just changed the html comment to x's here):
html source:
<a href="#/msg/outbox"
[ngClass]="{active:ms.isMenu('msg/outbox')}"
i18n="@@submenu.msg.outbox">Ausgang
<!-- TODO: XXXXXX-xxxx Xxxx xx Xxx -->
<span class="message-indicator" [hidden]="!intervalService.messageSummary.data.outboxTotal">
{{intervalService.messageSummary.data.outboxTotal}}</span>
</a>
Then I ran: npm run extract-i18n
"extract-i18n": "ng extract-i18n --format=xlf2 --output-path src/locale"
My angular.json config also remained unchanged:
"i18n": {
"locales": {
"en-150": {
"translation": "src/locale/messages.en-150.xlf",
"baseHref": "/en-150/"
},
"it": {
"translation": "src/locale/messages.it.xlf",
"baseHref": "/it/"
}
},
"sourceLocale": {
"code": "de-AT",
"baseHref": "/de-AT/"
}
},
...
"extract-i18n": {
"builder": "ng-extract-i18n-merge:ng-extract-i18n-merge",
"options": {
"browserTarget": "bpwebapp:build",
"outputPath": "src/locale",
"format": "xlf2",
"includeContext": true,
"targetFiles": [
"messages.en-150.xlf",
"messages.it.xlf"
]
}
},
The resulting entries in the messages.xlf look like that:
<unit id="submenu.msg.outbox">
<notes>
<note category="location">src/app/shared/components/menu/menu-secondary/menu-secondary.component.html:31,34</note>
</notes>
<segment>
<source>Ausgang <pc id="0" equivStart="START_TAG_SPAN" equivEnd="CLOSE_TAG_SPAN" type="other" dispStart="<span class="message-indicator" [hidden]="!intervalService.messageSummary.data.outboxTotal">" dispEnd="</span>"><ph id="1" equiv="INTERPOLATION" disp="{{intervalService.messageSummary.data.outboxTotal}}"/></pc></source>
</segment>
</unit>
No changes in messages.xlf except the change of line numbers in
The resulting entries in messages.en-150.xlf look ok like that:
<unit id="submenu.msg.outbox">
<notes>
<note category="location">src/app/shared/components/menu/menu-secondary/menu-secondary.component.html:31,34</note>
</notes>
<segment state="translated">
<source>Ausgang <pc id="0" equivStart="START_TAG_SPAN" equivEnd="CLOSE_TAG_SPAN" type="other" dispStart="<span class="message-indicator" [hidden]="!intervalService.messageSummary.data.outboxTotal">" dispEnd="</span>"><ph id="1" equiv="INTERPOLATION" disp="{{intervalService.messageSummary.data.outboxTotal}}"/></pc></source>
<target>Outbox <pc id="0" equivStart="START_TAG_SPAN" equivEnd="CLOSE_TAG_SPAN" type="other" dispStart="<span class="message-indicator" [hidden]="!intervalService.messageSummary.data.outboxTotal">" dispEnd="</span>"><ph id="1" equiv="INTERPOLATION" disp="{{intervalService.messageSummary.data.outboxTotal}}"/></pc></target>
</segment>
</unit>
The diff of above changes for the resulting en-150 translation file src/locale/messages.en-150.xlf
looks like:
Because of the changed html entities, but besides that everything fine with v2.7.1 and no switch to initial.
Then I changed to v2.8.0:
After playing with 2.7.1 and directly upgrading to v2.8.2 without any development in between the diff for all language xlf files look like:
@reifi can you please try the latest beta 2.8.3-0 (preferably on a clean setup)?
Note: Historically this lib did swallow some whitespaces when nested html tags in translations occurred. With 2.8.2, this was only partly resolved, hence the state changes without any (apparent) source changes. With this beta release, you should notice an additional whitespace before the <ph
. Accordingly the state will change back to "initial", but if you change it back to "translated" (and keep the new whitespace), on subsequent executions, the state should not change any more.
Please let me know if you notice anything (else)!
@reifi after testing it myself, I'd suggest you wait for the next beta, I'll ping you..
After clean installing 2.8.3-0 and running extract-i18n once there is indeed an additional whitespace before the <ph
and the state is correctly kept to state="translated"
but not before <pc
. The unchanged ICU source, extracted with <pc
flips to "initial"
(The sample from above, the unit id "submenu.msg.outbox" at the bottom of the diff image, is using <pc
and flips to initial)
extract-i18n
flipped some other values in all language files:No changes on further executions
@daniel-sc tested v2.8.3-2 (again clean - no other changes) and now it flips to initial (but probably more correct?):
@reifi thanks for the testing! Yes, any (whitespace) change in the source should change the state back to initial. I'll do some more testing and release in the next days..
should be resolved with v2.8.3
@daniel-sc Thanks for your time and effort !!
I found something else nowtoo, in the translations files besides messages.xlf, that was also in before with v2.8.0, a translation that jumps from 'translated' to 'initial':
also with a newline.
The Source, last time changed 8 months ago is:
It might look strange, but it's a hybrid Angularjs/Ngx app that works.
Originally posted by @reifi in https://github.com/daniel-sc/ng-extract-i18n-merge/issues/80#issuecomment-1782870916