1638239 - [terminology] Fluent variables and attributes (data-110n-name) should be excluded from terminology highlighting

Status: RESOLVED FIXED

(Webtools Graveyard :: Pontoon, defect, P2)

Description

[Francesco Lodolo [:flod]]

Example

{ $version } ({ $bits }-bit)

Terminology highlights the word version in $version. As a consequence:

• You can't click the placeable to copy it in your translation.
• This has already caused an error, where a localizer translated the variable name.

Comment 1

[Matjaz Horvat [:mathjazz]]

I wonder what's the optimal solution here?

1. To not highlight terms within placeables.
2. To be able to highlight both, i.e. terms within placeables, placeables within terms and even terms that span from within the placeble and outside of it.

Comment 2

[Francesco Lodolo [:flod]]

(In reply to Matjaz Horvat [:mathjazz] from comment #1)

To be able to highlight both, i.e. terms within placeables, placeables within terms and even terms that span from within the placeble and outside of it.

Can you think of an example of a placeable that contains localizable content? I have the feeling we might be using placeables for different things (I'm thinking of variables).

Comment 3

[Matjaz Horvat [:mathjazz]]

Some of them have the potential to include localizable content:
https://github.com/mozilla/pontoon/blob/master/frontend/src/core/placeable/parsers/altAttribute.js
https://github.com/mozilla/pontoon/blob/master/frontend/src/core/placeable/parsers/fluentParametrizedTerm.js
https://github.com/mozilla/pontoon/blob/master/frontend/src/core/placeable/parsers/fluentString.js

If we look at placeables as non-localizable content (that can be copied into the editor unchanged), I guess there's also no reason in showing term definitions for content within placeables. I which case we should be able to go ahead with Solution #1.

Comment 4

[Axel Hecht [:Pike]]

This is about placeables in the FTL files. Those just have plain strings for the title attribute of the mark elements.

In an abstract sense, only positional arguments and keyword values to CALL expressions are content that can be shown in the resulting string from inside placeables. And string literals, too. I think that's it. Stas?

In practical terms (sic), I think it should be OK to just exclude placeables altogether.

Comment 5

[Staś Małolepszy :stas]

(In reply to Axel Hecht [:Pike] from comment #4)

In an abstract sense, only positional arguments and keyword values to CALL expressions are content that can be shown in the resulting string from inside placeables. And string literals, too. I think that's it. Stas?

I think that's correct, assuming we don't count variants of select expressions, which technically are in placeables, too.

In practical terms (sic), I think it should be OK to just exclude placeables altogether.

Would it be enough to only include TextElements instead?

Comment 6

[Francesco Lodolo [:flod]]

Not sure if it should be a different bug, but we're having the same problem with data-l10n-name attributes, where l10n is marked as a term.
https://pontoon.mozilla.org/pt-BR/firefox/browser/browser/aboutLogins.ftl/?search=about-logins-intro-import2&string=213245

Comment 7

[Axel Hecht [:Pike]]

Maybe this is an order of evaluation thing? I.e., do terminology detection last?

Worth highlighting that we don't have one definition for markup in Fluent, we can't support much there.

Alternative thought, should terminology have an exclude-list of sorts? Sounds like something genuinely useful to be able to mark composed words for which the term definition doesn't apply?

Comment 8

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/pontoon/pull/1661