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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

returnDetails should return parameters used to drive interpolation #2046

Closed
robross0606 opened this issue Sep 28, 2023 · 0 comments 路 Fixed by #2053
Closed

returnDetails should return parameters used to drive interpolation #2046

robross0606 opened this issue Sep 28, 2023 · 0 comments 路 Fixed by #2053

Comments

@robross0606
Copy link

robross0606 commented Sep 28, 2023

馃殌 Feature Proposal

When returnDetails is set to true, the returned object includes the key, language, namespace and other important details. However, it does not include any parameter values passed to t() and used in interpolation.

Motivation

In order to understand what drove a particular translation, the details include everything you would need to trace the specific resource being used to drive res. Everything, that is, except interpolated parameters specifically passed into t(). These values are crucial details about the resolved translation if interpolation was involved.

Example

In our specific situation, we need to be able to "pass thru" the context data for a message from a back end GraphQL API through to the API client so it might drive their own localization upon ingesting our API responses. In other words, if we do this:

{
  "hello": {
    "world": "Hello, {{user}}!"
  }
}
const translation = ctx.i18n.t('hello.world', { returnDetails: true, user: 'John  Smith'})

The results in translation should be something like:

'{
  "res": "Hello, John Smith!",
  "usedKey": "hello.world",
  "usedParams": {
    "user": "John Smith"
   },
  "exactUsedKey": "hello.world",
  "usedLng": "en",
  "usedNS": "my-namespace"
}'

This is similar to returnObjects in concept, but more "pass thru" in that we shouldn't have to declare every parameter and the structure of the returned object in our en.json file. This way, we can structure a post-processor to massage the translation to match our GraphQL schema in the resolver.

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

Successfully merging a pull request may close this issue.

1 participant