Remove tags about fluent HOT 11 CLOSED

I'm totally fine with having this be a linter check.

from fluent.

One thing we're doing with tags is that we're taking them out of the data space that can be exposed publicly. You can't return the żeński to the calling program.

So I disagree that this is just a tooling feature.

from fluent.

Do we really need to enforce this level of protection in the runtime? I could see a linter rule which warns against interpolating attribute expressions on private messages (foo = { -brand-name.gender }), but even then I think it should not be an error.

from fluent.

I strongly think that exposing language-internal traits is an error. We've had people try to abuse language-internal traits over and over, and I also think that making it clear on the syntax level that that's not OK is a win.

Sorry for using traits, but we're not using that word right now, so I use it to mean tags/attributes/something.

from fluent.

One cannot retrieve a private message from MessageContext, so the only way to someone could attempt to retrieve an attribute on a private message is via interpolation.

If that's the case, we could address Pike's concern by simply forbidding AttributeExpressions on private messages outside of SelectExpressions selector.

from fluent.

I disagree on "simply" :) There is a lot of conditions in forbid AttributeExpressions on private messages outside of SelectExpressions selector which makes this rule hard to internalize. I'd prefer to move this check into a linter.

The syntax should help localizers create good localizations without imposing too many strict rules. At any point a localizer can create a bad translation: they can write About { -brand-name.gender } just as they can write About Totally Not Brand Name. Not everything that parses must make immediate sense.

from fluent.

Do we really need to enforce this level of protection in the runtime?

Yes, we need to handle this at runtime. If it's legal syntax, people can and likely will put it in files, and we need to have defined runtime behavior.

Linters are things that we run optionally. Hopefully people run it, but we can't enforce that they do in any way.

from fluent.

Before we discuss the implementation in #69, I'd like to get sign-offs on this proposal from the majority of the core team. Please comment in this thread and tick the box next to your name if you give this proposal a green light.

• @Pike
• @stasm
• @zbraniecki

from fluent.

r+

from fluent.

r+

from fluent.

We talked about this on the tech call yesterday, and zibi and I share the concern about runtime leakage, though we have different severities for it.

As we've seen folks try to do interesting stuff with hashes in l20n files, we'll want a runtime catch for this.

from fluent.