Peter Siska

>Taiko isn't actively maintained/fixing bugs That's a bummer :/

@JounQin Many CI environments normally set the `CI` variable by default (https://docs.travis-ci.com/user/environment-variables/#default-environment-variables, https://docs.travis-ci.com/user/environment-variables/#default-environment-variables, https://docs.github.com/en/actions/learn-github-actions/variables), so it would be best to also support this by default.

Yes, probably. But are there instances where you'd want the hooks to be installed in a CI environment?

Yes, I understand. Breaking changes can happen though, so I'd be inclined to still vote for handling `CI` env vars, since this is what many other tools do.

Husky uses a custom env var for this: https://typicode.github.io/husky/how-to.html#ci-server-and-docker Maybe it is easier to off-load the responsibility of skipping to the user all together. Using something like [is-ci](https://github.com/watson/is-ci) is pretty...

That‘s how I meant it: using `is-ci` should probably be outside of this library‘s scope, since it is easy enough.

It seems we're talking about two different things… The way I meant it is what is in the husky docs. They DO NOT include the `is-ci` package in husky, but...

Happening on our Symfony instance as well. Is there a best practice for reporting a bug with a working example?

Is there a way to disable removal of manually added translations? That way, we can at least add the menu translations manually and keep them when re-running the extraction. EDIT:...

Perfectly fine, let me know if there's something fishy and enjoy your vacation. On 09.02.2013, at 08:33, Manuel Reinhard [email protected] wrote: Awesome, thanks! You just caught me at the beginning...