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

Feature request: Support stand-alone translation keys in JS/TS #658

Open
IgnaceMaes opened this issue Apr 19, 2024 · 0 comments
Open

Feature request: Support stand-alone translation keys in JS/TS #658

IgnaceMaes opened this issue Apr 19, 2024 · 0 comments

Comments

@IgnaceMaes
Copy link

Support stand-alone translation keys

Use case

In JavaScript (or TypeScript), translation keys are discovered by matching on this.intl.t('') and t('') function calls. This assumes the keys are translated at the same place where the key is defined.

A common use case is to define constants in separate files. Here there might not be any context of the intl API. As those keys are not being discovered, the current way to work around this is to whitelist them.

e.g.:

// some-consts.js
const FOO = {
  A: 'x.100',
  B: 'x.200',
  C: 'x.300',
};

// some-component.js
get fooName() {
  return this.intl.t(FOO[this.args.type]);
}

Running intl-analyzer fails as translation keys aren't picked up.

Proposal

Have a util to mark stand-alone translation keys so they can be discovered.

// Tagged template util:
function translationKey(strings: TemplateStringsArray) {
  return strings[0];
}

Usage:

// some-consts.js
const FOO = {
  A: translationKey`x.100`,
  B: translationKey`x.200`,
  C: translationKey`x.300`,
};

// some-component.js
get fooName() {
  return this.intl.t(FOO[this.args.type]);
}

Alternatives

  • Use regular function calls instead of tagged templated
    • But that syntax would be complex to read and prone to errors as it needs to be executed
    • e.g. translationKey('x.100')()
  • Strip tagged templates via a Babel plugin so there's no runtime overhead. But as it's minimal and would make this way more complex that seems undesired.
  • Not support this and require rewrites?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant