Support context-extraction from filters.

[rubenv]

trafficstars

See rubenv/angular-gettext#103

Pull requests welcome

{{"1 car" | translate:"context"}}

[gabegorelick]

Is there any other parameter you'd want to pass as the first argument to the filter? My only concern is that filter parameters don't really scale to large permutations of arguments, and there's a lot of ways you can traditionally call gettext (context, plurals, etc.)

[rubenv]

You're right: filters don't scale well.

I don't like them, but we need them for some cases (e.g. translated attributes).

See https://github.com/rubenv/angular-gettext-tools/issues/39: we'll need a second filter to do plurals.

[gabegorelick]

Can you pass object literals to filters? Something like translate:{context: ""}? It's future-proof and still extractable.

[rubenv]

Yup, that could work as well. I'd be cool with that (it means we only need one filter!).

We'd need to change the filter implementation as well then.

[gabegorelick]

It's also not too late to remove the {{'' | translate:'context' }} syntax if we decide object literals is better.

[gabegorelick]

angular-translate uses object literal-strings: https://github.com/angular-translate/angular-translate/wiki/Dynamize-your-translations#parametrizing-the-translate-filter

We probably have to remove support for strings because angular doesn't like object literals passed to filters.

[rubenv]

@gabegorelick I'm considering a release of angular-gettext without context support in filters. This gives us an opportunity to get the fixes out there and gives us more time to figure out how to best move forward with filters.

Are you OK with that?

[gabegorelick]

Fine by me.

On Tuesday, December 16, 2014, Ruben Vermeersch [email protected] wrote:

@gabegorelick https://github.com/gabegorelick I'm considering a release of angular-gettext without context support in filters. This gives us an opportunity to get the fixes out there and gives us more time to figure out how to best move forward with filters.

Are you OK with that?

— Reply to this email directly or view it on GitHub https://github.com/rubenv/angular-gettext-tools/issues/63#issuecomment-67125620 .

[rubenv]

Moving to 2.1.

[yankee42]

As you can see I created a pull request for the first proposal ('text'|translate:'context').

So far there was some criticism about extensibility, so here are some options:

// This assumes that `comment` is a do nothing filter that has only meaning for the extractor:
{{'text'|translateComment:'someComment'|translate:'context'}}
// For people who want to be explicit even this could be added:
{{'text'|translateComment:'someComment'|translateContext:'context'|translate}}
// If it is required that `translate` is always the last filter in the list, then this could even be used to pass information along at runtime by augmenting/wrapping the original object.

// For object literals one could theoretically write (I admit that this is not the prettiest, but passing json as string directly is neither pretty in my opinion):
{{'text'|translate:('{context:\'context\'}'|parseJson)}}

Or actually how about imitating the gettext API more closely and implement filters pgettext, ngettext etc.? After all this is one of the advantages of using a standardized system so that everyone who is familiar with gettext can use the library intuitively.

@gabegorelick: Why do you say:

angular doesn't like object literals passed to filters

As far as I know (and I just tested it) that works great. What is the problem there?