The devDependency @types/node was updated from 12.7.7 to 12.7.8.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

The devDependency @typescript-eslint/eslint-plugin was updated from 2.7.0 to 2.8.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@typescript-eslint/eslint-plugin is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency @types/jest-expect-message was updated from 1.0.0 to 1.0.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/jest-expect-message is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

There have been updates to the babel7 monorepo:

• • The devDependency @babel/cli was updated from 7.6.4 to 7.7.0.

• The dependency @babel/core was updated from 7.6.4 to 7.7.0.
• The devDependency @babel/preset-env was updated from 7.6.3 to 7.7.0.
• The devDependency @babel/preset-react was updated from 7.6.3 to 7.7.0.
• The devDependency @babel/preset-typescript was updated from 7.6.0 to 7.7.0.
• The devDependency @babel/types was updated from 7.6.3 to 7.7.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

This monorepo update includes releases of one or more dependencies which all belong to the babel7 group definition.

babel7 is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

First off, love the library but couldn't help but notice one large caveat: the library won't extract strings unless the t function is being called as a property of an object (usually i18n or i18next. I think it could be beneficial to pass the translation function as an option too, so cases like this are considered:

const t = await i18n.changeLanguage('es')
console.log(t('Test string'));

or

i18n.changeLanguage('es', (err, t) => {
  console.log('Test string');
});

I was going to look into it but wasn't sure if allowing users to specify a blanket function is enough or if the way the file is parsed should be smarter so it knows the function originated from the i18next package. What are your thoughts?

The devDependency @types/node was updated from 12.7.2 to 12.7.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

There have been updates to the babel7 monorepo:

• • The devDependency @babel/cli was updated from 7.5.5 to 7.6.0.

• The dependency @babel/core was updated from 7.5.5 to 7.6.0.
• The devDependency @babel/preset-env was updated from 7.5.5 to 7.6.0.
• The devDependency @babel/preset-typescript was updated from 7.3.3 to 7.6.0.
• The devDependency @babel/types was updated from 7.5.5 to 7.6.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

This monorepo update includes releases of one or more dependencies which all belong to the babel7 group definition.

babel7 is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

I have been trying to make the babel-plugin-i18next-extract work on code thats using
decorators.

I got the following .babelrc using @babel/plugin-proposal-decorators

   ["@babel/plugin-proposal-decorators", { "legacy": true }],
   ["@babel/plugin-proposal-class-properties", { "loose": true }],
   ["@babel/plugin-proposal-object-rest-spread"],
   [
      "i18next-extract",
      {
        "locales": ["en", "nl"],
        "keyAsDefaultValue": true,
        "discardOldKeys": true,
        "i18nextInstancesNames": ["i18next", "i18n", "props"],
        "outputPath": "src/i18n/{{locale}}/{{ns}}.json"
      }
   ]

The babel-plugin-i18next-extract fails to pick up anything that contains a @withTranslation it seems

import { withTranslation } from 'react-i18next';

@withTranslation()
export default class Login extends React.Component {

  render() {
     return <span>{this.props.t("string")}</span>
  }
}

Wanted to hear if anybody got any ideas, how to bring that to work?

Is your feature request related to a problem? Please describe.

Using react-i18n hooks-style components, I've become used to the useTranslation("namespace") syntax where individual t() calls do not need a specific namespace specified since it can be inferred from the previous call.

When using a redux-thunk or redux-saga module, you aren't able to use the useTranslation() function since it does not run within a react context.

Describe the solution you'd like

There's a very similar function in i18n itself, i18next#getFixedT() that returns a TFunction using a fixed namespace (or fixed language, of which doesn't apply here), that allows the t() behavior as found in react-i18next.

Right now, babel-plugin-i18next-extract does not know how to infer namespace from this wrapper function (it does extract t() calls from it, but in the wrong namespace). Presumably, the extractors/useTranslationHook.ts extractor could be cloned to support this getFixedT() function.

Describe alternatives you've considered

• t("str", { ns: "namespace" }) a bunch of times. --> lots of repetitive namespace declarations :(

Additional context

See i18next/react-i18next#845 (comment)

Not sure if I'm missing something in the config, but it looks like when I wrap my components in compose from recompose, the namespace doesn't get picked up by babel-plugin-i18next-extract.

The code below puts the key in this translation file: default.json

import React from 'react';
import { compose } from 'recompose';
import { withTranslation } from 'react-i18next';

const SomeComponent = ({ t }) => <div>{t('mykey')}</div>;
export const SomeComponentWrapped = compose(withTranslation('namespace1'))(SomeComponent);

And this code (when removing compose) puts it in this file: namespace1.json

import React from 'react';
import { compose } from 'recompose';
import { withTranslation } from 'react-i18next';

const SomeComponent = ({ t }) => <div>{t('mykey')}</div>;
export const SomeComponentWrapped = withTranslation('namespace1')(SomeComponent);

I would expect both code snippet to put the key in the namespace1.json file.

There have been updates to the babel7 monorepo:

• • The devDependency @babel/cli was updated from 7.4.4 to 7.5.0.

• The dependency @babel/core was updated from 7.4.5 to 7.5.0.
• The devDependency @babel/preset-env was updated from 7.4.5 to 7.5.0.
• The dependency @babel/types was updated from 7.4.4 to 7.5.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

This monorepo update includes releases of one or more dependencies which all belong to the babel7 group definition.

babel7 is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

This might already be a feature and I just haven't been able to figure out how to get it work successfully, but currently in my project I am storing keys inside of JSON files, for example
login.JSON might contain:

{ "login": { "placeHolder": "Phone number", "login": "Login" } }

while my common.JSON might contain:
{ "common": { "welcome": "Welcome to the Home Menu", "language": "You are now using English", "date": "The current date is {{date, 'LLLL'}}" } }

I basically want to be able to combine these into a single JSON file with their namespaces and keys still intact, but whenever I try to have i18next-extract target JSON files, I usually get an error on the colon ':' where a semicolon is expected ';'.

The devDependency @typescript-eslint/parser was updated from 2.3.1 to 2.3.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@typescript-eslint/parser is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Currently, keys in the JSON file may be reordered by the plugin. Similarly, trailing line returns and whitespaces are always discarded when exported (which is not POSIX compliant, yet arguably a de facto standard imposed by JSON serializers in many languages and tools). This can lead to edition wars and merge conflicts in translation files, where an external tool (such as Weblate or even vim) would use a different order or would append a newline at the end.

The ideal solution would be to make the exporter preserve everything and just add keys like a human would do. We could get closer to this by relying on a lexer such as moo in order to keep a tokenized version of the original JSON file that we could use to re-export it just as it was before.

The problem of trailing whitespaces and line breaks could be addressed with way less effort just by copying in memory the trailing whitespaces and line breaks in the original file and re-adding them before exporting.

See discussions in #58

The devDependency rollup was updated from 1.18.0 to 1.19.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

rollup is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Here is my config

{
        keyAsDefaultValue: true,
        keyAsDefaultValueForDerivedKeys: false,
}

The problem is when I edit the translation file, after that, I add a new key in component, It will write to the translation file the old content with new key, the content I have edited is lost in the wild. So, I need a config for disable cache in this line

Thank you 🙏

The devDependency @typescript-eslint/parser was updated from 2.7.0 to 2.8.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@typescript-eslint/parser is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

I am using the plugin with settings:
useI18nextDefaultValue: true, keySeparator: null, discardOldKeys: true

I have a project where I'm using i18next with hooks and the t() function, and every component has its own namespace that is specified by const [t] = useTranslation('namespace').

However, only the first key used with t() in each component gets put in the proper namespace folder in extractedTranslations. The rest get shuffled into the default translation.json. Is this a bug or am I configuring something wrong?

Right now I'm just overriding with i18next-extract-mark-ns-start/stop comments to get everything in the folders I want.

There have been updates to the babel7 monorepo:

• • The devDependency @babel/cli was updated from 7.4.4 to 7.5.0.

• The dependency @babel/core was updated from 7.4.5 to 7.5.0.
• The devDependency @babel/preset-env was updated from 7.4.5 to 7.5.0.
• The dependency @babel/types was updated from 7.4.4 to 7.5.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

This monorepo update includes releases of one or more dependencies which all belong to the babel7 group definition.

babel7 is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

I can submit a PR for this, just want to know if anybody would want this. I'd like to be able to wrap the Trans component in, for example, material-ui's Typography component like so:

function Text({i18nKey, children, ...typographyProps}) {
 return (
    <Typography {...typographyProps}>
        <Trans i18nKey={i18nKey}>{children}</Trans>
    </Typography>
  );
}

and then have all usages of Text parsed as though it were <Trans />.

When I change code
<Trans>Profile</Trans>
to
<Trans>Profil</Trans>
I will receive two keys in translation.json

{
  "Profile": "",
  "Profil": ""
}

I want to have only fresh list of keys in translation file.
Can you please tell is there any way to update config to handle that?

Large multi-module applications often exist in a monorepo format where there is one canonical babel.config.js. Calls into i18next exist across the modules.

In these cases, you want to keep the translations for a given module within that module. As outputPath only supports 2 parameters, locale and ns, it's not possible to configure the output in a way that makes sense for large applications.

You could abuse the ns variable to do this, but I feel it would be better if the outputPath option accepted a function that is passed the current babel compiler state and or path to the file being operated on for the given i18next call. That would allow complete flexibility in where to output the files.

The devDependency @types/node was updated from 12.12.7 to 12.12.8.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

I've written a custom Trans component, MyTrans, and in the code it is used exactly like Trans would be (ie <MyTrans i18nKey="myKey"> Some stuff to translate </MyTrans>). Is there an option similar to the 'i18nInstanceNames' where we can specify a name for Trans extraction / would it be possible to add?

We have this jsx:

<Trans i18nKey="signup.tos">
  Mit der Registrierung des Nutzerkontos erkläre ich mich mit den{" "}
  <a
    href="https://www.polymore.com/tos"
    target="_blank"
    rel="noopener noreferrer"
  >
    AGB
  </a>{" "}
  einverstanden und bestätige die{" "}
  <a
    href="https://www.polymore.com/privacy"
    target="_blank"
    rel="noopener noreferrer"
  >
    Datenschutzerklärung
  </a>{" "}
  zur Kenntnis genommen zu haben.
</Trans>

Prettier automatically adds the spaces with {" "} to preserve them. The JSX above gets extracted as:

    "tos": "Mit der Registrierung des Nutzerkontos erkläre ich mich mit den <3>AGB</3> einverstanden und bestätige die <8>Datenschutzerklärung</8> zur Kenntnis genommen zu haben.",

Notice how it counts 3 and 8 here. Now the final translation ends up as:

Mit der Registrierung des Nutzerkontos erkläre ich mich mit den einverstanden und bestätige die zur Kenntnis genommen zu haben. zur Kenntnis genommen zu haben.

Some values got lost and some get suddenly repeated. When I overwrite the counters to 2 & 6 as below, it all works as expected:

    "tos": "Mit der Registrierung des Nutzerkontos erkläre ich mich mit den <2>AGB</2> einverstanden und bestätige die <6>Datenschutzerklärung</6> zur Kenntnis genommen zu haben.",

So it seems like the counter gets confused by the spaces.

Environment:

This is happening in a create react app, versions:

    "@babel/cli": "^7.6.0",
    "babel-plugin-i18next-extract": "^0.2.4",
    "react": "^16.8.6",
    "react-i18next": "^10.12.5",

The devDependency @types/jest was updated from 24.0.19 to 24.0.20.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

If the default value of a translation is passed as the second argument to the t function an error occurs. Example:

t('login.header', 'Sign in')

/data/Projects/project-frontend/src/pages/login/Login.tsx: Cannot use 'in' operator to search for 'context' in Sign in
    at parseTCallOptions (/data/Projects/project-frontend/node_modules/babel-plugin-i18next-extract/lib/index.js:539:34)
    at extractTCall (/data/Projects/project-frontend/node_modules/babel-plugin-i18next-extract/lib/index.js:573:16)
    at Object.extractTFunction (/data/Projects/project-frontend/node_modules/babel-plugin-i18next-extract/lib/index.js:595:13)
    at CallExpression.collect (/data/Projects/project-frontend/node_modules/babel-plugin-i18next-extract/lib/index.js:1372:32)
    at handleExtraction (/data/Projects/project-frontend/node_modules/babel-plugin-i18next-extract/lib/index.js:1355:16)
    at PluginPass.CallExpression (/data/Projects/project-frontend/node_modules/babel-plugin-i18next-extract/lib/index.js:1369:9)
    at NodePath._call (/data/Projects/project-frontend/node_modules/@babel/traverse/lib/path/context.js:53:20)
    at NodePath.call (/data/Projects/project-frontend/node_modules/@babel/traverse/lib/path/context.js:40:17)
    at NodePath.visit (/data/Projects/project-frontend/node_modules/@babel/traverse/lib/path/context.js:88:12)
    at TraversalContext.visitQueue (/data/Projects/project-frontend/node_modules/@babel/traverse/lib/context.js:118:16)

This is supported behaviour according to the i18next documentation and it would be nice if babel-plugin-18next-extract also supports this.

The devDependency prettier was updated from 1.18.2 to 1.19.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

prettier is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

There have been updates to the babel7 monorepo:

• • The devDependency @babel/cli was updated from 7.5.0 to 7.5.5.

• The dependency @babel/core was updated from 7.5.4 to 7.5.5.
• The devDependency @babel/preset-env was updated from 7.5.4 to 7.5.5.
• The dependency @babel/types was updated from 7.5.0 to 7.5.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

This monorepo update includes releases of one or more dependencies which all belong to the babel7 group definition.

babel7 is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency eslint was updated from 6.2.1 to 6.2.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

The devDependency eslint-config-prettier was updated from 6.5.0 to 6.6.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-config-prettier is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency @types/node was updated from 12.11.2 to 12.11.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

We are using ICU message format in our JSON files, and thus using the babel macros exported by react-i18next/icu.macro (Trans (different), Select, SelectOrdinal, Plural).
https://react.i18next.com/misc/using-with-icu-format

However, those macros do not properly set up the bindings in the AST correctly after swapping out the macro imports for the "normal" react-i18next Trans import, so this plugin doesn't recognize the new Trans import and doesn't extract the translations (isTransComponent and referencesImport return false because they can't find a valid binding)

I have learned my way around babel plugins and macros enough to fix some issues with the ICU macros, so that they generate the correct source code, but I've tried and tried to fix the bindings and I just can't figure out how to do it properly in the AST.

I have a workaround in referencesImport that adds an additional fallback if the bindings don't exist properly, to just look up the import in the ImportDeclarations. Would that be a welcome PR?
The other alternative is to get some help on making the ICU macro correctly update the bindings when it transforms the source code.

A bit of backstory if helpful:
I've been trying to use other command line extractors, but they choke on the curly braces and comma separated options in the ICU format, and they are just doing static parsing with acorn, so they can't take advantage of the work already in the ICU babel macro. And teaching them to recognize the ICU format seems like a lot of work.
Once I found this project, I realized how much cleaner it would be if the macro could run first, transform the source to handle the funky ICU format curly braces, then the extractor wouldn't need to know any special format, and would just have a "normal" Trans element to work with.

I seem to have that working locally as long as I have the workaround to fallback to direct inspection of the ImportDeclarations if a suitable binding can't be found.

I can provide more details or examples if that is helpful.

What solution do you think would be best for this type of situation?

I suggest adding a comment hint to "force" adding a key to the extraction.

Ex:
// i18next-extract-add-key key_name

Why it is important:

When using dynamic keys like t(`error.${code}\`), you must disable the line with // i18next-extract-disable-next-line or similar.

However, if you want to add the keys of the multiple options that will be dinamically accessed at runtime, your only option would be to directly add them to the final json files.

As we regularly use "discardOldKeys": true on the configuration, it is not possible for us to add keys that will not be removed by babel-plugin-i18next-extract.

Using the example of t(`error.${code}`) we would need to have in the translation.json file:

{ "error": { "404": "File not found", "500": "Server error" } }

This could be added in the following manner:

// i18next-extract-disable-next-line
console.log(t(`error.${code}`));

// i18next-extract-add-key error.404
// i18next-extract-add-key error.500

just a quick note - the config options in the readme say to use the option 'i18nextInstancesNames' but it should say 'i18nextInstanceNames'

Is your feature request related to a problem? Please describe.

I am using Transifex for storing all of my translations, which only supports ICU Format for pluralization.

I would love if babel-plugin-18next-extract supported an option to generate the ICU format for plurals instead of i18next's default format.

Describe the solution you'd like

What this means is that instead of generating this:

{
  "itemCount": "{{count}} item",
  "itemCount_plural": "{{count}} items"
}

I want this to be generated:

{
  "itemCount": "{count, plural, one {{count} item} other {count} items}}"
}

I suggest that a new boolean option, icuPlurals, be added to support this.

Describe alternatives you've considered

I've considered just living with the i18next format that has multiple keys instead of the one key with ICU format. This is not ideal because the Transifex translation UI does not know how to handle those keys as a plural string, but it DOES know how to handle the ICU string as plurals. Transifex presents a special UI to translators when the ICU format is correctly presented.

Additional context

The dependency i18next was updated from 19.0.0 to 19.0.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

i18next is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

See https://dev.azure.com/gilbsgilbert/babel-plugin-i18next-extract/_build/results?buildId=309

The devDependency eslint was updated from 6.6.0 to 6.7.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency @types/node was updated from 12.7.6 to 12.7.7.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

When extraction the keys, if an extraction error happens (for example, because of a dynamic key that can't be solved like t(myVariable)), all the remaining valid keys in the entire file will be ignored.

This is extra annoying when using the "discardOldKeys": true configuration, because in this case the existing translations will all be "erased".

The devDependency rollup was updated from 1.27.0 to 1.27.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

rollup is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

It looks like it tries to run mkdir everytime before adding keys to the JSON file.

 Error: EEXIST: file already exists, mkdir './extractedTranslations/en'

So it literally just parse one page, add the key correctly and then errors while parsing the next one.

My configuration is super simple, I've got a .babelrc file with

{
  "presets": ["react-app"],
  "plugins": ["i18next-extract"]
}

To get the t function, all my components have this:

const { t } = useTranslation();

When I extract translations, I get an error like this for each file that uses the hook:

babel-plugin-i18next-extract: Extraction error in <filename> at line xxx. Couldn't
evaluate i18next key. You should either make the key evaluable or skip the line
using a skip comment (/* i18next-extract-disable-line */ or
/* i18next-extract-disable-next-line */).

Where line xxx is the line shown above to get access to t.

Is there a way to have the extractor avoid this line without having to add the comment hints?

There are two specific react options in the react-i18next package which I think aren't supported as part of extraction. (from https://react.i18next.com/latest/i18next-instance)

transSupportBasicHtmlNodes: true,
transKeepBasicHtmlNodesFor: ['br', 'strong', 'i'],

With the following Trans component.

<Trans ns="onboarding" i18n={props.i18n}>
    Thank you, {{firstName: props.firstName}}!
    <br />
    Welcome to the party
</Trans>

The extraction is attempting to overwrite a key I have defined already:

-"Thank you, {{firstName}}!<br/>Welcome to the party": "Thank you, {{firstName}}!<br/>Welcome to the party"
+"Thank you, {{firstName}}!<3>Welcome to the party": "Thank you, {{firstName}}!<3>Welcome to the party",

I'm using the babel plugin as part of a webpack stack.
.babelrc

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

There have been updates to the babel7 monorepo:

• • The dependency @babel/core was updated from 7.5.5 to 7.6.0.

• The devDependency @babel/preset-env was updated from 7.5.5 to 7.6.0.
• The devDependency @babel/preset-typescript was updated from 7.3.3 to 7.6.0.
• The devDependency @babel/types was updated from 7.6.0 to 7.6.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

This monorepo update includes releases of one or more dependencies which all belong to the babel7 group definition.

babel7 is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

There have been updates to the babel7 monorepo:

• • The devDependency @babel/cli was updated from 7.5.0 to 7.5.5.

• The dependency @babel/core was updated from 7.5.4 to 7.5.5.
• The devDependency @babel/preset-env was updated from 7.5.4 to 7.5.5.
• The dependency @babel/types was updated from 7.5.0 to 7.5.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

This monorepo update includes releases of one or more dependencies which all belong to the babel7 group definition.

babel7 is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴