Contexts are not extracted when the value is a string literal

[culshaw]

Describe the bug

The t function doesn't extract a custom context from the t function options parameter. It only pulls from the defaults (male / female)

How to reproduce

Using props.t via the HOC react-i18next approach to extract a string (with keyAsDefaultValue) where also supplying context via the options parameter to take the default value and append the context to the extracted key.

{this.props.t("What is your full business name?", {
    context: "describe"
})}

Babel configuration:

"plugins": [
                [
                    "i18next-extract",
                    {
                        "contextSeparator": "__",
                        "defaultContexts": [""],
                        "defaultNS": "common",
                        "locales": ["en_GB", "de_DE"],
                        "jsonSpace": 4,
                        "keySeparator": null,
                        "nsSeparator": null,
                        "keyAsDefaultValue": ["en_GB"],
                        "keyAsDefaultValueForDerivedKeys": false,
                        "tFunctionNames": ["i18next.t", "i18n.t", "this.props.t", "props.t", "t"],
                        "outputPath": "./{{locale}}/{{ns}}.json"
                    }
                ]
            ]

Reproduction:

Provide a code snippet that produce the unexpected result.
Try to isolate the bug and make this snippet as simple, concise and self-explanatory as possible.

Expected behaviour

"What is your full business name?__describe": "What is your full business name?"

What actually happens (with defaultContexts as [""])

"What is your full business name?": "What is your full business name?"

(with defaultContexts key removed)

"What is your full business name?": "What is your full business name?",
"What is your full business name?": "What is your full business name?",
"What is your full business name?__female": "",
"What is your full business name?__male": "",

Your environment

• OS (e.g. ArchLinux): ? OSX
• Plugin version (e.g. 0.3.0): ? 0.5.0
• Node version (e.g. 12.13.0): ? 10.15.0

Additional context

I would absolutely love to help fix this, but I haven't a clue where to begin!

[gilbsgilbs]

Hi,

Thanks for raising an issue. I'm hesitant to consider this as a bug because it looks like a very marginal use-case and I definitely don't want to run into the hassle of parsing context values. 99.9% of the time, one will use a variable as context value and not a plain string literal, so trying to parse the value statically is highly likely to be pointless.

In any case, comment hints are the way to go for contexts, even if it seems redundant here:

{/* i18next-extract-mark-context-next-line ["describe"] */}
{this.props.t("What is your full business name?", {
    context: "describe"
})}

I think we'll stick to this solution for now, unless you can provide a very compelling reason to be smarter. However, docs improvements are always welcome if this solution was unobvious. Feel free to submit a PR if you think it could be made clearer.

(Meme approved :heavy_check_mark: :smile:)

[gilbsgilbs]

Apparently, this might be kind of confusing to users: https://stackoverflow.com/questions/58270942/context-added-to-translation-tags-do-not-pull-through-correctly-to-extracted-tra/59702861 . Let's reopen.

[urrri]

I also think it is very necessary feature. Adding extraction comment in each place is overkill if the context value is already explicitly defined. Just 2 additions:

1. Somehow to define whether need default (means clean, non-context) translation too. Maybe as another flag in settings, or if in defaultContexts present "".
2. If there is entry with implicit context (as variable) - add all default contexts.

[ritxweb]

Hi! It's still not working:

key_option1: "key on option 1", key_option2: "key on option 2"

t("key", { context: "option1" }) // NOT TRANSLATED

Any solution? Thanks!!