Support translate-attr directive

[jebner]

Problem

With version 2.12, angular-translate introduced a standalone translate-attr directive (see this commit) which deprecates/replaces the previously used translate-attr-ATTRIBUTE_NAME directive. webpack-angular-translate does not seem to support the new directive and therfore, those translations are not registered in the json file. As a workaround, we have to register those translations manually using i18n.registerTranslation.

Examples

To translate the attribute alt on an image, before angular-translate 2.12 this syntax was used:

<img src="mylogo.png" translate translate-attr-alt="LOGO"></img>

Since angular-translate 2.12 that directive is deprecated and replaced with:

<img src="mylogo.png" translate-attr="{ alt: 'LOGO' }"></img>

It is also possible to translate multiple attributes of an element:

<img src="mylogo.png" translate-attr="{ alt: 'LOGO', title: 'TITLE' }">

Desired Behaviour

The plugin extract the translation keys from the new translate-attr directive and writes them into the json file.

Would it be possible to also support this translate-attr directive?

Thank you!

[MichaReiser]

Hi @jebner. Thanks for raising the issue that the support for translate-attr is missing today. I'm no longer using the plugin myself and won't have time to implement the support anytime soon but are happy to merge a PR or add you as a contributor.

I had a quick glance over the code and believe that you should be able to implement the desired functionality by chaning the translateDirectiveTranslationExtractor. The extractor is called for every angular element (with all attributes) and gets a context that allows you to register a new translation including a default text. It should be sufficient to check if the translate-attr exists and if so, register all key/value pairs by calling registerTranslation.

The hardest part is most likely to handle all the edge cases, e.g. when a user passes a scope variable.

[sambernet]

I think we would be fine with a similar approach to the existing edge cases. E.g. handle the basic cases (covering most of the situations) and error out in more complex cases that can't (yet...) be handled, unless something like the existing suppress-dynamic-translation-error is added in the HTML. In this case, the instance would be logged as a warning and skipped.

[MichaReiser]

@sambernet that makes a lot of sense to me. I believe the suppress-dynamic-translation-error should already be handled outside of the extractor so that we can inherit this behavior for free as well. Let me add you and @jebner as contributors.

[MichaReiser]

I invited you both as collaborators. Do you @sambernet or @jebner have an NPM account so that I can give you publishing right.

[MichaReiser]

I may have some time to work on this in late May / beginning of June if someone's willing to fund it.