go/task
1
0
Fork 0
mirror of https://github.com/go-task/task.git synced 2025-08-10 22:42:19 +02:00
Code Issues Releases Activity

chore: sync translations (#1308)

Browse Source
This commit is contained in:
task-bot
2023-08-17 21:06:37 -03:00
committed by GitHub
parent 6f986af0d4
commit 6102900060
4 changed files with 71 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/api_reference.md
View File

@@ -17,7 +17,7 @@ task [--flags] [tasks...] [-- CLI_ARGS...]
:::tip
If `--` is given, all remaining arguments will be assigned to a special `CLI_ARGS` variable
`--`が渡されると、次に続く全てのパラメータは`CLI_ARGS`という特別な変数に格納されます
:::
@@ -61,20 +61,20 @@ Task will sometimes exit with specific exit codes. These codes are split into th
A full list of the exit codes and their descriptions can be found below:
| Code | Description |
| ---- | ------------------------------------------------------------ |
| 0 | Success |
| 1 | An unknown error occurred |
| 100 | No Taskfile was found |
| 101 | A Taskfile already exists when trying to initialize one |
| 102 | The Taskfile is invalid or cannot be parsed |
| 200 | The specified task could not be found |
| 201 | An error occurred while executing a command inside of a task |
| 202 | The user tried to invoke a task that is internal |
| 203 | There a multiple tasks with the same name or alias |
| 204 | A task was called too many times |
| 205 | A task was cancelled by the user |
| 206 | A task was not executed due to missing required variables |
| コード | 説明 |
| --- | ------------------------------------------------------------ |
| 0 | Success |
| 1 | An unknown error occurred |
| 100 | No Taskfile was found |
| 101 | A Taskfile already exists when trying to initialize one |
| 102 | The Taskfile is invalid or cannot be parsed |
| 200 | The specified task could not be found |
| 201 | An error occurred while executing a command inside of a task |
| 202 | The user tried to invoke a task that is internal |
| 203 | There a multiple tasks with the same name or alias |
| 204 | A task was called too many times |
| 205 | A task was cancelled by the user |
| 206 | A task was not executed due to missing required variables |
These codes can also be found in the repository in [`errors/errors.go`](https://github.com/go-task/task/blob/main/errors/errors.go).
@@ -124,11 +124,11 @@ There are some special variables that is available on the templating system:
| `TASK_VERSION` | The current version of task. |
| `ITEM` | The value of the current iteration when using the `for` property. Can be changed to a different variable name using `as:`. |
## ENV
## 環境変数
Some environment variables can be overridden to adjust Task behavior.
| ENV | Default | Description |
| 環境変数 | デフォルト値 | 説明 |
| -------------------- | ------- | ----------------------------------------------------------------------------------------------------------------- |
| `TASK_TEMP_DIR` | `.task` | Location of the temp dir. Can relative to the project like `tmp/task` or absolute like `/tmp/.task` or `~/.task`. |
| `TASK_COLOR_RESET` | `0` | Color used for white. |
@@ -140,9 +140,9 @@ Some environment variables can be overridden to adjust Task behavior.
| `TASK_COLOR_RED` | `31` | Color used for red. |
| `FORCE_COLOR` | | Force color output usage. |
## Taskfile Schema
## Taskfileのスキーマ
| Attribute | Type | Default | Description |
| 属性 | 型 | デフォルト値 | 説明 |
| ---------- | ---------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `version` | `string` | | Version of the Taskfile. The current version is `3`. |
| `output` | `string` | `interleaved` | Output mode. Available options: `interleaved`, `group` and `prefixed`. |
@@ -182,10 +182,10 @@ includes:
### Variable
| Attribute | Type | Default | Description |
| --------- | -------- | ------- | ------------------------------------------------------------------------ |
| _itself_ | `string` | | A static value that will be set to the variable. |
| `sh` | `string` | | A shell command. The output (`STDOUT`) will be assigned to the variable. |
| 属性 | 型 | デフォルト値 | 説明 |
| -------- | -------- | ------ | ------------------------------------------------------------------------ |
| _itself_ | `string` | | A static value that will be set to the variable. |
| `sh` | `string` | | A shell command. The output (`STDOUT`) will be assigned to the variable. |
:::info
@@ -202,7 +202,7 @@ vars:
### Task
| Attribute | Type | Default | Description |
| 属性 | 型 | デフォルト値 | 説明 |
| --------------- | ---------------------------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `cmds` | [`[]Command`](#command) | | A list of shell commands to be executed. |
| `deps` | [`[]Dependency`](#dependency) | | A list of dependencies of this task. Tasks defined here will run in parallel before this task. |

8
docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/contributing.md
View File

@@ -19,13 +19,13 @@ This document applies to the core [Task][task] repository _and_ [Task for Visual
- **Backwards compatibility** - Will your change break existing Taskfiles? It is much more likely that your change will merged if it backwards compatible. Is there an approach you can take that maintains this compatibility? If not, consider opening an issue first so that API changes can be discussed before you invest your time into a PR.
- **Experiments** - If there is no way to make your change backward compatible then there is a procedure to introduce breaking changes into minor versions. We call these "\[experiments\]\[experiments\]". If you're intending to work on an experiment, then please read the \[experiments workflow\]\[experiments-workflow\] document carefully and submit a proposal first.
## 1. Setup
## 1. セットアップ
- **Go** - Task is written in [Go][go]. We always support the latest two major Go versions, so make sure your version is recent enough.
- **Go** - Taskは[Go][go]で書かれています。 We always support the latest two major Go versions, so make sure your version is recent enough.
- **Node.js** - [Node.js][nodejs] is used to host Task's documentation server and is required if you want to run this server locally. It is also required if you want to contribute to the Visual Studio Code extension.
- **Yarn** - [Yarn][yarn] is the Node.js package manager used by Task.
## 2. Making changes
## 2. 変更を加える
- **Code style** - Try to maintain the existing code style where possible. Go code should be formatted by [`gofumpt`][gofumpt] and linted using [`golangci-lint`][golangci-lint]. Any Markdown or TypeScript files should be formatted and linted by [Prettier][prettier]. This style is enforced by our CI to ensure that we have a consistent style across the project. You can use the `task lint` command to lint the code locally and the `task lint:fix` command to automatically fix any issues that are found.
- **Documentation** - Ensure that you add/update any relevant documentation. See the [updating documentation](#updating-documentation) section below.
@@ -37,7 +37,7 @@ To run Task with working changes, you can use `go run ./cmd/task`. To run a deve
To run Task for Visual Studio Code, you can open the project in VSCode and hit F5 (or whatever you debug keybind is set to). This will open a new VSCode window with the extension running. Debugging this way is recommended as it will allow you to set breakpoints and step through the code. Otherwise, you can run `task package` which will generate a `.vsix` file that can be used to manually install the extension.
### Updating documentation
### ドキュメントの更新
Task uses [Docusaurus][docusaurus] to host a documentation server. The code for this is located in the core Task repository. This can be setup and run locally by using `task docs` (requires `nodejs` & `yarn`). All content is written in Markdown and is located in the `docs/docs` directory. All Markdown documents should have an 80 character line wrap limit (enforced by Prettier).

22
docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/releasing.md
View File

@@ -3,36 +3,36 @@ slug: /releasing/
sidebar_position: 13
---
# Releasing
# リリース
The release process of Task is done with the help of [GoReleaser][goreleaser]. You can test the release process locally by calling the `test-release` task of the Taskfile.
Taskのリリースプロセスは[GoReleaser][goreleaser]の助けを借りて行われます。 ローカルでリリースプロセスをテストするには、Taskfileの`test-release`タスクを呼び出します。
[GitHub Actions](https://github.com/go-task/task/actions) should release artifacts automatically when a new Git tag is pushed to `main` branch (raw executables and DEB and RPM packages).
[GitHub Actions](https://github.com/go-task/task/actions)は、新しいGitタグが`main`ブランチにプッシュされると、自動的に成果物(実行ファイルおよびDEBとRPMパッケージ)をリリースするはずです。
Since v3.15.0, raw executables can also be reproduced and verified locally by checking out a specific tag and calling `goreleaser build`, using the Go version defined in the above GitHub Actions.
v3.15.0以降、特定のタグをチェックアウトし、上記のGitHub Actionsで定義されたGoバージョンを使用して`goreleaser build`を呼び出すことで、実行ファイルをローカルでも再現して検証することができます。
# Homebrew
Goreleaser will automatically push a new commit to the [Formula/go-task.rb][gotaskrb] file in the [Homebrew tap][homebrewtap] repository to release the new version.
Goreleaserは新しいバージョンをリリースするために、[Homebrew tap][homebrewtap]リポジトリの[Formula/go-task.rb][gotaskrb]に新しいコミットを自動的にプッシュします。
# npm
To release to npm update the version in the [`package.json`][packagejson] file and then run `task npm:publish` to push it.
npmにリリースするには、[`package.json`][packagejson]でバージョンを更新し、`task npm:publish`を実行してプッシュします。
# Snapcraft
The [snap package][snappackage] requires to manual steps to release a new version:
[snapパッケージ][snappackage]をリリースするには、マニュアルのステップが必要です:
- Updating the current version on [snapcraft.yaml][snapcraftyaml].
- Moving both `amd64`, `armhf` and `arm64` new artifacts to the stable channel on the [Snapcraft dashboard][snapcraftdashboard].
- [snapcraft.yaml][snapcraftyaml]で現在のバージョンを更新する。
- [Snapcraftダッシュボード][snapcraftdashboard]で、`amd64`、`armhf`、`arm64`の新しい成果物を全てstableチャンネルに移動させる。
# Scoop
Scoop is a command-line package manager for the Windows operating system. Scoop package manifests are maintained by the community. Scoop owners usually take care of updating versions there by editing [this file](https://github.com/ScoopInstaller/Main/blob/master/bucket/task.json). If you think its Task version is outdated, open an issue to let us know.
ScoopはWindowsオペレーティングシステム用のコマンドラインパッケージマネージャーです。 Scoopパッケージマニフェストはコミュニティによって管理されています。 Scoopの所有者は通常、[このファイル](https://github.com/ScoopInstaller/Main/blob/master/bucket/task.json)を編集することでバージョンを更新します。 Taskのバージョンが古くなっていると思われる場合は、Issueを作成してお知らせください。
# Nix
Nix is a community owned installation method. Nix package maintainers usually take care of updating versions there by editing [this file](https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/tools/go-task/default.nix). If you think its Task version is outdated, open an issue to let us know.
Nixはコミュニティが所有するインストール方法です。 Nixパッケージのメンテナは通常、[このファイル](https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/tools/go-task/default.nix)を編集してバージョンを更新します。 Taskのバージョンが古くなっていると思われる場合は、Issueを作成してお知らせください。
<!-- prettier-ignore-start -->

64
docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/usage.md
View File

@@ -198,7 +198,7 @@ tasks:
## 他のTaskfileをインクルードする
If you want to share tasks between different projects (Taskfiles), you can use the importing mechanism to include other Taskfiles using the `includes` keyword:
異なるプロジェクト(Taskfile)間でタスクを共有したい場合、`includes`キーワードを利用して他のTaskfileをインクルードするためのインポートメカニズムを利用できます。
```yaml
version: '3'
@@ -208,13 +208,13 @@ includes:
docker: ./DockerTasks.yml
```
The tasks described in the given Taskfiles will be available with the informed namespace. So, you'd call `task docs:serve` to run the `serve` task from `documentation/Taskfile.yml` or `task docker:build` to run the `build` task from the `DockerTasks.yml` file.
指定されたTaskfileに記述されたタスクは、指定された名前空間で利用できるようになります。 なので、`documentation/Taskfile.yml`から`serve`タスクを実行するには、`task docs:serve`を呼び、`DockerTasks.yml`から`build`タスクを実行するには、`task docker:build`を呼び出します。
Relative paths are resolved relative to the directory containing the including Taskfile.
相対パスはインクルードするTaskfileが含まれているディレクトリに対して解決されます。
### OS-specific Taskfiles
### OS固有のTaskfile
With `version: '2'`, task automatically includes any `Taskfile_{{OS}}.yml` if it exists (for example: `Taskfile_windows.yml`, `Taskfile_linux.yml` or `Taskfile_darwin.yml`). Since this behavior was a bit too implicit, it was removed on version 3, but you still can have a similar behavior by explicitly importing these files:
`version: '2'`では、taskは`Taskfile_{{OS}}.yml`が存在する場合、自動的にインクルードします。(例えば: `Taskfile_windows.yml`、`Taskfile_linux.yml`、`Taskfile_darwin.yml`など) この挙動は少し分かりづらかったため、バージョン3で削除されましたが、これらのファイルを明示的にインポートすることで同様の挙動を持たせることができます。
```yaml
version: '3'
@@ -223,9 +223,9 @@ includes:
build: ./Taskfile_{{OS}}.yml
```
### Directory of included Taskfile
### インクルードされたTaskfileのディレクトリ
By default, included Taskfile's tasks are run in the current directory, even if the Taskfile is in another directory, but you can force its tasks to run in another directory by using this alternative syntax:
デフォルトでは、インクルードされたTaskfileのタスクは、Taskfileが別のディレクトリにあったとしても、現在のディレクトリで実行されます。 ですが、代替構文を利用することで、強制的にタスクを別のディレクトリで実行させることができます:
```yaml
version: '3'
@@ -238,13 +238,13 @@ includes:
:::info
The included Taskfiles must be using the same schema version as the main Taskfile uses.
インクルードされるTaskfileは、メインのTaskfileが使用しているスキーマバージョンと同様のものである必要があります。
:::
### Optional includes
### 任意のインクルード
Includes marked as optional will allow Task to continue execution as normal if the included file is missing.
オプショナルとしてマークされたインクルードは、インクルードされるファイルが見つからない場合でも、タスクの実行を通常通り続行させます。
```yaml
version: '3'
@@ -261,9 +261,9 @@ tasks:
./tests/Taskfile.yml does not exist"
```
### Internal includes
### 内部のインクルード
Includes marked as internal will set all the tasks of the included file to be internal as well (see the [Internal tasks](#internal-tasks) section below). This is useful when including utility tasks that are not intended to be used directly by the user.
インターナルとしてマークされたインクルードは、インクルードされるファイルの全てのタスクもインターナルとします(下記の [インターナルタスク](#internal-tasks)セクションを参照)。 これはユーザーが直接使用することを意図していないユーティリティタスクをインクルードする際に便利です。
```yaml
version: '3'
@@ -274,9 +274,9 @@ includes:
internal: true
```
### Vars of included Taskfiles
### インクルードされるTaskfileの変数
You can also specify variables when including a Taskfile. This may be useful for having reusable Taskfile that can be tweaked or even included more than once:
Taskfileをインクルードする際に変数を使用することもできます。 これは一度に複数回インクルードするような再利用可能なTaskfileを持つのに便利です。
```yaml
version: '3'
@@ -1019,11 +1019,11 @@ tasks:
- echo 'bar'
```
## Forwarding CLI arguments to commands
## CLI引数をコマンドにフォワード
If `--` is given in the CLI, all following parameters are added to a special `.CLI_ARGS` variable. This is useful to forward arguments to another command.
CLIで`--`が渡されると、次に続く全てのパラメータが、`.CLI_ARGS`という特別な変数に追加されます。 これは引数を別のコマンドにフォワードするのに便利です。
The below example will run `yarn install`.
以下の例では`yarn install`を実行します。
```bash
$ task yarn -- install
@@ -1038,7 +1038,7 @@ tasks:
- yarn {{.CLI_ARGS}}
```
## Doing task cleanup with `defer`
## `defer`を使ったタスクのクリーンアップ
With the `defer` keyword, it's possible to schedule cleanup to be run once the task finishes. The difference with just putting it as the last command is that this command will run even when the task fails.
@@ -1076,7 +1076,7 @@ Due to the nature of how the [Go's own `defer` work](https://go.dev/tour/flowcon
:::
## Go's template engine
## Goのテンプレートエンジン
Task parse commands as [Go's template engine][gotemplate] before executing them. Variables are accessible through dot syntax (`.VARNAME`).
@@ -1103,7 +1103,7 @@ Task also adds the following functions:
- `shellQuote`: Quotes a string to make it safe for use in shell scripts. Task uses [this Go function](https://pkg.go.dev/mvdan.cc/sh/v3@v3.4.0/syntax#Quote) for this. The Bash dialect is assumed.
- `splitArgs`: Splits a string as if it were a command's arguments. Task uses [this Go function](https://pkg.go.dev/mvdan.cc/sh/v3@v3.4.0/shell#Fields)
Example:
例:
```yaml
version: '3'
@@ -1128,7 +1128,7 @@ tasks:
{{end}}EOF
```
## Help
## ヘルプ
Running `task --list` (or `task -l`) lists all tasks with a description. The following Taskfile:
@@ -1381,11 +1381,11 @@ tasks:
- echo "This will print nothing" > /dev/null
```
## Dry run mode
## ドライランモード
Dry run mode (`--dry`) compiles and steps through each task, printing the commands that would be run without executing them. This is useful for debugging your Taskfiles.
## Ignore errors
## エラーを無視する
You have the option to ignore errors during command execution. Given the following Taskfile:
@@ -1414,7 +1414,7 @@ tasks:
`ignore_error` can also be set for a task, which means errors will be suppressed for all commands. Nevertheless, keep in mind that this option will not propagate to other tasks called either by `deps` or `cmds`!
## Output syntax
## 出力構文
By default, Task just redirects the STDOUT and STDERR of the running commands to the shell in real-time. This is good for having live feedback for logging printed by commands, but the output can become messy if you have multiple commands running simultaneously and printing lots of stuff.
@@ -1523,9 +1523,9 @@ The `output` option can also be specified by the `--output` or `-o` flags.
## 対話型CLIアプリケーション
When running interactive CLI applications inside Task they can sometimes behave weirdly, especially when the [output mode](#output-syntax) is set to something other than `interleaved` (the default), or when interactive apps are run in parallel with other tasks.
Task内で対話型CLIアプリケーションを実行する際、時折変な挙動をすることがあり、特に[出力モード](#output-syntax)が`交互`(デフォルト)に設定されていない、または対話型アプリが他のタスクと並行して実行される場合に発生します。
The `interactive: true` tells Task this is an interactive application and Task will try to optimize for it:
`interactive: true`は、これが対話型アプリケーションであることをTaskに伝え、Taskはそれに最適化しようとします:
```yaml
version: '3'
@@ -1537,11 +1537,11 @@ tasks:
interactive: true
```
If you still have problems running an interactive app through Task, please open an issue about it.
対話側アプリをTaskを通して実行する際に依然として問題がある場合は、それについてのIssueを作ってください。
## Short task syntax
## 短いタスク構文
Starting on Task v3, you can now write tasks with a shorter syntax if they have the default settings (e.g. no custom `env:`, `vars:`, `desc:`, `silent:` , etc):
Task v3から、デフォルトの設定(例: カスタムな `env:`、`vars`、`desc:`、`silent:`などがない場合)を持つタスクは、より短い構文で記述することができます:
```yaml
version: '3'
@@ -1556,7 +1556,7 @@ tasks:
## `set`と`shopt`
It's possible to specify options to the [`set`](https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html) and [`shopt`](https://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html) builtins. This can be added at global, task or command level.
[`set`](https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html)および[`shopt`](https://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html)の組み込みコマンドにオプションを渡すことが可能です。 これは、グローバル、タスク、またはコマンドのそれぞれのレベルで設定することができます。
```yaml
version: '3'
@@ -1571,11 +1571,11 @@ tasks:
:::info
Keep in mind that not all options are available in the [shell interpreter library](https://github.com/mvdan/sh) that Task uses.
Taskが使用する[シェルインタプリタライブラリ](https://github.com/mvdan/sh)で利用可能なオプションは全てがあるわけではないことに注意してください。
:::
## Watch tasks
## タスクのウォッチ
With the flags `--watch` or `-w` task will watch for file changes and run the task again. This requires the `sources` attribute to be given, so task knows which files to watch.