Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify and allow Private Terms #130

Open
Pike opened this issue May 25, 2018 · 2 comments
Open

Specify and allow Private Terms #130

Pike opened this issue May 25, 2018 · 2 comments
Labels
FUTURE Ideas and requests to consider after Fluent 1.0 syntax

Comments

@Pike
Copy link
Contributor

Pike commented May 25, 2018

We've used the term private in a lot of ways by now, I'd like us to re-introduce it for entries that are internal to a particular localization.

The primary use-cases right now would be platform-dependent phrases for example in Japanese.

We first talked about this in #62.

@stasm
Copy link
Contributor

stasm commented May 25, 2018

To make sure we're on the same page, do you mean private as in not checked by tools like compare-locales?

#62 mentions a grammar solution to this: --private-term.

If the only difference between -term and --private-term is the compare-locales use-case, could we achieve the same result with a @private decorator/semantic comment? (#16).

@Pike
Copy link
Contributor Author

Pike commented May 25, 2018

I mean private in the sense that

  • they're localizer-generated (i.e., pontoon),
  • or even reference-localization specific (i.e. pontoon would not require a localization thereof), interesting problem around what to localize then
  • they're not reported as missing or obsolete
  • they're checked for validity and errors
  • they're including in term ref checks

Their specification would likely also entail best practices on where to add then when a tool like pontoon is used to create one.

As for implementation, I'm not sure if I like or dislike semantic comments for that. Using semantic comments is the invitation to use group or file comments to denote private terms in a file, or a kind of glossary file globally. That's tempting, but that also makes it more involved to write tooling support for it.

And Semantic comments have the downside of not being ready-to-use right now :-/

@stasm stasm added the FUTURE Ideas and requests to consider after Fluent 1.0 label May 25, 2018
@stasm stasm added the syntax label Oct 16, 2018
SirNickolas added a commit to SirNickolas/SublimeFluent that referenced this issue Mar 25, 2022
These are experimental, not yet standardized constructs. The syntax for
dynamic term references (-$term-var) was taken as chosen by an unofficial
Perl 6 Fluent implementation.

projectfluent/fluent#130
projectfluent/fluent#80 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FUTURE Ideas and requests to consider after Fluent 1.0 syntax
Projects
None yet
Development

No branches or pull requests

2 participants