docs: add japanese translations

README.md

@@ -29,3 +29,10 @@ This command generates static content into the `build` directory and can be serv
 ### Deployment
 
 GitHub Actions will deploy it automatically to Firebase Hosting.
+
+
+### Run project locally in different languages
+
+```
+npm run start -- --locale ja
+```

crowdin.yml

@@ -0,0 +1,10 @@
+project_id: '619760'
+api_token: 71920d310ddf281a4d742dbeae5fba47c3f3c577bbd243c98f2dbfd917dd166e11aa6bcf4235b4e8
+preserve_hierarchy: true
+files:
+  # JSON translation files
+  - source: /i18n/en/**/*
+    translation: /i18n/%two_letters_code%/**/%original_file_name%
+  # Docs Markdown files
+  - source: /docs/**/*
+    translation: /i18n/%two_letters_code%/docusaurus-plugin-content-docs/current/**/%original_file_name%

docs/best-practices/account-types.mdx → docs/configuration/account-types.mdx

@@ -1,7 +1,7 @@
 ---
 title: Bucketeer account types
 # sidebar_position:
-slug: /best-practice/account-types
+slug: /configuration/account-types
 description: This page describes the existing account types available on Bucketter.
 tags: ['guide', 'account', 'account-types']
 ---

docs/configuration/api-keys.mdx

@@ -0,0 +1,35 @@
+---
+title: API keys
+# sidebar_position:
+slug: /configuration/api-keys
+description: Describes what API keys are, what they are used for, and how to create them.
+tags: ['integration', 'feature-flag']
+---
+
+import CenteredImg from '@site/src/components/centered-img/CenteredImg';
+
+On this page your find information about what are API Keys, how to create them and their role on Bucketeer system.
+
+## What are API Keys
+
+When working with flags in Bucketeer, API keys are essential. They authorize and control access to the feature flag management system, providing authentication capabilities that ensure secure connections between your application and the Bucketeer management service. Each API key is associated with a specific project and environment, allowing you to identify and link your application to the desired user group. By requiring a valid API key for accessing the flag information, the security and integrity of the system is maintained, reducing the risk of unauthorized entry or manipulation with feature flag configurations.
+
+When setting up the SDK on your application, you must include a valid API key. This key is necessary for the server to recognize that the request is valid when the SDK performs a server request. If you provide an invalid API key during configuration, the server will deny the request. For more information on configuring the SDK, refer to the [SDK's documentation](../sdk).
+
+## Creating an API Key
+
+To create an API Key, you need to be an Admin or have an environment account with the Owner role. Other members can see the APY keys but can't manage them.
+
+To generate a new API key in the Bucketeer dashboard, navigate to the **API Keys** tab. This section will present a list of all currently available API keys. If you wish to create a new one, click the **+ Add** button. A side panel will appear on the right side of your screen. Enter a name for the new key, limited to one hundred characters, and finalize the process by clicking **Submit**. The new key will show up at the top of the **API Keys** list.
+
+<CenteredImg
+  imgURL="img/feature-flags/api-keys/create-api-key.png"
+  alt="Account dashboard tab"
+  wSize="100%"
+/>
+
+The Bucketeer team advises giving each API key a meaningful name based on its associated feature or project to make it easy to manage. Avoid using randomly generated names as they can cause confusion and make it difficult to identify where the API key is being used.
+
+## Manage your API Keys
+
+Once an API key is created, it becomes immediately available for use and is set to the **ON** state. In addition, it grants access to all feature flags within the current environment. The Bucketeer dashboard does not offer a direct option to delete API keys. However, if a key is no longer required, you can toggle its state to **OFF** using the available switch button in the **API Keys** tab. This action will result in denying all SDK requests using that specific key.

docs/configuration/configuration.md

@@ -0,0 +1,17 @@
+---
+id: configuration
+title: Configuration
+slug: /configuration
+---
+
+# Configurations
+
+In this category, you will find information regarding complementary settings you can do when using the Bucketeer dashboard. The configurations available on these pages support the feature flag creation and usage. Below, you find the links and a brief description for each section.
+
+## API keys
+
+The [API keys](/configuration/api-keys) describe what they're and how they're used to authenticate and control access to the Bucketeer system.
+
+## Account types
+
+The [Account types](/configuration/account-types) present the different account types available on Bucketeer. You can use these different account types to provide different access levels to each team member.

docs/feature-flags/api-keys.mdx

@@ -32,4 +32,4 @@ The Bucketeer team advises giving each API key a meaningful name based on its as
 
 ## Manage your API Keys
 
-Once an API key is created, it becomes immediately available for use and is set to the **ON** state. In addition, it grants access to all feature flags within the current environment. The Bucketeer dashboard does not offer a direct option to delete API keys. However, if a key is no longer required, you can toggle its state to **OFF** using the available switch button in the **API Keys** tab. This action will result in denying all SDK requests using that specific key.
+Once an API key is created, it becomes immediately available for use and is set to the **ON** state. In addition, it grants access to all feature flags within the current environment. The Bucketeer dashboard does not offer a direct option to delete API keys. However, if a key is no longer required, you can toggle its state to **OFF** using the available switch button in the **API Keys** tab. This action will result in denying all SDK requests using that specific key.

docs/feature-flags/creating-feature-flags/auto-operation/auto-operation.mdx

@@ -0,0 +1,39 @@
+---
+title: Auto operation
+# sidebar_position:
+slug: /feature-flags/creating-feature-flags/auto-operation
+description: The Auto Operation feature handles the manipulation of feature flag configurations on your behalf. It executes specific operations automatically based on the conditions set by the user.
+tags: ['guide', 'automation', 'operation', 'feature-flag']
+---
+
+import CenteredImg from '@site/src/components/centered-img/CenteredImg';
+
+The auto operation feature handles the manipulation of feature flag configurations on your behalf. It executes specific operations automatically based on the conditions set by the user.
+
+To access the auto operation page go to the Feature Flag detail page and click on the **Auto Operation** tab. You can check the active and completed operations.
+
+## How auto operation works
+
+The auto operation feature consists of two key elements:
+
+- **Operation**: An operation refers to an action that impacts a feature flag. Each action is linked to one or more triggering conditions. When a condition is met, the associated operation's action is executed. Currently, Bucketeer supports two types of operations:
+
+  - **Enable**: Enables the chosen flag when the condition is met. You can release using the **[schedule](/feature-flags/creating-feature-flags/auto-operation/schedule)** or **[progressive rollout](/feature-flags/creating-feature-flags/auto-operation/rollout)** options.
+  - **Kill Switch**: Disables the chosen flag when the condition is met. You can disable it using the **[schedule](/feature-flags/creating-feature-flags/auto-operation/schedule)** or **[event rate](/feature-flags/creating-feature-flags/auto-operation/event-rate)**.
+
+- **Condition**: A condition specifies the circumstances under which the operation is triggered. Multiple conditions can be associated with a single killing operation. On the other hand, only one condition can be related to enabling a feature. Similarly, each rollout phase is linked to a condition. It's important to note that the corresponding operation is triggered if any conditions are satisfied.
+
+Based on the operations and condition the auto operation works as:
+
+1. The server monitors the specified conditions.
+2. When a condition is met, the corresponding operation is executed.
+3. After enabling or disabling the associated flag, the triggered operation's status changes from active to complete.
+4. The operation is moved from the Active to the Completed panel, indicating that it has been executed.
+
+## Conditions
+
+As mentioned, a condition must be fulfilled to trigger an auto operation. Currently, Bucketeer provides three condition options, which you can use to configure auto operations in your application:
+
+- [Schedule](/feature-flags/creating-feature-flags/auto-operation/schedule):: Specify the date and time to enable or kill a flag.
+- [Progressive rollout](/feature-flags/creating-feature-flags/auto-operation/rollout): Determine a strategy to release a feature flag variation progressively.
+- [Event rate](/feature-flags/creating-feature-flags/auto-operation/event-rate): Define conditions to kill a flag based on the rate of a particular event.

docs/feature-flags/creating-feature-flags/auto-operation/event-rate.mdx

@@ -0,0 +1,55 @@
+---
+title: Event rate
+# sidebar_position:
+slug: /feature-flags/creating-feature-flags/auto-operation/event-rate
+description: 'Check how the event rate features works in Bucketeer'
+tags: ['guide', 'automation', 'event rate', 'feature-flag']
+---
+
+import CenteredImg from '@site/src/components/centered-img/CenteredImg';
+
+The event rate condition is designed to turn off flags based on the usage rate. Some popular usage cases for these conditions are:
+
+- Kill automatically flags causing high error rates.
+- Turn off a flag you use to collect data for analysis. Therefore, the event rate condition can turn the flag off when enough data is collected.
+- Disable a flag that has been visited a certain number of times. Each time a user visits the flag, you can send that event, allowing the system to turn it off for you when it reaches the threshold.
+
+## How the event rate works
+
+The event rate condition triggers the operation when the frequency of a particular event reaches a specific threshold. For instance, whenever a user visits a flag, you can send an event through the SDK to track that visit. The Bucketeer system then receives these events and keeps track of the frequency of each flag variation. Thus, the system can evaluate the event rate and determine if it needs to turn off a particular flag.
+
+To set up the event rate condition, you need to define the following configurations:
+
+- **Variation**: The specific variation observed by the target user. The event rate will be calculated using the events called using this variation.
+- **Goal**: The goal used to calculate the event rate. The counter of goal events will increase each time the goal is reached.
+- **Condition**: The comparison operator used to assess the event rate. The available options are greater than or equal to (>=) or smaller than or equal to (<=). 
+- **Percentage**: The threshold for the event rate.
+- **Minimum Count**: Minimum number of occurrences required for the condition to be enabled. This option ensures that the event rate is not triggered before a certain number of events happen, avoiding a false positive.
+
+## How the event rate is calculated
+
+Bucketeer system uses the following formula to calculate the event rate:
+
+**Event Rate = (Unique Counter of Goal Events) / (Unique Counter of Evaluation Events)**
+
+Refer to the [Experiments](/feature-flags/testing-with-flags/experiments) and [Evaluate results](/feature-flags/creating-feature-flags/evaluate-results) sections for a better understanding of the user count of goals and evaluations.
+
+## Setting up auto operation with event rate
+
+To add an event rate condition to a feature flag, you need to follow the steps below:
+
+1. Go to the **Auto Operation** page.
+2. Click the **+ Add** button.
+3. The operation setting panel will appear. Choose the **Kill Switch** option.
+4. Select **Event Rate**.
+5. Set up the conditions. Define the variation, goal, condition, threshold, and minimum count.
+6. Click **Submit**. 
+
+The image below presents an example of event rate configuration. The current configuration's objective is to turn off the feature flag in case of a high error rate above 5%. A minimum count of 500 is used to avoid misleading turn-offs.
+
+<CenteredImg
+  imgURL="img/feature-flags/auto-ops-rules/event-rate-condition-v3.png"
+  alt="Create event rate condition"
+  wSize="400px"
+  borderWidth="1px"
+/>