diff --git a/guides/embed/ui-elements/explorer.md b/guides/embed/ui-elements/explorer.md index eb9d0c657..cc63d4e86 100644 --- a/guides/embed/ui-elements/explorer.md +++ b/guides/embed/ui-elements/explorer.md @@ -27,7 +27,7 @@ fullyTranslated: true Box Content Explorer UI Elementを使用すると、開発者は、Boxに保存されているコンテンツのフォルダビューをデスクトップまたはモバイルウェブアプリに埋め込むことができます。ライブラリはBox APIを介して指定されたフォルダに関する情報を取得した後、メインのBoxウェブアプリと同様にそのコンテンツをフォルダビューにレンダリングします。ユーザーは、そのフォルダ階層内を移動し、名前の変更、削除、共有などのファイル操作を実行できます。 -Content Explorer comes with a metadata view that uses metadata query to find files and folders based on their metadata. The data is then displayed in the embedded view. +コンテンツエクスプローラで、メタデータビューを使用できるようになりました。このビューでは、メタデータクエリを使用して、メタデータに基づいてファイルやフォルダを検索できます。データは埋め込みのビューに表示されます。 ## インストール @@ -158,33 +158,33 @@ contentExplorer.removeAllListeners(); ### オプション -| パラメータ | 型 | デフォルト | 説明 | -| ---------------------- | -------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `container` | String | `document.body` | コンテンツエクスプローラが配置されるコンテナのCSSセレクタ。hide() を呼び出すと、このコンテナは空になります。 | -| `sortBy` | String | `name` | コンテンツリストの最初の並べ替え基準オプション。値は`id`、`name`、`date`または`size`になります。 | -| `sortDirection` | String | `ASC` | コンテンツリストの最初の並べ替え方向オプション。値は`ASC`または`DESC`になります。 | -| `logoUrl` | String | | ヘッダーに表示するカスタムロゴのURL。この値が「box」という文字列の場合は、Boxのロゴが表示されます。 | -| `canPreview` | Boolean | `true` | このオプションが`true`に設定されていて、ファイルに対する`can_preview`権限が`true`の場合、コンテンツエクスプローラでファイルをクリックできます。ファイルをクリックするとそのファイルのプレビューが開始されます。ファイルに対する権限`can_preview`が`false`に設定されている場合、このオプションによる効果はありません。このオプションは、プレビュー可能なファイルのみに適用できます。 | -| `canDownload` | Boolean | `true` | これを`false`に設定すると、ダウンロードオプションが非表示になります。このオプションを非表示にするだけではダウンロードを防ぐことはできず、ファイルに対する権限でも`can_download`を`false`に設定する必要があります。ファイルに対する権限`can_download`が`false`に設定されている場合、このオプションによる効果はありません。このオプションは、ファイルのみに適用できます。 | -| `canDelete` | Boolean | `true` | これを`false`に設定すると、削除オプションが非表示になります。このオプションを非表示にするだけでは削除を防ぐことはできず、項目に対する権限でも`can_delete`を`false`に設定する必要があります。項目に対する権限`can_delete`が`false`に設定されている場合、このオプションによる効果はありません。 | -| `canRename` | Boolean | `true` | これを`false`に設定すると、名前の変更オプションが非表示になります。このオプションを非表示にするだけでは名前の変更を防ぐことはできず、項目に対する権限でも`can_rename`を`false`に設定する必要があります。 | -| `canUpload` | Boolean | `true` | これを`false`に設定すると、アップロードオプションが非表示になります。このオプションを非表示にするだけではアップロードを防ぐことはできず、現在のフォルダに対する権限でも`can_upload`を`false`に設定する必要があります。フォルダに対する権限`can_upload`が`false`に設定されている場合、このオプションによる効果はありません。 | -| `canCreateNewFolder` | Boolean | `true` | フォルダの新規作成オプションが非表示になります。このオプションを非表示にするだけではフォルダの新規作成を防ぐことはできず、フォルダ項目に対する権限でも`can_upload`を`false`に設定する必要があります。フォルダ項目に対する権限`can_upload`が`false`に設定されている場合、このオプションによる効果はありません。 | -| `canShare` | Boolean | `true` | `false`に設定すると、共有ボタンが非表示になります。このボタンを非表示にするだけでは共有を防ぐことはできず、項目の`permissions`でも`can_share`をfalseに設定する必要があります。項目に対する権限`can_share`が`false`に設定されている場合、このオプションによる効果はありません。 | -| `canSetShareAccess` | Boolean | `true` | `false`に設定すると、共有権限の変更を許可する共有ドロップダウン選択が非表示になります。この選択のドロップダウンを非表示にするだけでは共有権限の変更を防ぐことはできず、項目に対する権限でも`can_set_share_access`を`false`に設定する必要があります。項目に対する権限`can_set_share_access`が`false`に設定されている場合、このオプションによる効果はありません。 | -| `sharedLink` | String | | 共有リンクのURL。フォルダが共有されており、アクセストークンがファイルの所有者またはコラボレータに属していない場合は必須です。 | -| `sharedLinkPassword` | String | | 共有リンクのパスワード。共有リンクにパスワードが設定されている場合は必須です。 | -| `size` | String | `undefined` | コンテンツエクスプローラがコンテナの幅の大小に合わせて表示されるように示します。値には空白か、`small`または`large`を指定できます。空白にした場合、UI Elementはそのコンテナに合わせて調整され、自動で`small`の幅と`large`の幅が切り替わります。 | -| `isTouch` | Boolean | デフォルトでは、ブラウザとデバイスのデフォルトのタッチサポートが設定されます。 | Indicates to the Content Explorer that it's is being rendered on a touch enabled device. | -| `autoFocus` | Boolean | `false` | `true`に設定すると、初回読み込み時に項目グリッドに焦点が当てられます。 | -| `defaultView` | String | `files` | Value can be either be `files`, `recents` or `metadata`. When set to `recents`, by default you will see recent items instead of the regular file/folder structure. `metadata` is required to display the metadata view in Content Explorer. If not provided, you'll get a regular folder view. | -| `requestInterceptor` | Function | | リクエストをインターセプトする関数。例については、[このCodePen](https://codepen.io/box-platform/pen/jLdxEv)を参照してください。基盤となるXHRライブラリは`axios.js`で、[インターセプタでは同様のアプローチ](https://github.com/axios/axios#interceptors)に従っています。 | -| `responseInterceptor` | Function | | レスポンスをインターセプトする関数。例については、[このCodePen](https://codepen.io/box-platform/pen/jLdxEv)を参照してください。基盤となるXHRライブラリは`axios.js`で、[インターセプタでは同様のアプローチ](https://github.com/axios/axios#interceptors)に従っています。 | -| `ContentOpenWithProps` | Object | `{ show: false }` | エクスプローラからプレビューする際にOpen With Elementを表示できます。 | -| `token` | String | | Developer token generated in the Developer Console. | -| `metadataQuery` | Object | | Metadata query used to get the information for the metadata view. | -| `rootFolderID` | String | | Folder ID with a metadata template applied. `metadataQuery` will apply to this folder. | -| `fieldsToShow` | Object | | The metadata fields/columns to view - must be valid field names from the metadata template. | +| パラメータ | 型 | デフォルト | 説明 | +| ---------------------- | -------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `container` | String | `document.body` | コンテンツエクスプローラが配置されるコンテナのCSSセレクタ。hide() を呼び出すと、このコンテナは空になります。 | +| `sortBy` | String | `name` | コンテンツリストの最初の並べ替え基準オプション。値は`id`、`name`、`date`または`size`になります。 | +| `sortDirection` | String | `ASC` | コンテンツリストの最初の並べ替え方向オプション。値は`ASC`または`DESC`になります。 | +| `logoUrl` | String | | ヘッダーに表示するカスタムロゴのURL。この値が「box」という文字列の場合は、Boxのロゴが表示されます。 | +| `canPreview` | Boolean | `true` | このオプションが`true`に設定されていて、ファイルに対する`can_preview`権限が`true`の場合、コンテンツエクスプローラでファイルをクリックできます。ファイルをクリックするとそのファイルのプレビューが開始されます。ファイルに対する権限`can_preview`が`false`に設定されている場合、このオプションによる効果はありません。このオプションは、プレビュー可能なファイルのみに適用できます。 | +| `canDownload` | Boolean | `true` | これを`false`に設定すると、ダウンロードオプションが非表示になります。このオプションを非表示にするだけではダウンロードを防ぐことはできず、ファイルに対する権限でも`can_download`を`false`に設定する必要があります。ファイルに対する権限`can_download`が`false`に設定されている場合、このオプションによる効果はありません。このオプションは、ファイルのみに適用できます。 | +| `canDelete` | Boolean | `true` | これを`false`に設定すると、削除オプションが非表示になります。このオプションを非表示にするだけでは削除を防ぐことはできず、項目に対する権限でも`can_delete`を`false`に設定する必要があります。項目に対する権限`can_delete`が`false`に設定されている場合、このオプションによる効果はありません。 | +| `canRename` | Boolean | `true` | これを`false`に設定すると、名前の変更オプションが非表示になります。このオプションを非表示にするだけでは名前の変更を防ぐことはできず、項目に対する権限でも`can_rename`を`false`に設定する必要があります。 | +| `canUpload` | Boolean | `true` | これを`false`に設定すると、アップロードオプションが非表示になります。このオプションを非表示にするだけではアップロードを防ぐことはできず、現在のフォルダに対する権限でも`can_upload`を`false`に設定する必要があります。フォルダに対する権限`can_upload`が`false`に設定されている場合、このオプションによる効果はありません。 | +| `canCreateNewFolder` | Boolean | `true` | フォルダの新規作成オプションが非表示になります。このオプションを非表示にするだけではフォルダの新規作成を防ぐことはできず、フォルダ項目に対する権限でも`can_upload`を`false`に設定する必要があります。フォルダ項目に対する権限`can_upload`が`false`に設定されている場合、このオプションによる効果はありません。 | +| `canShare` | Boolean | `true` | `false`に設定すると、共有ボタンが非表示になります。このボタンを非表示にするだけでは共有を防ぐことはできず、項目の`permissions`でも`can_share`をfalseに設定する必要があります。項目に対する権限`can_share`が`false`に設定されている場合、このオプションによる効果はありません。 | +| `canSetShareAccess` | Boolean | `true` | `false`に設定すると、共有権限の変更を許可する共有ドロップダウン選択が非表示になります。この選択のドロップダウンを非表示にするだけでは共有権限の変更を防ぐことはできず、項目に対する権限でも`can_set_share_access`を`false`に設定する必要があります。項目に対する権限`can_set_share_access`が`false`に設定されている場合、このオプションによる効果はありません。 | +| `sharedLink` | String | | 共有リンクのURL。フォルダが共有されており、アクセストークンがファイルの所有者またはコラボレータに属していない場合は必須です。 | +| `sharedLinkPassword` | String | | 共有リンクのパスワード。共有リンクにパスワードが設定されている場合は必須です。 | +| `size` | String | `undefined` | コンテンツエクスプローラがコンテナの幅の大小に合わせて表示されるように示します。値には空白か、`small`または`large`を指定できます。空白にした場合、UI Elementはそのコンテナに合わせて調整され、自動で`small`の幅と`large`の幅が切り替わります。 | +| `isTouch` | Boolean | デフォルトでは、ブラウザとデバイスのデフォルトのタッチサポートが設定されます。 | コンテンツエクスプローラがタッチ対応デバイスにレンダリングされることを示します。 | +| `autoFocus` | Boolean | `false` | `true`に設定すると、初回読み込み時に項目グリッドに焦点が当てられます。 | +| `defaultView` | String | `files` | 値は`files`、`recents`、または`metadata`になります。`recents`に設定すると、デフォルトで、通常のファイル/フォルダ構造ではなく、最近使用した項目が表示されます。コンテンツエクスプローラでメタデータビューを表示するには、`metadata`を指定する必要があります。指定しない場合、通常のフォルダビューが表示されます。 | +| `requestInterceptor` | Function | | リクエストをインターセプトする関数。例については、[このCodePen](https://codepen.io/box-platform/pen/jLdxEv)を参照してください。基盤となるXHRライブラリは`axios.js`で、[インターセプタでは同様のアプローチ](https://github.com/axios/axios#interceptors)に従っています。 | +| `responseInterceptor` | Function | | レスポンスをインターセプトする関数。例については、[このCodePen](https://codepen.io/box-platform/pen/jLdxEv)を参照してください。基盤となるXHRライブラリは`axios.js`で、[インターセプタでは同様のアプローチ](https://github.com/axios/axios#interceptors)に従っています。 | +| `ContentOpenWithProps` | Object | `{ show: false }` | エクスプローラからプレビューする際にOpen With Elementを表示できます。 | +| `token` | String | | 開発者コンソールで生成された開発者トークン。 | +| `metadataQuery` | Object | | メタデータビューの情報を取得するために使用されるメタデータクエリ。 | +| `rootFolderID` | String | | メタデータテンプレートが適用されているフォルダのID。`metadataQuery`はこのフォルダに適用されます。 | +| `fieldsToShow` | Object | | 表示するメタデータフィールド/列 - メタデータテンプレートの有効なフィールド名を指定する必要があります。 | ### イベント @@ -257,51 +257,51 @@ contentExplorer.removeAllListeners(); | ユーザーが基本機能、プレビュー、ダウンロード、およびファイル/フォルダ名の変更を必要とする | `base_explorer` + `item_preview` + `item_download` + `item_rename` | | ユーザーがすべての機能 (基本、プレビュー、ダウンロード、名前の変更、共有、アップロード、および削除) を必要とする | `base_explorer` + `item_preview` + `item_download` + `item_rename` + `item_delete` + `item_share` + `item_upload` | -## Metadata view +## メタデータビュー -With Content Explorer you can also display files and folders based on their metadata. This view is called the metadata view and uses metadata template and metadata query to find the data you want to display. +コンテンツエクスプローラを使用すると、メタデータに基づいてファイルやフォルダを表示することもできます。このビューはメタデータビューと呼ばれ、メタデータテンプレートとメタデータクエリを使用して、表示するデータを探します。 ### 前提条件 -Make sure you have the following installed: +以下がインストールされていることを確認してください。 -* Node version: `>=18.18.2 <20.11.0` -* React version `>=17.0.2 <18.0.0` -* BUIE version `19.0.0` +* Nodeのバージョン: `>=18.18.2 <20.11.0` +* Reactのバージョン: `>=17.0.2 <18.0.0` +* BUIEのバージョン: `19.0.0` -### Create and configure an app +### アプリの作成と構成 -1. [Create a Box app][box-app]. -2. Add the local development address in the CORS Domains: +1. [Boxアプリを作成します][box-app]。 +2. \[CORSドメイン] にローカルでの開発用のアドレスを追加します。 ![CORSドメイン](./images/box-app-cors.png) -3. Generate a [developer token][token]. +3. [開発者トークン][token]を生成します。 ### メタデータテンプレートの作成 -The next step is to create a metadata template you will use to populate the Content Explorer. +次の手順では、コンテンツエクスプローラにデータを設定するために使用するメタデータテンプレートを作成します。 -1. Create a metadata template. You can use [Metadata API][creating-templates-api] or [Admin Console][creating-templates-ui] to do so. -2. Apply an already created template to a Box folder. Make sure you enable the cascade policy. For detailed instructions, see [instructions on customizing and applying templates][apply-templates]. +1. メタデータテンプレートを作成します。これには、[メタデータAPI][creating-templates-api]または[管理コンソール][creating-templates-ui]を使用できます。 +2. すでに作成済みのテンプレートをBoxフォルダに適用します。必ずカスケードポリシーを有効にするようにしてください。詳細な手順については、[テンプレートのカスタマイズと適用の手順][apply-templates]を参照してください。 -### Display metadata view +### メタデータビューの表示 -To make things easier, you can use a [sample project][metadata-project] to launch metadata view. +作業を簡単にするために、[サンプルプロジェクト][metadata-project]を使用してメタデータビューを起動できます。 -1. Clone the metadata sample project. -2. Update the placeholders in [`App.js`][appjs] with actual values: +1. メタデータのサンプルプロジェクトを複製します。 +2. [`App.js`][appjs]内のプレースホルダを実際の値で更新します。 -| パラメータ | 説明 | -| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `DEVELOPER_TOKEN` | [Developer token][token] generated in the the Developer Console. | -| `ENTERPRISE_ID` | Enterprise ID copied from the **General Settings** tab of your application. | -| `METADATA_TEMPLATE_NAME` | Name of your already created metadata template. **Note**: To make sure you provided the proper name, use the [metadata API][get-template] to retrieve the name, or copy it from the URL in the Admin Console. ![Metadata name in Admin Console](./images/metadata-template-name.png) If you decide to change the template name in the UI, you change the label only. The name to use in the component is always the you provided at the beginning. | -| `ROOTFOLDER_ID` | ID of Box folder to which you applied the metadata template. | +| パラメータ | 説明 | +| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `DEVELOPER_TOKEN` | 開発者コンソールで生成された[開発者トークン][token]。 | +| `ENTERPRISE_ID` | アプリケーションの \[**一般設定**] タブからコピーしたEnterprise ID。 | +| `METADATA_TEMPLATE_NAME` | 作成済みのメタデータテンプレートの名前。**注**: 適切な名前を指定済みであることを確認するには、[メタデータAPI][get-template]を使用して名前を取得するか、管理コンソールでURLから名前をコピーします。![管理コンソールにおけるメタデータ名](./images/metadata-template-name.png) UIでテンプレート名を変更しても、変更されるのはラベルのみです。コンポーネントで使用する名前は、常に最初に指定した名前になります。 | +| `ROOTFOLDER_ID` | メタデータテンプレートを適用したBoxフォルダのID。 | -The `defaultView`, `fieldsToShow`, and `metadataQuery` parameters are already defined in the sample project, as in the example below. +`defaultView`、`fieldsToShow`、`metadataQuery`の各パラメータは、以下の例に示すように、すでにサンプルプロジェクトで定義されています。 -For additional information on metadata queries, see [this guide][metadata-query]. +メタデータクエリの詳細については、[こちらのガイド][metadata-query]を参照してください。 -3. Pass the required parameters to the Content Explorer component. +3. コンテンツエクスプローラコンポーネントに必須パラメータを渡します。 ```js @@ -336,7 +336,7 @@ For additional information on metadata queries, see [this guide][metadata-query] ``` -A sample code for a React component including the Content Explorer metadata view would look as follows: +コンテンツエクスプローラのメタデータビューを含むReactコンポーネントのサンプルコードは次のようになります。 ```js function App() { @@ -421,7 +421,7 @@ export default App; -**TIP**: For a detailed flow, see [Metadata view blog post][blogpost]. +**ヒント**: 詳細なフローについては、[メタデータビューに関するブログ記事][blogpost]を参照してください。 diff --git a/pages/sign/index.md b/pages/sign/index.md index 2b0ec2737..df52d1625 100644 --- a/pages/sign/index.md +++ b/pages/sign/index.md @@ -14,31 +14,31 @@ previous_page_id: '' source_url: 'https://github.com/box/developer.box.com/blob/main/content/pages/sign/index.md' fullyTranslated: true --- -# Working with Box Sign +# Box Signの使用 -![Working with box sign image](images/working-with-box-sign.png) +![Box Signの使用の画像](images/working-with-box-sign.png) -This learning page provides developers with practical insights into working with [Box Sign][sign], aiming to facilitate the integration of the Box Platform Sign engine into their applications. +この学習ページでは、アプリケーションへのBox Platform Signエンジンの統合を促進することを目的に、[Box Sign][sign]の使用に関する実践的なインサイトを開発者に提供します。 ## クイックスタート -Use the [Quick start][quick-start] to go straight into the creation of a signature request. +[クイックスタート][quick-start]を使用すると、すぐに署名リクエストの作成に着手することができます。 -## Technical use cases +## 技術的なユースケース -In the [Technical use cases][technical-use-cases], you will learn how to handle the different types of documents that can be used in a signature request: from unstructured documents that require a preparation step, through templates, to generated ready to sign documents. +[技術的なユースケース][technical-use-cases]では、準備手順が必要な非構造化ドキュメントから、テンプレート、署名する準備ができている生成済みドキュメントまで、署名リクエストで使用できるさまざまな種類のドキュメントを処理する方法について説明します。 -## Request Options +## リクエストのオプション -In the [Request options][request-options], you will find a detailed exploration of the available customization and configuration options when sending signing requests through the Box Sign API. Learn how to tailor the signing experience to match your application's user interface, workflow, and specific requirements. +[リクエストのオプション][request-options]では、Box Sign APIを使用して署名リクエストを送信する際に利用できるカスタマイズと構成のオプションについて詳しく説明します。アプリケーションのユーザーインターフェース、ワークフロー、特定の要件に合うように署名エクスペリエンスを調整する方法を確認してください。 -Let's get started! +それでは、始めましょう。 [sign]: https://www.box.com/esignature diff --git a/pages/sign/quick-start/api-basics.md b/pages/sign/quick-start/api-basics.md index adc086bea..d4b2648a5 100644 --- a/pages/sign/quick-start/api-basics.md +++ b/pages/sign/quick-start/api-basics.md @@ -15,42 +15,42 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/10-quick-start/10-api-basics.md fullyTranslated: true --- -# API Basics +# APIの基本 ## Sign API -The Sign request endpoint is used to create and manage signature requests. You can create, resend, and cancel signature requests. You can also list all signature requests and get details of a specific signature request. +署名リクエストを作成して管理するには、署名リクエストのエンドポイントを使用します。署名リクエストは、作成、再送信、キャンセルできます。また、すべての署名リクエストのリストを取得したり、特定の署名リクエストの詳細を取得したりすることもできます。 -The endpoint is `https://{api.box.com}/2.0/sign_requests`. The following table lists the operations that you can perform on this endpoint. +エンドポイントは`https://{api.box.com}/2.0/sign_requests`です。次の表に、このエンドポイントで実行できる操作を示します。 -| 操作 | エンドポイント | 説明 | -| ---- | ------------------------- | -------------------------------------------- | -| GET | /sign_requests | List all signature requests. | -| GET | /sign_requests/:id | Get details of a specific signature request. | -| POST | /sign_requests | Create a signature request. | -| POST | /sign_requests/:id/resend | Resend a signature request. | -| POST | /sign_requests/:id/cancel | Cancel a signature request. | +| 操作 | エンドポイント | 説明 | +| ---- | ------------------------- | ---------------------- | +| GET | /sign_requests | すべての署名リクエストのリストを取得します。 | +| GET | /sign_requests/:id | 特定の署名リクエストの詳細を取得します。 | +| POST | /sign_requests | 署名リクエストを作成します。 | +| POST | /sign_requests/:id/resend | 署名リクエストを再送信します。 | +| POST | /sign_requests/:id/cancel | 署名リクエストをキャンセルします。 | -For full details on the request and response parameters, see the [Sign request API reference][sign-api-reference]. +リクエストとレスポンスのパラメータの詳細については、[署名リクエストAPIリファレンス][sign-api-reference]を参照してください。 -## Sign templates API +## SignテンプレートAPI -The Sign templates endpoint is used to list and get details of a template. +テンプレートのリストと詳細を取得するには、Signテンプレートエンドポイントを使用します。 -You can not create, edit, or delete templates using the API. These templates are exclusively managed in the Box web application. +このAPIを使用してテンプレートを作成、編集、削除することはできません。これらのテンプレートは、Boxウェブアプリでのみ管理されます。 -The endpoint is `https://{api.box.com}/2.0/sign_templates`. The following table lists the operations that you can perform on this endpoint. +エンドポイントは`https://{api.box.com}/2.0/sign_templates`です。次の表に、このエンドポイントで実行できる操作を示します。 -| 操作 | エンドポイント | 説明 | -| --- | ------------------- | ----------------------------------- | -| GET | /sign_templates | List all templates. | -| GET | /sign_templates/:id | Get details of a specific template. | +| 操作 | エンドポイント | 説明 | +| --- | ------------------- | --------------------- | +| GET | /sign_templates | すべてのテンプレートのリストを取得します。 | +| GET | /sign_templates/:id | 特定のテンプレートの詳細を取得します。 | -For a full details on the request and response parameters, see the [Sign template request API reference][sign-api-template-ref] +リクエストとレスポンスのパラメータの詳細については、[SignテンプレートリクエストAPIリファレンス][sign-api-template-ref]を参照してください。 [sign-api-reference]: https://developer.box.com/reference/resources/sign-request/ diff --git a/pages/sign/quick-start/index.md b/pages/sign/quick-start/index.md index 94a2dc053..716e9940f 100644 --- a/pages/sign/quick-start/index.md +++ b/pages/sign/quick-start/index.md @@ -17,13 +17,13 @@ fullyTranslated: true --- # クイックスタート -Get a sense of how the [Box Sign API][api-basics] is structured and how to create your first signature request. +[Box Sign API][api-basics]の構造と、最初の署名リクエストの作成方法の趣旨を把握しましょう。 -The Sign API does not follow the traditional CRUD model. You can create, resend, and cancel signature requests. You can also list all signature requests and get details of a specific signature request. +Sign APIは従来のCRUDモデルに従っていません。署名リクエストは、作成、再送信、キャンセルできます。また、すべての署名リクエストのリストを取得したり、特定の署名リクエストの詳細を取得したりすることもできます。 -Sign Templates API is read-only. You can list all templates and get details of a specific template. +SignテンプレートAPIは読み取り専用です。すべてのテンプレートのリストを取得したり、特定のテンプレートの詳細を取得したりすることができます。 -Once you get a sense of the API, you can create [your first signature request][quick-start]. +APIの趣旨を把握したら、[最初の署名リクエスト][quick-start]を作成できます。 [api-basics]: page://sign/quick-start/api-basics diff --git a/pages/sign/quick-start/your-first-request.md b/pages/sign/quick-start/your-first-request.md index c5ac1bf6c..10a1f0034 100644 --- a/pages/sign/quick-start/your-first-request.md +++ b/pages/sign/quick-start/your-first-request.md @@ -15,13 +15,13 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/10-quick-start/20-your-first-request.md fullyTranslated: true --- -# Your first request +# 最初のリクエスト -Imagine that you have a document stored in Box and you want to send it to a customer for signature. At a minimum your app needs to know what document to sign, where to store the signed document, and the signer email. +Boxに保存されているドキュメントがあり、署名をもらうために顧客に送信することを想像してみてください。少なくとも、アプリでは、署名対象のドキュメント、署名済みドキュメントの保存先、署名者のメールアドレスを認識する必要があります。 -## Creating a signature request +## 署名リクエストの作成 -You can use the Box Sign API or one of the available SDKs to create a signature request. See the example: +署名リクエストの作成には、Box Sign APIまたは使用可能ないずれかのSDKを使用できます。次の例を参照してください。 @@ -56,7 +56,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -101,7 +101,7 @@ def main(): -This will result in a signature request with a prepare document URL (simplified): +この結果、ドキュメント準備のURL (簡略化されています) を含む署名リクエストが作成されます。 @@ -152,7 +152,7 @@ This will result in a signature request with a prepare document URL (simplified) - + ```YAML @@ -167,52 +167,52 @@ Prepare url: https://app.box.com/sign/document/xyz-abc-123/.../prepare_doc/ -## Check the status of the signature request +## 署名リクエストのステータスの確認 -Creating the signature request is an asynchronous process, and can generate errors. Your application should check the status of the request before proceeding, and handle any errors. +署名リクエストの作成は非同期処理であり、エラーが発生する可能性があります。アプリケーションでは、処理を進める前にリクエストのステータスを確認し、エラーがあれば処理する必要があります。 -A signature request can have the following statuses: +署名リクエストのステータスを以下に示します。 -![Signature flow](images/basic-sign-flow.png) +![署名のフロー](images/basic-sign-flow.png) * `converting`: 署名リクエストが送信された後、ファイルが署名プロセスのために`.pdf`に変換されている。 -* `error_converting`: An issue occurred while converting the file to a `.pdf`. -* `created`: When the `document_preparation_is_needed` is set to `true`, but the `prepare_url` has not yet been visited. +* `error_converting`: ファイルを`.pdf`に変換中に問題が発生した。 +* `created`: `document_preparation_is_needed`が`true`に設定されているが、`prepare_url`がまだアクセスされていない。 * `sent`: リクエストが正常に送信されたが、どの署名者も対応していない。 -* `error_sending`: An issue occurred while sending the request. -* `viewed`: The first, or only, signer clicked on **Review document** in the signing email or visited the signing URL. -* `downloaded`: The document was downloaded by the signer. +* `error_sending`: リクエストの送信中に問題が発生した。 +* `viewed`: 最初 (または唯一) の署名者が署名用メールの \[**ドキュメントをレビュー**] をクリックするか、署名用URLにアクセスした。 +* `downloaded`: 署名者がドキュメントをダウンロードした。 * `signed`: すべての署名者がリクエストの処理を完了した。 -* `signed and downloaded`: The document was signed and downloaded by the signer. +* `signed and downloaded`: 署名者がドキュメントに署名してダウンロードした。 * `declined`: いずれかの署名者がリクエストを拒否した。 * `cancelled`: リクエストがUIまたはAPIを介してキャンセルされた。 * `expired`: 署名が未完了、不十分のまま、有効期限が過ぎた。 -* `finalizing`: All signers have signed the request, but the final document with signatures and the signing log have not been generated yet. -* `error_finalizing`: The `finalizing` phase did not complete successfully. +* `finalizing`: すべての署名者がリクエストに署名済みでも、署名された最終的なドキュメントと署名ログがまだ生成されていない。 +* `error_finalizing`: `finalizing`フェーズが正常に完了しなかった。 -## Preparing the document +## ドキュメントの準備 -Depending on your technical use case you may need to prepare the document. In this specific example, we are signing a PDF, and the Box Sign engine has no idea where to place the signature pad field or any other inputs. This is why we used the `is_document_preparation_needed` flag. +技術的なユースケースによっては、ドキュメントの準備が必要になる場合があります。この具体的な例では、PDFに署名していますが、Box Signエンジンは、署名フィールドやその他の入力データの配置場所を認識しません。そのため、`is_document_preparation_needed`フラグを使用しました。 -If a prepare URL is present, then your application should open the prepare URL in a browser, where the requester can add the signature pad field and any other inputs needed for the signer to complete the document. +準備のURLが存在する場合、アプリケーションはそのURLをブラウザで開く必要があります。そこで、リクエスト送信者は、署名者がドキュメントでの作業を完了するために必要な署名フィールドやその他の入力データを追加できます。 -Once the document is prepared, the requester can send the signature request to the signer. +ドキュメントが準備できたら、リクエスト送信者は署名リクエストを署名者に送信できます。 -This preparation step is not always necessary. Take a look at the [technical use cases][technical-use-cases] for more information. +この準備手順は必須ではありません。詳細については、[技術的なユースケース][technical-use-cases]を参照してください。 -## Completing the signature request +## 署名リクエストの完了 -The signer then receives an email from Box with a link to the signature request. The signer can click the link and sign the document. +署名者には、署名リクエストへのリンクが記載されたメールがBoxから届きます。署名者はリンクをクリックしてドキュメントに署名できます。 -When the process is completed, both a signature log containing metadata and the signed document are stored in the destination folder. +処理が完了すると、メタデータを含む署名ログと署名済みドキュメントの両方が保存先フォルダに格納されます。 -Congratulations! You have successfully created your first signature request. +これで、最初の署名リクエストを正常に作成できました。 -This represents the basic use case for Box Sign. The `create` method has many options that you can use to customize your signature request. +これは、Box Signの基本的なユースケースを示しています。`create`メソッドには、署名リクエストのカスタマイズに使用できる多くのオプションがあります。 -Be sure to check the [request options][request-options], and the [technical use cases][technical-use-cases] sections for more information. +詳細については、[リクエストのオプション][request-options]と[技術的なユースケース][technical-use-cases]のセクションをぜひ確認してください。 diff --git a/pages/sign/request-options/custom-email.md b/pages/sign/request-options/custom-email.md index 190e60755..e9e0a0ec3 100644 --- a/pages/sign/request-options/custom-email.md +++ b/pages/sign/request-options/custom-email.md @@ -15,30 +15,30 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/30-request-options/60-custom-email.md fullyTranslated: true --- -# Custom email and notifications +# カスタムメールと通知 -## Email subject and body +## メールの件名と本文 -By default, the email sent to the signers contains a link to the document, a generic subject, and a generic message. +署名者に送信されるメールには、デフォルトで、ドキュメントへのリンク、一般的な件名、一般的なメッセージが記載されています。 -If you are using templates managed within Box, the subject and message body can be set in the template itself. +Box内で管理されているテンプレートを使用する場合、件名とメッセージ本文はテンプレート自体で設定できます。 -However, if you are not using templates, you can still customize the email messages sent to the signers by passing the `email_subject` and the `email_message` parameters. +ただし、テンプレートを使用しない場合も、`email_subject`パラメータと`email_message`パラメータを渡すことで、署名者に送信されるメールメッセージをカスタマイズすることができます。 -Both parameters accept strings, but the `email_message` parameter also accepts HTML with some limitations. +どちらのパラメータにも文字列を使用できますが、`email_message`パラメータには、いくつか制限はあるもののHTMLも使用できます。 -Only some HTML tags are allowed. Links included in the message are also converted to hyperlinks in the email. +使用できるのは、一部のHTMLタグだけです。また、メッセージに含まれるリンクは、メールではハイパーリンクに変換されます。 -The message parameter may contain the following HTML tags: +メッセージパラメータには、以下のHTMLタグを含めることができます。 * `a`, `abbr`, `acronym`, `b`, `blockquote`, `code`, `em`, `i`, `ul`, `li`, `ol`, `strong` -Custom styles on these tags are not allowed. +これらのタグにカスタムスタイルを適用することはできません。 -Be aware that when the text to HTML ratio is too high, the email may end up in spam filters or clipped. +テキストとHTMLの比率が大きすぎると、メールがスパムフィルタに入ったり、切り取られたりする可能性があることにご注意ください。 @@ -77,7 +77,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -119,19 +119,19 @@ def main(): -## Manual notification +## 手動による通知 -By now, you've noticed that the signature request sends an email notification to the signers by default. This email is sent from a `box.com` domain and email system. +ここまでで、署名リクエストでは、デフォルトで署名者にメール通知が送信されることがわかりました。このメールは`box.com`ドメインおよびメールシステムから送信されます。 -You can take over the notification process by setting the `embed_url_external_user_id` parameter to an identifier of your choice for a specific signer. +`embed_url_external_user_id`パラメータに特定の署名者を表す任意の識別子を設定することで、通知プロセスを引き継ぐことができます。 -By setting this parameter, the signer will not receive an email notification, and within the signature request, you get back both an `embed_url` and an `iframeable_embed_url`. +このパラメータを設定すると、署名者にはメール通知が送信されず、署名リクエスト内で`embed_url`と`iframeable_embed_url`の両方が返されます。 -The `embed_url` can be opened directly, so it is suitable for your app to send it in an email, or by any other notifications system for the signer to open. +`embed_url`は直接開くことができるので、アプリからメールで送信したり、署名者が開く他の通知システムで送信したりするのに適しています。 -The `iframeable_embed_url` is suited to be used with the [Box Embedded Sign Client][embed], which allows you to embed the Box Sign client on an iframe within your web app. +`iframeable_embed_url`は、[Box Signクライアントの埋め込み機能][embed]との併用に適しており、ウェブアプリ内のiframeにBox Signクライアントを埋め込むことができます。 -For example see this request: +たとえば、次のリクエストを確認してください。 @@ -166,7 +166,7 @@ For example see this request: - + ```python @@ -218,7 +218,7 @@ def main(): -Returns (simplified): +結果は次のとおりです (簡略化されています)。 @@ -248,7 +248,7 @@ Returns (simplified): - + ```yaml @@ -267,6 +267,6 @@ Simple sign request: 22a990ce-4e24-463b-b2f4-124820fe161a-defddc79c946 -You can now take the embedded URLs and use your own notification process or embed the signature client within your own app. +これで、埋め込みURLを取得して、独自の通知プロセスを使用したり、自分のアプリ内に署名クライアントを埋め込んだりできるようになりました。 [embed]: guide://box-sign/embedded-sign-client diff --git a/pages/sign/request-options/custom-urls.md b/pages/sign/request-options/custom-urls.md index 9ce49edb6..ec8e6961c 100644 --- a/pages/sign/request-options/custom-urls.md +++ b/pages/sign/request-options/custom-urls.md @@ -15,15 +15,15 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/30-request-options/30-custom-urls.md fullyTranslated: true --- -# Redirect URLs +# リダイレクトURL -Often after signing a document your company might want to redirect the user to a specific web page like a thank you or an onboarding page. There are two features to support these requirements. +会社は、ドキュメントに署名したユーザーをお礼のページやオンボーディングページのような特定のウェブページにリダイレクトした方がよい場合もよくあります。このような要件をサポートする機能は2つあります。 -When the signer completes the signature process, they can be redirected to a web page. The same can happen when the signer declines the signature request. +署名者が署名プロセスを完了したときに、その署名者をウェブページにリダイレクトできます。署名者が署名リクエストを拒否した場合も同様です。 -We can customize these pages by passing the `redirect_url` and `decline_redirect_url` parameters. +`redirect_url`パラメータと`decline_redirect_url`パラメータを渡すことで、これらのページをカスタマイズできます。 -![Custom redirect pages](images/sign-flow-custom-url.png) +![カスタムリダイレクトページ](images/sign-flow-custom-url.png) 例: @@ -62,7 +62,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -105,4 +105,4 @@ def main(): -If you sign you’ll be redirected to our forum page. If you decline you’ll be redirected to our developer page. +署名した場合、フォーラムページにリダイレクトされます。拒否した場合は、開発者向けのページにリダイレクトされます。 diff --git a/pages/sign/request-options/extra-security.md b/pages/sign/request-options/extra-security.md index e8859120e..3e7ed7f1d 100644 --- a/pages/sign/request-options/extra-security.md +++ b/pages/sign/request-options/extra-security.md @@ -15,15 +15,15 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/30-request-options/20-extra-security.md fullyTranslated: true --- -# Extra security (2FA) +# セキュリティの強化 (2要素認証) -Imagine you want an [additional layer of security][2FA] for your signature requests, by requesting the signer to use a password or a phone verification in the document signing step. +ドキュメントへの署名手順で署名者に対してパスワードや電話認証を要求することで、署名リクエストの[セキュリティレベルを高める][2FA]ことを想像してみてください。 -![2FA Signature request](images/sign-flow-2fa.png) +![2要素認証による署名リクエスト](images/sign-flow-2fa.png) -## Phone verification +## 電話認証 -You can require the signer to use 2FA through their mobile phone to complete the signature request by passing the `is_phone_verification_required_to_view` parameter. +`is_phone_verification_required_to_view`パラメータを渡すことにより、署名リクエストを完了するために携帯電話から2要素認証を使用するよう署名者に要求することができます。 例: @@ -61,7 +61,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -113,23 +113,23 @@ def main(): -When the signer tries to complete the signature request a phone verification pops up: +署名者が署名リクエストを完了しようとすると、電話認証を求めるポップアップが表示されます。 -![Phone verification](images/sign-simple-phone-verification.png) +![電話認証](images/sign-simple-phone-verification.png) -Then the signer is prompted to enter the code sent in a SMS: +その後、署名者はSMSで送信されたコードを入力するよう求められます。 -![Entering the SMS code](images/sign-simple-phone-verification-enter-code.png) +![SMSコードの入力](images/sign-simple-phone-verification-enter-code.png) -This check is done as the last step, so it does not prevent the signer from accessing the document. +この確認は最後の手順として行われるため、署名者がドキュメントにアクセスできなくなることはありません。 -## Password verification +## パスワード認証 -You can require the signer to use a password to open the signature request by passing the `password` parameter in the `signer` object. For example: +`signer`オブジェクトに`password`パラメータを渡すことにより、署名リクエストを開くためにパスワードを使用するよう署名者に要求することができます。次に例を示します。 @@ -165,7 +165,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -216,13 +216,13 @@ def main(): -Once the signer opens the signature request they should see something like this: +署名者が署名リクエストを開くと、次のような画面が表示されます。 -![Password verification pop-up](images/sign-simple-password.png) +![パスワード認証のポップアップ](images/sign-simple-password.png) -As the password verification is done on the first step, it prevents the signer from accessing the document until the correct password is provided. +パスワード認証は最初の手順で行われるため、正しいパスワードが入力されるまで、署名者はドキュメントにアクセスできません。 diff --git a/pages/sign/request-options/in-person.md b/pages/sign/request-options/in-person.md index 09d19c95c..0205a6513 100644 --- a/pages/sign/request-options/in-person.md +++ b/pages/sign/request-options/in-person.md @@ -15,23 +15,23 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/30-request-options/70-in-person.md fullyTranslated: true --- -# In person signatures +# 対面での署名 -Imagine your application is used by a salesperson when they are face to face with a customer and an immediate signature is required, for example, to subscribe to a service or to confirm a purchase. +営業担当者が顧客と対面していて、サービスへの加入や購入の確認など、即座に署名が必要になったときに、アプリケーションを使用する場合を考えてみましょう。 -In this case, the salesperson can use your application to create a signature request and then hand over the device to the customer to sign the document, immediately closing the deal. +この場合、営業担当者はアプリケーションを使用して署名リクエストを作成した後、顧客にデバイスを手渡してドキュメントに署名してもらうことで、すぐに取引を成立させることができます。 -Doing this using the Box web application, for example from a template, is very straightforward. You set the signer or signers email so they can receive a copy of the signed document, flag them as in person, and as soon as you send the request, the Sign interface opens requesting the signature for the first signer, then for the second signer, and so on. +Boxウェブアプリを使用して、例えばテンプレートからこの作業を行うことは非常に簡単です。署名者が署名済みドキュメントのコピーを受信できるように署名者 (複数可) のメールアドレスを設定し、対面での署名というフラグを設定します。また、リクエストを送信するとすぐに、Signのインターフェースが開き、最初の署名者に署名をリクエストし、その後、2番目の署名者、3番目の署名者のように続きます。 -In order to use this within your application, you need to create a signature request with the `is_in_person` flag set to `true` for each signer. +アプリケーション内でこれを使用するには、署名者ごとに`is_in_person`フラグを`true`に設定して署名リクエストを作成する必要があります。 -However because your application needs to show the Sign interface to the signer, you also need to use the `embed_url_external_user_id`so that you get back the embedded URLs, and then either open a browser window or use an iframe to display the signature interface. +ただし、アプリケーションではSignのインターフェースを署名者に表示する必要があるため、埋め込みURLが返されるように`embed_url_external_user_id`を使用してから、ブラウザウィンドウを開くか、iframeを使用して署名インターフェースを表示する必要があります。 -![In person signing loops through signers](images/sign-flow-in-person.png) +![複数の署名者による対面での署名のループ](images/sign-flow-in-person.png) -## Create an in person signature request +## 対面での署名リクエストの作成 -Let's use a template with a single signer as an example: +例として、1人の署名者を設定したテンプレートを使用します。 @@ -62,7 +62,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -115,7 +115,7 @@ def main(): -Resulting in (simplified): +結果は次のとおりです (簡略化されています)。 @@ -155,7 +155,7 @@ Resulting in (simplified): - + ```yaml @@ -174,17 +174,17 @@ Simple sign request: a9159d31-d2fb-4e88-9306-02c00de013d1 -Notice the `embed_url` and `iframeable_embed_url` in the response. Now when we browse to the embed URL, you see the signature interface: +レスポンスの`embed_url`と`iframeable_embed_url`に注目してください。埋め込みURLを参照すると、署名インターフェースが表示されます。 -![In person signing](images/sign-in-person.png) +![対面での署名](images/sign-in-person.png) -Once finished the signer will receive a copy of the signed document via their email. +署名が完了すると、署名者には署名済みドキュメントのコピーがメールで送信されます。 -## Multiple in person signers +## 複数の署名者による対面での署名 -As long as the signer is flagged as `is_in_person`, the signing interface cycles through all the signers in the request. +署名者に`is_in_person`というフラグが設定されている限り、リクエストに含まれるすべての署名者に署名インターフェースが繰り返されます。 -For example, if you add a second signer to the request: +たとえば、リクエストに2人目の署名者を追加する場合は、次のようになります。 @@ -220,7 +220,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -280,7 +280,7 @@ def main(): -Results in (simplified): +結果は次のとおりです (簡略化されています)。 @@ -326,7 +326,7 @@ Results in (simplified): - + ```yaml @@ -349,10 +349,10 @@ Simple sign request: d066575f-f22b-42fc-b9e2-701468776475 -Browsing to the embedded URL shows the signature interface for the first signer: +埋め込みURLを参照すると、最初の署名者に署名インターフェースが表示されます。 -![First in person signer](images/sign-inperson-first.png) +![最初の対面での署名者](images/sign-inperson-first.png) -Once the first signer has signed, the signature interface automatically switches to the second signer: +最初の署名者が署名すると、署名インターフェースは自動的に2番目の署名者に切り替わります。 -![Alt text](images/sign-inperson-second.png) +![代替テキスト](images/sign-inperson-second.png) diff --git a/pages/sign/request-options/index.md b/pages/sign/request-options/index.md index 66d1729f1..309f18e8c 100644 --- a/pages/sign/request-options/index.md +++ b/pages/sign/request-options/index.md @@ -15,6 +15,6 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/30-request-options/index.md fullyTranslated: true --- -# Request options +# リクエストのオプション -The Box Sign API offers a wide range of customization and configuration options when sending signature requests. These options allow developers to tailor the user experience and workflow to match their application's specific requirements. +Box Sign APIには、署名リクエストを送信する際のカスタマイズと構成のさまざまなオプションが用意されています。開発者はこれらのオプションを使用することで、アプリケーションに固有の要件に合わせてユーザーエクスペリエンスとワークフローをカスタマイズできます。 diff --git a/pages/sign/request-options/multiple-signers.md b/pages/sign/request-options/multiple-signers.md index 5dd5462f0..51a901eab 100644 --- a/pages/sign/request-options/multiple-signers.md +++ b/pages/sign/request-options/multiple-signers.md @@ -15,21 +15,21 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/30-request-options/10-multiple-signers.md fullyTranslated: true --- -# Multiple signers and roles +# 複数の署名者と役割 -## Multiple signers +## 複数の署名者 -What if you have a document that needs to be signed by multiple people? This is typical for contracts between two or more entities. +複数の人に署名してもらう必要があるドキュメントがある場合はどうなるでしょうか。これは、2つ以上の事業体の間で結ばれる契約でよく見られます。 -Having multiple signers introduces another dimension to the Box Sign process, the order in which the signers need to sign the document. +複数の署名者を設定すると、Box Signのプロセスには、署名者がドキュメントに署名する順序という別の要素が導入されます。 -If you do not specify the order, the request is sent to everyone at the same time, and when all parties have signed the document, they each receive a copy with all signatures. +順序を指定しない場合、リクエストは全員に同時に送信されます。さらに、関係者全員がドキュメントへの署名を完了すると、各関係者は、すべての署名を含むコピーを受け取ります。 -If you specify the signing order, the signature request is sent to the first signer. Only when the first signer signs the document, the request is sent to the second signer, and so on. +署名の順序を指定すると、署名リクエストは最初の署名者に送信されます。最初の署名者がドキュメントに署名した場合にのみ、このリクエストは2番目の署名者に送信されます (それ以降も同様)。 -Let’s see this working with an example scholarship contract between a university and a student. In this case the institution/teacher must sign the document first. +大学と学生の間で交わされる奨学金の契約の例を使用してこの仕組みを見てみましょう。この場合は、教育機関/教員が最初にドキュメントに署名する必要があります。 -Creating a method specific for this: +このためのメソッドを作成します。 @@ -70,7 +70,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -134,47 +134,47 @@ def main(): -In this particular example the document needs to be prepared, so the browser to the prepare URL opens. +この例では、ドキュメントを準備する必要があるため、ブラウザで準備のURLを開きます。 -Drag the signature pad, the full name and the date to the appropriate places in the document, and click Send Request: +署名パッド、フルネーム、日付をドキュメント内の適切な場所にドラッグし、\[リクエストの送信] をクリックします。 -![Preparing the contract](images/sign-multi-prep.png) +![契約書の準備](images/sign-multi-prep.png) -Notice you now have two signers, with the order already specified. The `color` is also important to identify which signer is which (in this case the institution is blue and the student is green), determining which signature pad, name and date belongs to which signer. +この時点で2人の署名者が設定され、順序もすでに指定されていることに注目してください。また、`color`は、署名者を識別するためにも重要であり (この場合、教育機関は青、教員は緑)、どの署名者にどの署名パッド、名前、日付が属しているかを特定します。 -If you look at the signature request details, you should see something like this: +署名リクエストの詳細を確認すると、次のように表示されます。 -![Signature request details showing the document and signers](images/sign-multi-prep-details.png) +![ドキュメントと署名者を示す署名リクエストの詳細](images/sign-multi-prep-details.png) -Indicating that the first request was sent, but the second is waiting for the first to be completed. +最初のリクエストは送信済みですが、2番目のリクエストは最初のリクエストが完了するのを待っていることを示します。 -Go ahead and complete the signature process for both signers. +先に進み、両方の署名者の署名プロセスを完了します。 -Notice that when you get the second request it is already signed by the first signer. +2番目のリクエストを受け取った時点で、すでに最初の署名者は署名済みであることに注意してください。 ## ロール -So far we have been working with the `signer` role. However there are [other roles][roles] that you can use to customize the signature process. +ここまでは、役割として`signer`を使用してきましたが、署名プロセスのカスタマイズに使用できる[他の役割][roles]もあります。 -The available roles are, `signer`, `approver`, and `final copy reader` +使用可能な役割は、`signer`、`approver`、`final copy reader`です。 -From a developer perspective, this means: +開発者の視点から見ると、これは以下を意味します。 -* **Signer**: Any person who is allowed to add data to the document. This includes adding a signature, initials, date, but also filling out text fields, check boxes, and radio buttons, even if it does not include a signature. +* **署名者**: ドキュメントにデータを追加できる人。これには、署名、イニシャル、日付の追加だけでなく、署名が含まれていなくても、テキストフィールド、チェックボックス、ラジオボタンへの入力も含まれます。 -* **Approver**: This role will be asked if they approve the signature request. This approval happens before the preparation step, if enabled, and before the request is sent to any of the signers. This role is useful if you need to get approval from someone before sending the document to the signers. +* **承認者**: この役割は、署名リクエストを承認するかどうかを尋ねられます。この承認は、準備手順の前 (有効な場合) およびリクエストが署名者に送信される前に行われます。この役割は、ドキュメントを署名者に送信する前に誰かから承認を得る必要がある場合に便利です。 -* **Final copy reader**: This role does not interact with the signature process, but will receive a copy of the signed document. +* **最終的なコピー受信者**: この役割は、署名プロセスには関与しませんが、署名済みドキュメントのコピーを受け取ります。 -Let's use roles to be a bit more creative in the scholarship example. +役割を使用して、この奨学金の例ではもう少し工夫してみましょう。 -Imagine that the scholarship needs to be approved by the dean, and the legal department receives a final copy of the contract. +奨学金は学部長による承認が必要であることと、法務部門が契約書の最終的なコピーを受け取ることを想像してみてください。 -The flow starts with the signature request, flowed by the dean approval, the institution signature, the student signature, and finally the legal department receives a copy of the signed document: +フローは署名リクエストで始まり、学部長による承認、教育機関による署名、学生による署名と続き、最後に、法務部門が署名済みドキュメントのコピーを受け取ります。 -![Multiple signers and roles](images/sign-flow-multi-role.png) +![複数の署名者と役割](images/sign-flow-multi-role.png) -Let's create a method for this: +このためのメソッドを作成しましょう。 @@ -223,7 +223,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -299,19 +299,19 @@ def main(): -Like before you need to prepare the document, so open the prepare URL in your browser. +先ほどと同様、ドキュメントを準備する必要があるため、ブラウザで準備のURLを開きます。 -Notice in the example the institution is represented by blue on the left, and the student by green on the right, and both are signers. +この例では、教育機関が左側に青で示され、学生が右側に緑で示されており、どちらも署名者であることに注目してください。 -Neither the `approver` nor the `final copy reader` can have inputs associated with them. If you do this, their roles will be adjusted to `signer`: +`approver`にも`final copy reader`にも入力データを関連付けることはできません。関連付けると、その役割は`signer`に変更されます。 -![Multiple role preparation](images/sign_multi-steps-prep.png) +![複数の役割の準備](images/sign_multi-steps-prep.png) -Continuing the signature process: +署名プロセスを続行します。 -* The dean approves the scholarship -* The institution signs the scholarship -* The student signs the scholarship -* The legal department receives a copy of the signed document. +* 学部長が奨学金を承認する +* 教育機関が奨学金に署名する +* 学生が奨学金に署名する +* 法務部門が署名済みドキュメントのコピーを受け取る [roles]: https://support.box.com/hc/en-us/articles/4404105660947-Roles-for-signers diff --git a/pages/sign/request-options/request-expiration.md b/pages/sign/request-options/request-expiration.md index 6c457a8b5..3ba083590 100644 --- a/pages/sign/request-options/request-expiration.md +++ b/pages/sign/request-options/request-expiration.md @@ -15,13 +15,13 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/30-request-options/50-request-expiration.md fullyTranslated: true --- -# Request expiration +# リクエストの有効期限 -There are situations where you might need to [set an expiration date][exp-date] for the signature request. +場合によっては、署名リクエストの[有効期限を設定する][exp-date]必要があります。 -For example, imagine a quote for a service that is valid for 30 days. This proposal has to be signed by a certain date, and if not, the signature request for the quote is no longer valid. +たとえば、30日間有効なサービスの見積もりを想像してみてください。この提案書には期日までに署名する必要があり、署名しなかった場合、この見積もりに対する署名リクエストは無効になります。 -All you need to do is pass the `days_valid` parameter. +必要なのは、`days_valid`パラメータを渡すことだけです。 例: @@ -58,7 +58,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python diff --git a/pages/sign/request-options/resend-requests.md b/pages/sign/request-options/resend-requests.md index 4552ba04a..3bb4d216c 100644 --- a/pages/sign/request-options/resend-requests.md +++ b/pages/sign/request-options/resend-requests.md @@ -15,17 +15,17 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/30-request-options/40-resend-requests.md fullyTranslated: true --- -# Resend requests +# リクエストの再送信 -What if the signer did not receive the email, the email was lost, or the signer deleted the email by mistake? +署名者がメールを受信できなかった場合や、メールを紛失したり、署名者が誤ってメールを削除したりした場合はどうなるでしょうか。 -You can resend the signature request email to the `signer` , either manually or you can turn on the automatic resend option. +署名リクエストメールは、手動で`signer`に再送信することも、自動再送信オプションをオンにすることもできます。 -## Manual resend +## 手動による再送信 -To manually resend the signature request email to the signer, call the `resend_sign_request` method on the `sign_requests` object. You can only do it once every 10 minutes. +署名リクエストメールを手動で署名者に再送信するには、`sign_requests`オブジェクトで`resend_sign_request`メソッドを呼び出します。この操作は、10分間に1回しか実行できません。 -Here is an example: +以下に例を示します。 @@ -41,7 +41,7 @@ curl --location --request POST 'https://api.box.com/2.0/sign_requests/ - + ```python @@ -56,11 +56,11 @@ def sign_send_reminder(client: Client, sign_request_id: str): -## Automatic resend +## 自動再送信 -The automatic resend option sends a reminder email to signers that have not signed the document yet, after 3, 8, 13, and 18 days. +自動再送信オプションを使用すると、ドキュメントにまだ署名していない署名者に対して3日後、8日後、13日後、18日後にリマインダメールが送信されます。 -To enable automatic resend set the `are_reminders_enabled` parameter to `true`. For example: +自動再送信を有効にするには、`are_reminders_enabled`パラメータを`true`に設定します。たとえば、以下のようにします。以下に例を示します。 @@ -95,7 +95,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python diff --git a/pages/sign/technical-use-cases/index.md b/pages/sign/technical-use-cases/index.md index 5441c1d3e..c7fdd8b3e 100644 --- a/pages/sign/technical-use-cases/index.md +++ b/pages/sign/technical-use-cases/index.md @@ -15,21 +15,21 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/20-technical-use-cases/index.md fullyTranslated: true --- -# Technical use cases +# 技術的なユースケース -In your application you will be signing different documents from many sources. How can your application process such documents in order for them to be recognized by the Box Sign service? +アプリケーションでは、多くのソースからのさまざまなドキュメントに署名することになります。このようなドキュメントをBox Signサービスに認識させるためにアプリケーションでどのように処理すればよいのでしょうか。 -A signature request can have multiple requirements, or inputs, beyond the traditional signature, such as name, date, and initials. These inputs are called signature properties. The Box Sign service needs to know where to place these inputs in the document, and how to recognize them. +署名リクエストには、従来の署名 (名前、日付、イニシャルなど) 以外に、複数の要件 (入力データ) を設定することができます。こうした入力データは署名プロパティと呼ばれます。Box Signサービスでは、これらの入力データをドキュメント内のどこに配置し、どのように認識するかを把握しておく必要があります。 -The first step is to consider if the document has the necessary information for the Box Sign service to recognize the signature properties. +最初の手順として、Box Signサービスが署名プロパティを認識するために必要な情報をドキュメントに含めるかどうかを検討します。 -If not, then the [document is unstructured][unstructured-docs], and should be prepared before sending the signature request. This is called document preparation, and is an extra step automatically created by the Box Sign service. +含めない場合、[ドキュメントは構造化されていない][unstructured-docs]ので、署名リクエストを送信する前に準備する必要があります。これはドキュメントの準備と呼ばれ、Box Signサービスによって自動的に作成される追加の手順です。 -There are two other types of documents that already have the necessary information for the Box Sign service to recognize the signature properties. The [sign templates][sign-templates], managed in the Box application, and the [structured documents][sign-structured-docs], which are typically generated documents, containing specific tags representing the signature properties. +Box Signサービスが署名プロパティを認識するために必要な情報をすでに含んでいるドキュメントは、他に2種類あります。1つは、Boxアプリケーションで管理される[Signテンプレート][sign-templates]で、もう1つは[構造化されたドキュメント][sign-structured-docs]です。構造化されたドキュメントは、署名プロパティを表す特定のタグを含む、通常生成されるドキュメントです。 -Signing unstructured docs +非構造化ドキュメントへの署名 diff --git a/pages/sign/technical-use-cases/sign-structured-docs.md b/pages/sign/technical-use-cases/sign-structured-docs.md index 801a74d1e..5ddb77fc2 100644 --- a/pages/sign/technical-use-cases/sign-structured-docs.md +++ b/pages/sign/technical-use-cases/sign-structured-docs.md @@ -15,46 +15,46 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/20-technical-use-cases/30-sign-structured-docs.md fullyTranslated: true --- -# Signing structured docs +# 構造化されたドキュメントへの署名 -A structured document in the context of Box Sign is a document that includes specific tags that can be recognized by the Box Sign API. These tags are used to place the signature properties associated with a specific signer in the document, such as name, date, and signature. +Box Signのコンテキストにおける構造化されたドキュメントとは、Box Sign APIが認識できる特殊なタグを含むドキュメントのことです。これらのタグは、特定の署名者に関連付けられた署名プロパティ (名前、日付、署名など) をドキュメント内に配置するために使用されます。 -This allows your app to handle a dynamic generated document that is ready to be signed, which has a couple of advantages: +これにより、アプリでは、署名の準備が整った、動的に生成されたドキュメントを処理できます。これには、いくつかの利点があります。 -* The document can be dynamically generated, and the signature properties can be added to the document before creating the signature request, effectively bypassing the document preparation step. +* ドキュメントを動的に生成できます。また、署名リクエストを作成する前に署名プロパティをドキュメントに追加できるため、実質的にドキュメントの準備手順を省略できます。 -* The document format can be handled outside of Box Sign templates, allowing higher flexibility and integration with external document management systems. +* ドキュメントの形式はBox Signテンプレートの外部で処理できるため、柔軟性が高まり、外部のドキュメント管理システムとの統合が可能になります。 -## Anatomy of a structured document +## 構造化されたドキュメントの詳細 -Here is an example of a structured document, showing the formatting used to place tags in a Microsoft Word document: +構造化されたドキュメントの例を以下に示します。この例では、Microsoft Wordドキュメントにタグを配置する際に使用される書式を示しています。 -![Using tags in a Microsoft Word document](images/sing-structured-tags-sample.png) +![Microsoft Wordドキュメントでのタグの使用](images/sing-structured-tags-sample.png) -In the sample above `[[c|1]]` means a checkbox assigned to signer 1, and `[[s| -1]]` means a signature pad assigned to signer 1. Notice how the signature pad is using font size 48 to reserve space vertically for the signature. +上の例では、`[[c|1]]`は署名者1に割り当てられたチェックボックスを指し、`[[s| +1]]`は署名者1に割り当てられた署名パッドを指します。署名パッドでフォントサイズ48を使用して、署名用のスペースを縦方向に確保していることに注目してください。 -The `[[t|1|id:tag_full_name|n:enter your complete name]]` means a name tag assigned to signer 1, with the label `enter your complete name`, and using an id of `tag_full_name`. +`[[t|1|id:tag_full_name|n:enter your complete name]]`は、ラベル`enter your complete name`とID `tag_full_name`を使用して、署名者1に割り当てられた名前タグを指します。 -Check out this [document][support-tags] for a complete description of all the tags available. +利用可能なすべてのタグの詳細な説明については、こちらの[ドキュメント][support-tags]を参照してください。 -Setting the tags to the same `color` as the background will make them invisible, but they will still be there. +タグを背景と同じ`color`に設定すると、タグは見えなくなりますが、そこに存在はしています。 -The number in the tags refer to the signer number, not the signing order, so `[[c|1]]` is the checkbox for signer 1, `[[c|2]]` is the checkbox for signer 2, and so on. +タグ内の番号は、署名順序ではなく、署名者の番号を指すため、`[[c|1]]`は署名者1のチェックボックス、`[[c|2]]`は署名者2のチェックボックスのようになります。 -Tag 0 is reserved for the sender, and always exists. So even if the sender does not need to input any data into the document, the other signers must start with 1. +タグ0は送信者用に予約されており、必ず存在します。そのため、送信者がドキュメントにデータを入力する必要がない場合でも、他の署名者には1以降の番号を割り当てる必要があります。 -## Create a signature request from a structured document +## 構造化されたドキュメントからの署名リクエストの作成 -This is the same as creating a signature request from an unstructured document. At minimum, you will need to specify the document, the receiving folder and the email of the `signer`. +これは、非構造化ドキュメントから署名リクエストを作成する場合と同じです。少なくとも、ドキュメント、受信用フォルダ、および`signer`のメールアドレスを指定する必要があります。 -Since the structured document already contains the signature properties details and location, you can bypass the document preparation. +構造化されたドキュメントにはすでに署名プロパティの詳細と場所が含まれているため、ドキュメントの準備は省略できます。 -This is how the flow would look like, from the generated document, create the signature request and finally sign the document: +このフローは次のようになり、ドキュメントの生成から始まり、署名リクエストを作成して、最後にドキュメントに署名します。 -![Signing a structured document](images/sign-flow-tags.png) +![構造化されたドキュメントへの署名](images/sign-flow-tags.png) -Consider this method: +次のメソッドを考えてみましょう。 @@ -88,7 +88,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -128,7 +128,7 @@ def main(): -Resulting in (simplified): +結果は次のとおりです (簡略化されています)。 @@ -178,7 +178,7 @@ Resulting in (simplified): - + ```yaml @@ -195,19 +195,19 @@ Simple sign request: 6878e048-e9bd-4fb1-88c6-8e502783e8d0 -If you go to the `signer` email inbox, open the email from Box Sign, click on the `Review and Sign` button, you'll see the document with the signature properties in place: +`signer`のメールの受信トレイに移動し、Box Signからのメールを開き、\[`Review and Sign`] ボタンをクリックすると、署名プロパティが所定の位置に配置されているドキュメントが表示されます。 -![Document with the properties in place](images/sign-structured-signing-document.png) +![プロパティが所定の位置に配置されているドキュメント](images/sign-structured-signing-document.png) -After completing the process the signed document looks like this: +処理を完了すると、署名済みドキュメントは次のようになります。 -![Signed document](images/sign-structured-doc-finished.png) +![署名済みドキュメント](images/sign-structured-doc-finished.png) -## Pre-populate the signature attributes +## 署名の属性の事前入力 -If you have an external id in the document tags you can use it to pre-populate their values. For example, you can use the `tag_full_name` to pre-populate the name of the signer. +ドキュメントのタグに外部IDが設定されている場合は、その外部IDを使用して値を事前入力できます。たとえば、`tag_full_name`を使用して署名者の名前を事前に入力できます。 -See this method: +次のメソッドを確認してください。 @@ -246,7 +246,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -293,7 +293,7 @@ def main(): -Resulting in (simplified): +結果は次のとおりです (簡略化されています)。 @@ -358,7 +358,7 @@ Resulting in (simplified): - + ```yaml @@ -375,15 +375,15 @@ Simple sign request: 7b86e46c-72ba-4568-a6ff-787077cca007 -The document now has the name pre-populated: +これで、ドキュメントには名前が事前入力されるようになりました。 -![Document ready for sign with the name pre-populated](images/sign-structure-name-pre-pop.png) +![名前が事前入力された、署名の準備が整っているドキュメント](images/sign-structure-name-pre-pop.png) -## Extract information from a signed document +## 署名済みドキュメントからの情報の抽出 -Let's say you want to extract the name of the signer and the other properties from the signed document. This is useful if you need to tie the information from the signature request back into your systems. +たとえば、署名者の名前とその他のプロパティを署名済みドキュメントから抽出したいとします。これは、署名リクエストの情報を再度システムに紐付ける必要がある場合に便利です。 -Let's create a method to extract the information from the signed request: +署名済みリクエストから情報を抽出するメソッドを作成しましょう。 @@ -399,7 +399,7 @@ curl --location 'https://api.box.com/2.0/sign_requests/ - + ```python @@ -443,7 +443,7 @@ def main(): -Resulting in (simplified): +結果は次のとおりです (簡略化されています)。 @@ -534,7 +534,7 @@ Resulting in (simplified): - + ```yaml @@ -557,10 +557,10 @@ Simple sign request: 7b86e46c-72ba-4568-a6ff-787077cca007 ## まとめ -Structured documents are a great way to integrate with external document management systems, creating dynamic documents that are ready for signature. +構造化されたドキュメントの使用は、外部のドキュメント管理システムと統合して、署名可能な動的ドキュメントを作成するのに最適です。 -If your document signature requirements have a lot of options, you can pre-populate these from another data source and save the user's time, but remember that the user who owns these properties can always change them. +ドキュメントの署名要件に多くの選択肢がある場合は、別のデータソースからこれらを事前に入力して、ユーザーの時間を節約することができます。ただし、これらのプロパティを所有するユーザーはいつでもプロパティを変更できることを忘れないでください。 -After the document is signed you can extract the information from the signature request, which is useful if you need to tie it back into your systems. +ドキュメントが署名された後に署名リクエストから情報を抽出することができるので、その情報を再度システムに紐付ける必要がある場合に便利です。 [support-tags]: https://support.box.com/hc/en-us/articles/4404085855251-Creating-templates-using-tags diff --git a/pages/sign/technical-use-cases/sign-template.md b/pages/sign/technical-use-cases/sign-template.md index cdb5a40f2..618a308f1 100644 --- a/pages/sign/technical-use-cases/sign-template.md +++ b/pages/sign/technical-use-cases/sign-template.md @@ -15,41 +15,41 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/20-technical-use-cases/20-sign-template.md fullyTranslated: true --- -# Signing using templates +# テンプレートを使用した署名 -A [Box Sign template][template] is a specific type of document that not only contains the text, but also the signature requirements and placement. It is prepared for signing in advance, and as such can be sent directly to the signer or signers. +[Box Signテンプレート][template]は、テキストだけでなく、署名の要件や配置も含む特定の種類のドキュメントです。これは署名用に事前に準備されているため、署名者 (複数可) に直接送信できます。 -Required fields include, for example, the signature pad field, the full name, and the date. +必須フィールドには、署名パッド、フルネーム、日付などがあります。 -These fields have an owner, meaning they are populated by a specific signer and cannot be shared between them. They can be `mandatory` or `optional` , and be pre-populated by your application. However even if pre-populated, they can always be changed by the `signer`. +これらのフィールドには1人の所有者が設定されています。つまり、フィールドは特定の署名者が入力し、署名者間で共有することはできません。これらは、`mandatory`または`optional`にすることができるほか、アプリケーションによって事前入力することもできます。ただし、事前に入力されている場合でも、`signer`がいつでも変更できます。 -Within the Box web app, the template not only sets the signature fields, but also the number of signers, the order in which they sign, other roles and recipients such as `approver`, and `final_copy_recipient`, email notification settings, and a few more options. +Boxウェブアプリ内では、テンプレートによって、署名フィールドだけでなく、署名者の数、署名の順序、他の役割と受信者 (`approver`や`final_copy_recipient`など)、メール通知の設定、その他いくつかのオプションも設定されます。 -For a complete set of options of the signature request please refer to the [request options][request-options] section. +署名リクエストのオプションの詳細については、[リクエストのオプション][request-options]セクションを参照してください。 -These templates are exclusively created and managed in the Box Sign web app, and can be used to create signature requests using the API or the web app. +これらのテンプレートは、Box Signウェブアプリでのみ作成および管理され、APIまたはウェブアプリを使用して署名リクエストを作成する際に使用できます。 -Let's start by creating a template. +最初に、テンプレートを作成しましょう。 -## Creating a template +## テンプレートの作成 -From the Box app navigate to the sign menu on the left, then select templates. +Boxアプリで、左側の \[Sign] メニューに移動し、\[テンプレート] を選択します。 -![Navigating to templates under Box Sign](images/sign-template-navigate.png) +![Box Signで \[テンプレート\] に移動する](images/sign-template-navigate.png) -Then, click on the New Template button, and choose or upload the document from Box. +次に、\[新しいテンプレート] ボタンをクリックし、Boxからドキュメントを選択またはアップロードします。 -![Selecting a document when creating a template](images/sign-template-selecting-template.png) +![テンプレート作成時にドキュメントを選択する](images/sign-template-selecting-template.png) -For example, drag and drop a date, a name and a signature pad to the template, like so: +次のように、日付、名前、署名パッドをテンプレートにドラッグアンドドロップします。 -![Adding the signature, name, and date to the template](images/sign-template-signature-props.png) +![テンプレートに署名、名前、日付を追加する](images/sign-template-signature-props.png) -Save the template. +テンプレートを保存します。 -## Identify the template +## テンプレートの識別 -In order to work with templates in the Box Sign API we are going to need the `template_id` . Consider this method to list all the templates available to the user: +Box Sign APIでテンプレートを使用するには、`template_id`が必要になります。ユーザーが利用できるすべてのテンプレートのリストを取得するための次のメソッドを考えてみます。 @@ -64,7 +64,7 @@ curl --location 'https://api.box.com/2.0/sign_templates' \ - + ```python @@ -91,7 +91,7 @@ def main(): -Returns something similar to (simplified): +次のような結果が返されます (簡略化されています)。 @@ -165,7 +165,7 @@ Returns something similar to (simplified): - + ```yaml @@ -180,16 +180,16 @@ Sign templates: 1 -## Creating a signature request from a template +## テンプレートからの署名リクエストの作成 -The big advantage of using templates is that we do not need to worry about document preparation. Most of the signature options can be set in the template itself. +テンプレートを使用する大きなメリットは、ドキュメントの準備について心配する必要がないことです。ほとんどの署名オプションはテンプレート自体で設定できます。 -This is how the flow would look like: +このフローは次のようになります。 -![Signing using a template](images/sign-flow-template.png) -Using a signature template, create the signature request, and finally sign the document. +![テンプレートを使用した署名](images/sign-flow-template.png) +署名テンプレートを使って署名リクエストを作成し、最終的にドキュメントに署名します。 -See this example: +次の例を確認してください。 @@ -218,7 +218,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -253,7 +253,7 @@ def main(): -Resulting in (simplified): +結果は次のとおりです (簡略化されています)。 @@ -297,7 +297,7 @@ Resulting in (simplified): - + ```yaml @@ -314,35 +314,35 @@ Simple sign request: b25674a2-540b-4201-ae18-a78f05ef1a9a -The signer receives an email from Box.com with a link to the document, and can sign it. +署名者は、ドキュメントへのリンクが記載されたメールをBox.comから受信すると、そのドキュメントに署名できます。 -Since the template already had the signature requirements, document preparation was not needed. Notice the date was automatically populated with the current date. +テンプレートにはすでに署名要件が設定されているため、ドキュメントの準備は必要ありませんでした。日付には現在の日付が自動的に入力されていることに注意してください。 -## Pre-populate the signature attributes +## 署名の属性の事前入力 -From a usability perspective, it is a good idea to pre-populate the inputs you require from your users. +使いやすさの観点から、ユーザーに求める入力データを事前入力することをお勧めします。 -Some inputs may be intentionally left unpopulated. For example, when your legal department specifies that the “Yes, I agree” field must be explicitly set by the signer. +一部の入力データは意図的に入力されていない可能性があります。たとえば、法務部門では、署名者が明示的に「はい、同意します」と設定する必要があると規定している場合があります。 -Using the Box app sign template editor, you can assign an `external_id` to each of the inputs, and have the app populate them from any data source. +BoxアプリのSignテンプレートエディタを使用すると、各入力データに`external_id`を割り当てて、アプリに任意のデータソースから入力データを入力させることができます。 -Let’s implement this for the name. +これを名前に実装しましょう。 -Go back to the template design and add an id to the name field: +テンプレートのデザインに戻り、名前フィールドにIDを追加します。 -![Assigning a tag id to a signature property input](images/sign-template-add-id-to-name-prop.png) +![署名プロパティの入力データにタグIDを割り当てる](images/sign-template-add-id-to-name-prop.png) -Save the template. +テンプレートを保存します。 -Let’s create a new method to pre-populate the name: +名前を事前入力する新しいメソッドを作成しましょう。 @@ -377,7 +377,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -419,7 +419,7 @@ def main(): ``` -Resulting in (simplified): +結果は次のとおりです (簡略化されています)。 @@ -473,7 +473,7 @@ Resulting in (simplified): - + ```yaml @@ -490,17 +490,17 @@ Simple sign request: adab1740-eeba-4392-a3f5-defddc79c946 -Open the signer inbox and complete the sign request. +署名者の受信トレイを開き、署名リクエストを完了します。 -![Signing the document](images/sign-template-name-populated.png) +![ドキュメントに署名する](images/sign-template-name-populated.png) -When the signer views the document, the `signer` can still change it. +`signer`はドキュメントを表示している場合、その名前を変更できます。 -## Get more information about a template +## テンプレートに関する詳細情報の取得 -You've seen that you can list the templates available to a user. But you can also get more information about a specific template. +ユーザーが利用できるテンプレートのリストを取得できることはわかりましたが、特定のテンプレートに関する詳細情報を取得することもできます。 -Let’s create a method that returns basic information of a template, but details all the signature requirements: +テンプレートの基本情報を返すほか、署名要件をすべて列挙するメソッドを作成しましょう。 @@ -516,7 +516,7 @@ f2ec720d-47a6-4052-8210-9bfa8d6c349c' \ - + ```python @@ -541,7 +541,7 @@ def main(): ``` -Resulting in (simplified): +結果は次のとおりです (簡略化されています)。 @@ -611,7 +611,7 @@ Resulting in (simplified): - + ```yaml @@ -632,19 +632,19 @@ Sign template: 94e3815b-f7f5-4c2c-8a26-e9ba5c486031 - Simple-PDF.pdf -Notice that the `signer_full_name` is the `tag_id` we used to pre-populate the name. +`signer_full_name`は、名前を事前に入力するために使用した`tag_id`であることに注意してください。 ## まとめ -Templates are a form of signing structured documents where the signature requirements are already defined and placed on the document. +テンプレートは、署名用の構造化されたドキュメントの一種で、署名要件がすでに定義され、ドキュメントに配置されています。 -This not only keeps your contract management team happy, but it also creates a process which is consistent and requires a low level of effort from your users. +これは、契約管理チームを満足させるだけでなく、ユーザーの労力をあまり必要としない一貫性のあるプロセスを構築します。 -Finally if your document signature requirements have a lot of options, you can pre-populate these from another data source and save the user some time. Remember that the user who owns these properties can always change them. +さらに、ドキュメントの署名要件に多くのオプションがある場合は、別のデータソースからこれらを事前に入力して、ユーザーの時間を節約することができます。これらのプロパティを所有するユーザーはいつでもプロパティを変更できることを忘れないでください。 -There is no API entry point to create a template, so you will have to create and manage them manually from the Box app, unless the document already includes signature tags that can be used by the Box Sign engine. Take a look at our [Structured Docs][structured-docs] section for more information. +テンプレートを作成するためのAPIエントリポイントはないため、Box Signエンジンで使用できる署名タグがすでにドキュメントに含まれている場合を除き、Boxアプリから手動でテンプレートを作成して管理する必要があります。詳細については、[構造化ドキュメント][structured-docs]のセクションを参照してください。 [template]: https://support.box.com/hc/en-us/sections/21356768117651-Templates diff --git a/pages/sign/technical-use-cases/sign-unstructured-docs.md b/pages/sign/technical-use-cases/sign-unstructured-docs.md index 3ecd0858d..1026898f1 100644 --- a/pages/sign/technical-use-cases/sign-unstructured-docs.md +++ b/pages/sign/technical-use-cases/sign-unstructured-docs.md @@ -15,18 +15,18 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/20-technical-use-cases/10-sign-unstructured-docs.md fullyTranslated: true --- -# Signing unstructured docs +# 非構造化ドキュメントへの署名 -Imagine a document management app, where users can upload a document and ask anyone to sign it. In this case your app will know what document to sign and who needs to sign, but it has no idea where to put the signature or its properties like name, date, initial, and so on. +ユーザーがドキュメントをアップロードし、誰にでもそのドキュメントへの署名を依頼できるドキュメント管理アプリを想像してみてください。この場合、アプリは、署名対象のドキュメントと署名する必要がある人を認識しますが、署名やそのプロパティ (名前、日付、イニシャルなど) を配置する場所は認識しません。 -This contrasts with [using templates][sign-templates] or [structured documents][structured documents] [sign-structured-docs][sign-structured-docs] where your app knows what they are, and where the signature properties go. +これは、[テンプレート][sign-templates]や[構造化されたドキュメント][structured documents] [sign-structured-docs][sign-structured-docs]を使用する場合とは対照的です。これらを使用する場合、アプリは、署名プロパティの内容や場所を認識します。 -In these cases, and because each document can have a different structure, it is a good idea to always set the `is_document_preparation_needed` flag set to `true`, so that the sender has a chance to select and place the signature properties in the document before the signer gets the request. +このような場合、各ドキュメントに異なる構造を使用できるため、常に`is_document_preparation_needed`フラグを`true`に設定することをお勧めします。これにより、署名者がリクエストを受け取る前に、送信者は署名プロパティを選択してドキュメントに配置できるようになります。 -There are three steps to this flow, creating the signature request, then preparing the document, and finally signing it. This is how the flow looks like: -![Sign unstructured docs flow](images/unstructured-docs-flow.png) +このフローには、署名リクエストの作成、ドキュメントの準備、署名という3つのステップがあります。フローは次のようになります。 +![非構造化ドキュメントへの署名フロー](images/unstructured-docs-flow.png) -Consider this example: +次の例を考えてみます。 @@ -60,7 +60,7 @@ curl --location 'https://api.box.com/2.0/sign_requests' \ - + ```python @@ -105,7 +105,7 @@ def main(): -This results in a signature request with a prepare document URL (simplified): +これの結果、ドキュメント準備のURL (簡略化されています) を含む署名リクエストが作成されます。 @@ -156,7 +156,7 @@ This results in a signature request with a prepare document URL (simplified): - + ```yaml @@ -171,23 +171,23 @@ Prepare url: https://app.box.com/sign/document/xyz-abc-123/.../prepare_doc/ -Notice in the above script that, if a prepare document URL was generated by the signature request, then the app opens a browser for it. The requester can then apply the different signature properties, for example: +上記のスクリプトでは、ドキュメント準備のURLが署名リクエストによって生成された場合、アプリによってそのURLのためにブラウザが開くことに注意してください。その後、リクエスト送信者は、次のようにさまざまな署名プロパティを適用できます。 -![Preparing the document using drag and drop on the template editor](images/sign-pdf-prep-doc.png) +![テンプレートエディタでドラッグアンドドロップを使用してドキュメントを準備する](images/sign-pdf-prep-doc.png) -Once the document is prepared, the requester can send the signature request to the signer. +ドキュメントが準備できたら、リクエスト送信者は署名リクエストを署名者に送信できます。 -Back in the Box app you can see the status `In Progress`. +Boxアプリに戻ると、ステータスが`In Progress`になっていることがわかります。 -![Pending signature request](images/sign-request-pending.png) +![保留中の署名リクエスト](images/sign-request-pending.png) -The signer then receives an email from Box with a link to the signature request. +その後、署名リクエストへのリンクが記載されたメールがBoxから署名者に送信されます。 -![Signing the document](images/sign-pdf-prep-finish-sign.png) +![ドキュメントに署名する](images/sign-pdf-prep-finish-sign.png) -When the process is completed, both a signature log containing metadata and the signed document are stored in the destination folder. +処理が完了すると、メタデータを含む署名ログと署名済みドキュメントの両方が保存先フォルダに格納されます。 -![Log and signed document](images/sign-pdf-signed-docs.png) +![ログと署名済みドキュメント](images/sign-pdf-signed-docs.png) [sign-templates]: page://sign/technical-use-cases/sign-template diff --git a/pages/sign/webhooks/index.md b/pages/sign/webhooks/index.md index 3e20dda61..f44909864 100644 --- a/pages/sign/webhooks/index.md +++ b/pages/sign/webhooks/index.md @@ -19,21 +19,21 @@ source_url: >- https://github.com/box/developer.box.com/blob/main/content/pages/sign/40-webhooks/index.md fullyTranslated: true --- -# Sign webhooks +# Sign Webhook -Sign webhooks allow you to receive notifications about events that happen with the signature requests. You can use them to trigger actions in your own application, or to notify your users about events that happen in Sign. +Sign Webhookを使用すると、署名リクエストに伴って発生したイベントに関する通知を受信することができます。Sign Webhookを使用して、自分のアプリケーションで操作を開始したり、Signで発生したイベントについてユーザーに通知したりできます。 -This is particularly important since the signature requests are asynchronous, and the signers can interact with them at any time, possibly outside of your application. +署名リクエストが非同期処理で、署名者はいつでも (場合によってはアプリケーション外部でも) 署名リクエストを操作できるので、これは特に重要になります。 -## Sign related events +## Sign関連のイベント -There are Sign related events that can trigger the webhooks. Like most of Box events the listeners are set at folder or document level. +WebhookをトリガーできるSign関連のイベントがあります。Boxイベントの大半と同様、リスナーはフォルダレベルまたはドキュメントレベルで設定されます。 -The most common use case is to listen to the events at the folder where the sign requests are created. This way you can listen to all the signature requests created in that folder. +最も一般的なユースケースでは、署名リクエストが作成されるフォルダでイベントをリッスンします。このように、そのフォルダに作成されるすべての署名リクエストをリッスンできます。 -Some examples of events that can be listened to are: +リッスンできるイベントの例を以下に示します。 -* `SIGN_REQUEST.COMPLETED`, when a signature request is completed. -* `SIGN_REQUEST.DECLINED`, when a signature request is declined. -* `SIGN_REQUEST.EXPIRED`, when a signature request expires. -* `SIGN_REQUEST.SIGNER_EMAIL_BOUNCED`, when a signer's email is bounced. +* `SIGN_REQUEST.COMPLETED`: 署名リクエストが完了した。 +* `SIGN_REQUEST.DECLINED`: 署名リクエストが拒否された。 +* `SIGN_REQUEST.EXPIRED`: 署名リクエストの有効期限が切れた。 +* `SIGN_REQUEST.SIGNER_EMAIL_BOUNCED`: 署名者のメールが差し戻された。