diff --git a/README.md b/README.md index 3ebfcef5..98fdc4cf 100644 --- a/README.md +++ b/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 +``` \ No newline at end of file diff --git a/crowdin.yml b/crowdin.yml new file mode 100644 index 00000000..c8e02e54 --- /dev/null +++ b/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% diff --git a/docs/best-practices/account-types.mdx b/docs/configuration/account-types.mdx similarity index 98% rename from docs/best-practices/account-types.mdx rename to docs/configuration/account-types.mdx index d6b3e923..b9f1ea73 100644 --- a/docs/best-practices/account-types.mdx +++ b/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'] --- diff --git a/docs/configuration/api-keys.mdx b/docs/configuration/api-keys.mdx new file mode 100644 index 00000000..13fcb39d --- /dev/null +++ b/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. + + + +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. diff --git a/docs/configuration/configuration.md b/docs/configuration/configuration.md new file mode 100644 index 00000000..8e74c0d5 --- /dev/null +++ b/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. diff --git a/docs/feature-flags/api-keys.mdx b/docs/feature-flags/api-keys.mdx index d26051d9..8462d82d 100644 --- a/docs/feature-flags/api-keys.mdx +++ b/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. \ No newline at end of file diff --git a/docs/feature-flags/creating-feature-flags/auto-operation.mdx b/docs/feature-flags/creating-feature-flags/auto-operation.mdx deleted file mode 100644 index fff38929..00000000 --- a/docs/feature-flags/creating-feature-flags/auto-operation.mdx +++ /dev/null @@ -1,94 +0,0 @@ ---- -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 on the Bucketeer dashboard, select the **Feature Flags** tab, choose the desired flag, and click on its name. Select the **Auto Ops Rules** tab at the top of the new page. You can check the active and completed operations on the Auto Ops Rules page. - -## 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**: This operation type enables the chosen flag. - - **Kill Switch**: This operation type disables the chosen flag. - -- **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. 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 - -The following conditions are available for defining auto operations: - -1. **Schedule**: This condition evaluates whether the specified date and time have been reached. You must always use a future date and time to schedule the operation. It is useful, for example, to release a feature at a specific date and time or to turn off a beta feature after a certain period. - - - -:::info Limit of schedule conditions - -You can only have two active operations based on schedule conditions. One will define when to enable and the other when to kill the flag. - -::: - -2. **Event Rate**: This condition triggers the operation based on the event rate reaching a specified threshold. The event rate is only available for killing operations. It allows you to automatically turn off a flag if it is causing a high error rate or turn it off once enough data has been collected for analysis. - - - -Below, you will find a description of the configuration options for setting up the event rate condition: - -- **Variation**: The specific variation observed by the target user. -- **Goal**: The goal used to calculate the event rate. Each time the goal is reached, the counter of goal events will increase. -- **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. - -## How the event rate is calculated - -The event rate is calculated using the following formula: - -**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 - -Configuring auto operations is a straightforward process. Follow these steps: - -1. Go to the Auto Ops Rules page. -2. Click the **Add operation** button. -3. The operation setting panel will appear. Choose the desired operation. For this example, the **Enable** option was selected. -4. Set up the desired condition. For the **Enable** operation, only the **Schedule** is available. -5. Click the **Create Operation** button to create the auto operation rule. The image below summarizes the configuration described in the previous steps. - - - -When the scheduled time arrives, the feature flag will be automatically enabled. diff --git a/docs/feature-flags/creating-feature-flags/auto-operation/auto-operation.mdx b/docs/feature-flags/creating-feature-flags/auto-operation/auto-operation.mdx new file mode 100644 index 00000000..7852d3d6 --- /dev/null +++ b/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. \ No newline at end of file diff --git a/docs/feature-flags/creating-feature-flags/auto-operation/event-rate.mdx b/docs/feature-flags/creating-feature-flags/auto-operation/event-rate.mdx new file mode 100644 index 00000000..ba12dc3c --- /dev/null +++ b/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. + + \ No newline at end of file diff --git a/docs/feature-flags/creating-feature-flags/auto-operation/rollout.mdx b/docs/feature-flags/creating-feature-flags/auto-operation/rollout.mdx new file mode 100644 index 00000000..e90517bf --- /dev/null +++ b/docs/feature-flags/creating-feature-flags/auto-operation/rollout.mdx @@ -0,0 +1,91 @@ +--- +title: Rollout +# sidebar_position: +slug: /feature-flags/creating-feature-flags/auto-operation/rollout +description: 'Check how the rollout features works in Bucketeer' +tags: ['guide', 'automation', 'rollout', 'feature-flag'] +--- + +import CenteredImg from '@site/src/components/centered-img/CenteredImg'; + +The rollout solution is designed to deliver new features for your users progressively. It automates the release process, gradually providing the flag variation you choose to a larger percentage of your users to ensure it performs as expected. You can use this approach to detect problems and reduce the impact in the earlier stage. + +When you use the rollout option, you select an enabling operation from the [Auto Operation](/feature-flags/creating-feature-flags/auto-operation). That means that you will choose the flag variation that more users will receive as time goes on and the rollout approaches its end. + +## Rollout requirements and restriction + +You need to fulfill some requirements to use the rollout feature. Otherwise, you will not be able to set it. The list below summarizes the restrictions related to the rollout creation: + +- The rollout only works for flags with two variations. If you try to use it with a flag with more variations, you will receive an error message when submitting it. +- You are not able to add a rollout to a flag with [Prerequisites](/feature-flags/creating-feature-flags/targeting#prerequisites), [Targets](/feature-flags/creating-feature-flags/targeting#targeting), or [Rules](/feature-flags/creating-feature-flags/targeting#rollout-percentage). +- To add a rollout, the feature flag must be active. + +No restrictions apply to the flag type. This means you can use the rollout feature with all [feature flag types](/feature-flags/creating-feature-flags/create-feature-flag#feature-flags-types). + +## How rollout works + +The rollout feature is designed to work with two variation flags. It allows you to progressively make an existing variation available for a larger user group until it is available for all users. + +To understand how the rollout feature works, let's consider a boolean flag with `true` and `false` variations, which defines if new content is available to users. Currently, the `false` variation is the [off variation](/feature-flags/creating-feature-flags/targeting#the-targeting-page), which means users cannot see the new content. However, the content is ready to launch, and you want to make it available to all users in a span of 10 days. For this scenario, you can use the rollout feature to roll out the `true` variation progressively at 10% daily. On the first day of the rollout, 10% of your users will see the new content, and by the second day, 20% will see it, and so on. After 10 days, the rollout will be complete, and all users will have access to the new content. The image below summarizes the rollout process. + + + +## Configuring a rollout + +To add a rollout 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 **Enable** operation. +4. Select **Progreesive Rollout**. +5. Set up the rollout. +6. Click **Submit**. + +The rollout provides two main options when setting it up: + +- **Template**: With this option, you define the percentual increment and the frequency of the rollout. The weight of each phase and the execution time are automatically defined until the rollout reaches 100%. +- **Manual**: In this case, you are responsible for defining each rollout phase's percentual weight and release time. + +### Template rollout + +If you choose to use the Template rollout, you need to define the following configurations before submitting it: + +- **Variation**: Choose the variation to roll out. You should not choose the same variation selected as [off variation](/feature-flags/creating-feature-flags/targeting#the-targeting-page). Otherwise, you will receive an error message. +- **Start Date**: The rollout starting date and time. +- **Increment**: The percentual increment to be used at each rollout release phase. This option will define, as a result, the total number of rollout releases. If you choose 10%, 10 stages are required to reach the total rollout. +- **Frequency**: The frequency of each rollout phase (hourly, daily, weekly) will be released. The first phase will depend on the **Start Date** value you selected, and the remaining phases will rely on this starting point. + +Notice that when using the Template rollout, all phases increment the percentage of users accessing the new variation by the same amount, defined by the **Increment** parameter. The image below summarizes an example of a configuration using the Template configuration. + + + +### Manual rollout + +When using the Manual rollout, the configurations required to submit the rollout differ from those used on the Template rollout. In this case, you need to set the following parameters: + +- **Variation**: Choose the variation to roll out. You should not choose the same variation selected as [off variation](/feature-flags/creating-feature-flags/targeting#the-targeting-page). Otherwise, you will receive an error message. +- **Weight**: The percentual value of users receiving the selected variation at the selected date. +- **Execute at**: The date and time when the rollout phase will be released, updating the percentage of users accessing the selected variation. + +Using the Manual rollout, you do not need to follow an incremental rule for each rollout phase. The only restriction is that each new rollout phase must have a higher weight than the previous one. + +Another important point related to the Manual option is that you don't need to reach 100% to submit the rollout. Suppose the last entry to the Manual configuration is 90%. In this case, the rollout will be concluded, and only 90% of your users will have access to the new variation. The remaining 10% will continue receiving the [off variation](/feature-flags/creating-feature-flags/targeting#the-targeting-page), the same as before the rollout. + +The image below summarizes an example of a configuration using the Manual configuration. + + \ No newline at end of file diff --git a/docs/feature-flags/creating-feature-flags/auto-operation/schedule.mdx b/docs/feature-flags/creating-feature-flags/auto-operation/schedule.mdx new file mode 100644 index 00000000..9c35a04d --- /dev/null +++ b/docs/feature-flags/creating-feature-flags/auto-operation/schedule.mdx @@ -0,0 +1,43 @@ +--- +title: Schedule +# sidebar_position: +slug: /feature-flags/creating-feature-flags/auto-operation/schedule +description: 'Check how the schedule features works in bucketeer. Use it to release or remove a flag variation.' +tags: ['guide', 'automation', 'schedule', 'feature-flag'] +--- + +import CenteredImg from '@site/src/components/centered-img/CenteredImg'; + +The schedule solution is designed to deliver or remove a feature at a specific date and time. Therefore, you can use it to release a new feature for holidays or special promotions, for example. The same solution can be used to remove the temporary feature after the holidays or to turn off a beta feature after a certain period. + +## How the schedule works + +When you use the Bucketeer auto operation with the schedule condition, you will manage your flags based on the date and time you define. When the Bucketeer receives the SDK request, the schedule condition evaluates whether the specified date and time have been reached. If so, the operation of enabling or killing a flag variation is executed. + +:::info Schedule requisites and restrictions + +To use the schedule condition, you always need to use a future date and time to schedule the operation. + +You can only have two active operations based on schedule conditions. One will define when to enable and the other when to kill the flag. However, you aren't required to use both operations. You can use only the enable option, for example. + +::: + +## Setting up auto operation with schedule + +To release or kill a feature flag using the schedule option, 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 **Enable** operation to release or **Kill Switch** to remove a flag. +4. Select **Schedule**. +5. Set up the date and time. Remember, you need to select a future date and time. +6. Click **Submit**. + +The image below presents an example of schedule configuration for enabling a feature flag. + + \ No newline at end of file diff --git a/docs/feature-flags/creating-feature-flags/targeting.mdx b/docs/feature-flags/creating-feature-flags/targeting.mdx index e6dd2a58..e29a9b65 100644 --- a/docs/feature-flags/creating-feature-flags/targeting.mdx +++ b/docs/feature-flags/creating-feature-flags/targeting.mdx @@ -38,26 +38,26 @@ The below image presents an example of the **Targeting** page. ## How targeting works -On the targeting page, you can define a series of conditions which will define which flag variation the user will receive. Since several targeting option are provide, you need to undertand the evaluation order, otherwise, the targeting strategy may not reflect your objectives. To help you to have a better undertanding, the list below show the evaluation order with description related to the possible results. +On the targeting page, you can define a series of conditions defining which flag variation the user will receive. Since several targeting options are provided, you need to understand the evaluation order. Otherwise, the targeting strategy may reflect something other than your objectives. To help you understand better, the list below shows the evaluation order with a description of the possible results. -1. **Switch Button**: If the swtch in on the OFF position, users receive the OFF variation and no further evaluation is required. Otherwise, the evaluation checks if prerequisites exists. -2. [**Prerequisites**](/feature-flags/creating-feature-flags/targeting#prerequisites): Evaluate all existing prerequisite flags, if they exists. If all flags return the selected variation, satisfying all conditions, the evaluation goes to the next stage, defined by targeting or rollout percentage. If one of prerequisites fail, returning a different variation from the one specified, the user will receive the OFF variation and no further evaluation is required. -3. [**Targeting**](/feature-flags/creating-feature-flags/targeting#targeting): After prerequisites are satisfied, the targets are evaluated. Each user or user group will receive the variation you defined. In case the user/user group is not listed on any variation, rollout rules are evaluated if at least one exists, otherwise the user receive the default strategy variation. -4. [**Rule rollout percentage**](/feature-flags/creating-feature-flags/targeting#rollout-percentage): In case no rule is satisfied, the user receive the default strategy variation. +1. **Switch Button**: If the switch is on the OFF position, users receive the OFF variation, and no further evaluation is required. Otherwise, the evaluation checks if prerequisites exist. +2. [**Prerequisites**](/feature-flags/creating-feature-flags/targeting#prerequisites): Evaluate all existing prerequisite flags, if they exist. If all flags return the selected variation, satisfying all conditions, the evaluation goes to the next stage, defined by targeting or rollout percentage. If one of the prerequisites fails, returning a different variation from the one specified, the user will receive the OFF variation, and no further evaluation is required. +3. [**Targeting**](/feature-flags/creating-feature-flags/targeting#targeting): After prerequisites are satisfied, the targets are evaluated. Each user or user group will receive the variation you defined. If the user/user group is not listed on any variation, rollout rules are evaluated if at least one exists. Otherwise, the user receives the default strategy variation. +4. [**Rule rollout percentage**](/feature-flags/creating-feature-flags/targeting#rollout-percentage): If no rule is satisfied, the user receives the default strategy variation. -The fluxogram below summirizes how targeting on Bucketeer works. +The below flowchart summarizes how targeting on Bucketeer works. ### Prerequisites -When a prerequisite flag is added to targeting, the current flag is only evaluated if the prerequisite flag's returned value matches the configured value. This means that the target flag is only evaluated if the prerequisite conditions are satisfied. +When a prerequisite flag is added to a targeting configuration, the target flag is only evaluated if the prerequisite flag's returned value matches the configured value. This means that the target flag is only evaluated if the prerequisite conditions are fully satisfied. -If multiple flags are set as prerequisites, they are evaluated using the logical operator AND. This ensures that all prerequisite conditions are met before evaluating the target flag. If the return value from one of the prerequisite flags is not the expected value, the OFF variation in the target flag is returned. The OFF variation serves as the fallback option when the prerequisite conditions are not fulfilled. +If multiple flags are set as prerequisites, they are evaluated using the logical operator AND. This ensures that all prerequisite conditions are met before evaluating the target flag. In case the return value from one of the prerequisite flags is not as expected, the OFF variation in the target flag is returned. The OFF variation is used as a fallback option when the prerequisite conditions are not fulfilled. The image below presents an example using two flags as prerequisites. Therefore, the targeting or rollout percentage evaluation will only happen if the first flag returns the **true** variation and the second returns the **a** variation. Otherwise, the Bucketeer will provide the OFF variation. @@ -69,7 +69,7 @@ The image below presents an example using two flags as prerequisites. Therefore, ### Targeting -The Bucketeer targeting section allows you to define which users or groups receive each feature flag variation. Taking a boolean flag as an example, you could provide the true variation for Android users and the false variation for ios users, as shown in the image below. +The Bucketeer targeting section allows you to define which users or groups receive each feature flag variation. Taking a boolean flag as an example, you could provide the `true` variation for Android users and the `false` variation for iOS users, as shown in the image below. To get started, you will need to set up feature flags on the Bucketeer dashboard. You can refer to the - Using Feature Flags guide to learn more + Using Feature Flags guide to learn more about the process. Once you have your credentials and have created a feature flag, you can choose an SDK that best suits your application. The SDK @@ -97,7 +97,7 @@ Bucketeer was designed to accommodate different types of members. Below you find First and foremost, it's important to understand how to enable or disable feature flags. Familiarize yourself with managing flags and the mechanisms for toggling them on and off with the - Using Feature Flags guide. + Using Feature Flags guide.

In addition to managing flags, you play a crucial role in designing and @@ -111,7 +111,7 @@ Bucketeer was designed to accommodate different types of members. Below you find Utilizing feature flags enables you to conduct various types of testing, such as A/B testing. For more detailed information on experimentation, please refer to the - Testing with flags + Testing with flags resource.

@@ -150,11 +150,9 @@ Bucketeer was designed to accommodate different types of members. Below you find platform. This includes tasks such as adding or removing members, assigning appropriate roles and permissions, and ensuring that the right level of access is granted to individuals based on their responsibilities. Check{' '} - - Create Bucketeer's account - {' '} + Create Bucketeer's account{' '} to learn more about account creation or access the{' '} - Bucketeer account types to - learn more about the existing roles. + Bucketeer account types to learn + more about the existing roles.

diff --git a/docs/getting-started/quickstart/create-an-api-key.mdx b/docs/getting-started/quickstart/create-an-api-key.mdx index de319e6c..ef774e1e 100644 --- a/docs/getting-started/quickstart/create-an-api-key.mdx +++ b/docs/getting-started/quickstart/create-an-api-key.mdx @@ -25,4 +25,4 @@ The Bucketeer team recommends naming the API key based on the system where it wi wSize="100%" /> -After creating the API key, it will appear on the **API Keys** page, and its state will be **ON**, meaning it's ready for use. Now you can move on to the next step and [create your first feature flag](/getting-started/quickstart/create-your-first-flag). However, if you want to learn more about the usage of the API keys, check the [API keys](#) page. +After creating the API key, it will appear on the **API Keys** page, and its state will be **ON**, meaning it's ready for use. Now you can move on to the next step and [create your first feature flag](/getting-started/quickstart/create-your-first-flag). However, if you want to learn more about the usage of the API keys, check the [API keys](/configuration/api-keys) page. diff --git a/docs/sdk/client-side/android/index.md b/docs/sdk/client-side/android/index.md index 25594568..de516908 100644 --- a/docs/sdk/client-side/android/index.md +++ b/docs/sdk/client-side/android/index.md @@ -331,7 +331,7 @@ In regular use, you don't need to call the flush method because the events are s ### User attributes configuration -This feature will give you robust and granular control over what users can see on your application. You can add rules using these attributes on the console UI's feature flag's targeting tab. [See more](#). +This feature will give you robust and granular control over what users can see on your application. You can add rules using these attributes on the console UI's feature flag's targeting tab. [See more](/feature-flags/creating-feature-flags/targeting#user-attributes). @@ -388,7 +388,7 @@ This updating method will override the current data. ### Getting user information -This method will return the current user configured in the SDK. This is useful when you want to check the current user id and attributes before updating them through [updateUserAttributes](#updating-user-attributes). +This method will return the current user configured in the SDK. This is useful when you want to check the current user id and attributes before updating them through [updateUserAttributes](android#updating-user-attributes). @@ -414,7 +414,7 @@ val evaluationDetails = client.evaluationDetails("YOUR_FEATURE_FLAG_ID") :::caution -Do not call this method without calling the [Evaluating user method](#evaluating-user). The Evaluating user method must always be called because it generates analytics events that will be sent to the server. +Do not call this method without calling the [Evaluating user method](android#evaluating-user). The Evaluating user method must always be called because it generates analytics events that will be sent to the server. ::: diff --git a/docs/sdk/client-side/flutter/index.md b/docs/sdk/client-side/flutter/index.md index 6adc55c5..c55a7fd9 100644 --- a/docs/sdk/client-side/flutter/index.md +++ b/docs/sdk/client-side/flutter/index.md @@ -297,7 +297,7 @@ In regular use, you don't need to call the flush method because the events are s ### User attributes configuration -This feature will give you robust and granular control over what users can see on your application. You can add rules using these attributes on the console UI's feature flag's targeting tab. [See more](#). +This feature will give you robust and granular control over what users can see on your application. You can add rules using these attributes on the console UI's feature flag's targeting tab. [See more](/feature-flags/creating-feature-flags/targeting#user-attributes). @@ -353,7 +353,7 @@ This updating method will override the current data. ### Getting user information -This method will return the current user configured in the SDK. This is useful when you want to check the current user id and attributes before updating them through [updateUserAttributes](#getting-user-information). +This method will return the current user configured in the SDK. This is useful when you want to check the current user id and attributes before updating them through [updateUserAttributes](flutter#updating-user-attributes). diff --git a/docs/sdk/client-side/ios/index.md b/docs/sdk/client-side/ios/index.md index e558766d..92f0a5d2 100644 --- a/docs/sdk/client-side/ios/index.md +++ b/docs/sdk/client-side/ios/index.md @@ -364,7 +364,7 @@ In regular use, you don't need to call the flush method because the events are s ### User attributes configuration -This feature will give you robust and granular control over what users can see on your application. You can add rules using these attributes on the console UI's feature flag's targeting tab. [See more](#). +This feature will give you robust and granular control over what users can see on your application. You can add rules using these attributes on the console UI's feature flag's targeting tab. [See more](/feature-flags/creating-feature-flags/targeting#user-attributes). @@ -429,7 +429,7 @@ This updating method will override the current data. ### Getting user information -This method will return the current user configured in the SDK. This is useful when you want to check the current user id and attributes before updating them through [updateUserAttributes](#getting-user-information). +This method will return the current user configured in the SDK. This is useful when you want to check the current user id and attributes before updating them through [updateUserAttributes](ios#updating-user-attributes). @@ -455,7 +455,7 @@ let evaluationDetails = client.evaluationDetails(featureId: "YOUR_FEATURE_FLAG_I :::caution -Do not call this method without calling the [Evaluating user method](#evaluating-user). The Evaluating user method must always be called because it generates analytics events that will be sent to the server. +Do not call this method without calling the [Evaluating user method](ios#evaluating-user). The Evaluating user method must always be called because it generates analytics events that will be sent to the server. ::: diff --git a/docs/sdk/client-side/javascript/index.md b/docs/sdk/client-side/javascript/index.md index f684efa6..2173b886 100644 --- a/docs/sdk/client-side/javascript/index.md +++ b/docs/sdk/client-side/javascript/index.md @@ -262,7 +262,7 @@ In regular use, you don't need to call the flush method because the events are s ### User attributes configuration -This feature will give you robust and granular control over what users can see on your application. You can add rules using these attributes on the console UI's feature flag's targeting tab. [See more](#). +This feature will give you robust and granular control over what users can see on your application. You can add rules using these attributes on the console UI's feature flag's targeting tab. [See more](/feature-flags/creating-feature-flags/targeting#user-attributes). @@ -317,7 +317,7 @@ This updating method will override the current data. ### Getting user information -This method will return the current user configured in the SDK. This is useful when you want to check the current user id and attributes before updating them through [updateUserAttributes](#getting-user-information). +This method will return the current user configured in the SDK. This is useful when you want to check the current user id and attributes before updating them through [updateUserAttributes](javascript#updating-user-attributes). diff --git a/docusaurus.config.js b/docusaurus.config.js index dc506091..9c5dfa5a 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -33,6 +33,14 @@ const config = { i18n: { defaultLocale: 'en', locales: [ 'en', 'ja' ], + localeConfigs: { + en: { + label: 'English', + }, + ja: { + label: 'Japanese', + }, + }, }, presets: [ @@ -135,6 +143,11 @@ const config = { className: 'header-slack-link', 'aria-label': 'Bucketeer Slack - Join the conversation', }, + { + type: 'localeDropdown', + position: 'right', + className: 'language_dropdown' + }, ], }, prism: { diff --git a/i18n/en/code.json b/i18n/en/code.json new file mode 100644 index 00000000..940f0cb5 --- /dev/null +++ b/i18n/en/code.json @@ -0,0 +1,293 @@ +{ + "theme.ErrorPageContent.title": { + "message": "This page crashed.", + "description": "The title of the fallback page when the page crashed" + }, + "theme.NotFound.title": { + "message": "Page Not Found", + "description": "The title of the 404 page" + }, + "theme.NotFound.p1": { + "message": "We could not find what you were looking for.", + "description": "The first paragraph of the 404 page" + }, + "theme.NotFound.p2": { + "message": "Please contact the owner of the site that linked you to the original URL and let them know their link is broken.", + "description": "The 2nd paragraph of the 404 page" + }, + "theme.admonition.note": { + "message": "note", + "description": "The default label used for the Note admonition (:::note)" + }, + "theme.admonition.tip": { + "message": "tip", + "description": "The default label used for the Tip admonition (:::tip)" + }, + "theme.admonition.danger": { + "message": "danger", + "description": "The default label used for the Danger admonition (:::danger)" + }, + "theme.admonition.info": { + "message": "info", + "description": "The default label used for the Info admonition (:::info)" + }, + "theme.admonition.caution": { + "message": "caution", + "description": "The default label used for the Caution admonition (:::caution)" + }, + "theme.BackToTopButton.buttonAriaLabel": { + "message": "Scroll back to top", + "description": "The ARIA label for the back to top button" + }, + "theme.blog.archive.title": { + "message": "Archive", + "description": "The page & hero title of the blog archive page" + }, + "theme.blog.archive.description": { + "message": "Archive", + "description": "The page & hero description of the blog archive page" + }, + "theme.blog.paginator.navAriaLabel": { + "message": "Blog list page navigation", + "description": "The ARIA label for the blog pagination" + }, + "theme.blog.paginator.newerEntries": { + "message": "Newer Entries", + "description": "The label used to navigate to the newer blog posts page (previous page)" + }, + "theme.blog.paginator.olderEntries": { + "message": "Older Entries", + "description": "The label used to navigate to the older blog posts page (next page)" + }, + "theme.blog.post.paginator.navAriaLabel": { + "message": "Blog post page navigation", + "description": "The ARIA label for the blog posts pagination" + }, + "theme.blog.post.paginator.newerPost": { + "message": "Newer Post", + "description": "The blog post button label to navigate to the newer/previous post" + }, + "theme.blog.post.paginator.olderPost": { + "message": "Older Post", + "description": "The blog post button label to navigate to the older/next post" + }, + "theme.blog.post.plurals": { + "message": "One post|{count} posts", + "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.blog.tagTitle": { + "message": "{nPosts} tagged with \"{tagName}\"", + "description": "The title of the page for a blog tag" + }, + "theme.tags.tagsPageLink": { + "message": "View All Tags", + "description": "The label of the link targeting the tag list page" + }, + "theme.colorToggle.ariaLabel": { + "message": "Switch between dark and light mode (currently {mode})", + "description": "The ARIA label for the navbar color mode toggle" + }, + "theme.colorToggle.ariaLabel.mode.dark": { + "message": "dark mode", + "description": "The name for the dark color mode" + }, + "theme.colorToggle.ariaLabel.mode.light": { + "message": "light mode", + "description": "The name for the light color mode" + }, + "theme.docs.breadcrumbs.navAriaLabel": { + "message": "Breadcrumbs", + "description": "The ARIA label for the breadcrumbs" + }, + "theme.docs.DocCard.categoryDescription": { + "message": "{count} items", + "description": "The default description for a category card in the generated index about how many items this category includes" + }, + "theme.docs.paginator.navAriaLabel": { + "message": "Docs pages", + "description": "The ARIA label for the docs pagination" + }, + "theme.docs.paginator.previous": { + "message": "Previous", + "description": "The label used to navigate to the previous doc" + }, + "theme.docs.paginator.next": { + "message": "Next", + "description": "The label used to navigate to the next doc" + }, + "theme.docs.tagDocListPageTitle.nDocsTagged": { + "message": "One doc tagged|{count} docs tagged", + "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.docs.tagDocListPageTitle": { + "message": "{nDocsTagged} with \"{tagName}\"", + "description": "The title of the page for a docs tag" + }, + "theme.docs.versionBadge.label": { + "message": "Version: {versionLabel}" + }, + "theme.docs.versions.unreleasedVersionLabel": { + "message": "This is unreleased documentation for {siteTitle} {versionLabel} version.", + "description": "The label used to tell the user that he's browsing an unreleased doc version" + }, + "theme.docs.versions.unmaintainedVersionLabel": { + "message": "This is documentation for {siteTitle} {versionLabel}, which is no longer actively maintained.", + "description": "The label used to tell the user that he's browsing an unmaintained doc version" + }, + "theme.docs.versions.latestVersionSuggestionLabel": { + "message": "For up-to-date documentation, see the {latestVersionLink} ({versionLabel}).", + "description": "The label used to tell the user to check the latest version" + }, + "theme.docs.versions.latestVersionLinkLabel": { + "message": "latest version", + "description": "The label used for the latest version suggestion link label" + }, + "theme.common.editThisPage": { + "message": "Edit this page", + "description": "The link label to edit the current page" + }, + "theme.common.headingLinkTitle": { + "message": "Direct link to {heading}", + "description": "Title for link to heading" + }, + "theme.lastUpdated.atDate": { + "message": " on {date}", + "description": "The words used to describe on which date a page has been last updated" + }, + "theme.lastUpdated.byUser": { + "message": " by {user}", + "description": "The words used to describe by who the page has been last updated" + }, + "theme.lastUpdated.lastUpdatedAtBy": { + "message": "Last updated{atDate}{byUser}", + "description": "The sentence used to display when a page has been last updated, and by who" + }, + "theme.navbar.mobileVersionsDropdown.label": { + "message": "Versions", + "description": "The label for the navbar versions dropdown on mobile view" + }, + "theme.tags.tagsListLabel": { + "message": "Tags:", + "description": "The label alongside a tag list" + }, + "theme.AnnouncementBar.closeButtonAriaLabel": { + "message": "Close", + "description": "The ARIA label for close button of announcement bar" + }, + "theme.blog.sidebar.navAriaLabel": { + "message": "Blog recent posts navigation", + "description": "The ARIA label for recent posts in the blog sidebar" + }, + "theme.CodeBlock.copied": { + "message": "Copied", + "description": "The copied button label on code blocks" + }, + "theme.CodeBlock.copyButtonAriaLabel": { + "message": "Copy code to clipboard", + "description": "The ARIA label for copy code blocks button" + }, + "theme.CodeBlock.copy": { + "message": "Copy", + "description": "The copy button label on code blocks" + }, + "theme.CodeBlock.wordWrapToggle": { + "message": "Toggle word wrap", + "description": "The title attribute for toggle word wrapping button of code block lines" + }, + "theme.DocSidebarItem.toggleCollapsedCategoryAriaLabel": { + "message": "Toggle the collapsible sidebar category '{label}'", + "description": "The ARIA label to toggle the collapsible sidebar category" + }, + "theme.NavBar.navAriaLabel": { + "message": "Main", + "description": "The ARIA label for the main navigation" + }, + "theme.navbar.mobileLanguageDropdown.label": { + "message": "Languages", + "description": "The label for the mobile language switcher dropdown" + }, + "theme.TOCCollapsible.toggleButtonLabel": { + "message": "On this page", + "description": "The label used by the button on the collapsible TOC component" + }, + "theme.blog.post.readMore": { + "message": "Read More", + "description": "The label used in blog post item excerpts to link to full blog posts" + }, + "theme.blog.post.readMoreLabel": { + "message": "Read more about {title}", + "description": "The ARIA label for the link to full blog posts from excerpts" + }, + "theme.blog.post.readingTime.plurals": { + "message": "One min read|{readingTime} min read", + "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.docs.breadcrumbs.home": { + "message": "Home page", + "description": "The ARIA label for the home page in the breadcrumbs" + }, + "theme.docs.sidebar.collapseButtonTitle": { + "message": "Collapse sidebar", + "description": "The title attribute for collapse button of doc sidebar" + }, + "theme.docs.sidebar.collapseButtonAriaLabel": { + "message": "Collapse sidebar", + "description": "The title attribute for collapse button of doc sidebar" + }, + "theme.docs.sidebar.navAriaLabel": { + "message": "Docs sidebar", + "description": "The ARIA label for the sidebar navigation" + }, + "theme.docs.sidebar.closeSidebarButtonAriaLabel": { + "message": "Close navigation bar", + "description": "The ARIA label for close button of mobile sidebar" + }, + "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { + "message": "← Back to main menu", + "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" + }, + "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { + "message": "Toggle navigation bar", + "description": "The ARIA label for hamburger menu button of mobile navigation" + }, + "theme.docs.sidebar.expandButtonTitle": { + "message": "Expand sidebar", + "description": "The ARIA label and title attribute for expand button of doc sidebar" + }, + "theme.docs.sidebar.expandButtonAriaLabel": { + "message": "Expand sidebar", + "description": "The ARIA label and title attribute for expand button of doc sidebar" + }, + "cmfcmf/d-s-l.searchBar.placeholder": { + "message": "Search...", + "description": "Placeholder shown in the searchbar" + }, + "cmfcmf/d-s-l.searchBar.clearButtonTitle": { + "message": "Clear", + "description": "Title of the button to clear the current search input" + }, + "cmfcmf/d-s-l.searchBar.detachedCancelButtonText": { + "message": "Cancel", + "description": "Text of the button to close the detached search window" + }, + "cmfcmf/d-s-l.searchBar.submitButtonTitle": { + "message": "Submit", + "description": "Title of the button to submit a new search" + }, + "cmfcmf/d-s-l.searchBar.noResults": { + "message": "No results found.", + "description": "message shown if no results are found" + }, + "theme.ErrorPageContent.tryAgain": { + "message": "Try again", + "description": "The label of the button to try again rendering when the React error boundary captures an error" + }, + "theme.common.skipToMainContent": { + "message": "Skip to main content", + "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" + }, + "theme.tags.tagsPageTitle": { + "message": "Tags", + "description": "The title of the tag list page" + } +} diff --git a/i18n/en/docusaurus-plugin-content-docs/current.json b/i18n/en/docusaurus-plugin-content-docs/current.json new file mode 100644 index 00000000..fd3725be --- /dev/null +++ b/i18n/en/docusaurus-plugin-content-docs/current.json @@ -0,0 +1,74 @@ +{ + "version.label": { + "message": "Next", + "description": "The label for version current" + }, + "sidebar.docs.category.Quickstart": { + "message": "Quickstart", + "description": "The label for category Quickstart in sidebar docs" + }, + "sidebar.docs.category.Creating Feature Flags": { + "message": "Creating Feature Flags", + "description": "The label for category Creating Feature Flags in sidebar docs" + }, + "sidebar.docs.category.Testing With Flags": { + "message": "Testing With Flags", + "description": "The label for category Testing With Flags in sidebar docs" + }, + "sidebar.docs.category.Client": { + "message": "Client", + "description": "The label for category Client in sidebar docs" + }, + "sidebar.docs.category.Server": { + "message": "Server", + "description": "The label for category Server in sidebar docs" + }, + "sidebar.docs.category.Documentation Style": { + "message": "Documentation Style", + "description": "The label for category Documentation Style in sidebar docs" + }, + "sidebar.docs.doc.Bucketeer Docs": { + "message": "Bucketeer Docs", + "description": "The label for the doc item Bucketeer Docs in sidebar docs, linking to the doc bucketeer-docs" + }, + "sidebar.docs.doc.Introduction": { + "message": "Introduction", + "description": "The label for the doc item Introduction in sidebar docs, linking to the doc getting-started/introduction" + }, + "sidebar.docs.doc.Create an account": { + "message": "Create an account", + "description": "The label for the doc item Create an account in sidebar docs, linking to the doc getting-started/create-an-account" + }, + "sidebar.docs.doc.Bucketeer Vocabulary": { + "message": "Bucketeer Vocabulary", + "description": "The label for the doc item Bucketeer Vocabulary in sidebar docs, linking to the doc getting-started/bucketeer-vocabulary" + }, + "sidebar.docs.doc.Overview": { + "message": "Overview", + "description": "The label for the doc item Overview in sidebar docs, linking to the doc integration/index" + }, + "sidebar.docs.doc.API Keys": { + "message": "API Keys", + "description": "The label for the doc item API Keys in sidebar docs, linking to the doc configuration/api-keys" + }, + "sidebar.docs.doc.Account Types": { + "message": "Account Types", + "description": "The label for the doc item Account Types in sidebar docs, linking to the doc configuration/account-types" + }, + "sidebar.docs.doc.Pushes": { + "message": "Pushes", + "description": "The label for the doc item Pushes in sidebar docs, linking to the doc integration/pushes" + }, + "sidebar.docs.doc.Notifications": { + "message": "Notifications", + "description": "The label for the doc item Notifications in sidebar docs, linking to the doc integration/notifications" + }, + "sidebar.docs.doc.Optimize with tags": { + "message": "Optimize with tags", + "description": "The label for the doc item Optimize with tags in sidebar docs, linking to the doc best-practices/optimize-bucketeer-with-tags" + }, + "sidebar.docs.doc.Contributing": { + "message": "Contributing", + "description": "The label for the doc item Contributing in sidebar docs, linking to the doc contribution-guide/contributing" + } +} diff --git a/i18n/en/docusaurus-theme-classic/navbar.json b/i18n/en/docusaurus-theme-classic/navbar.json new file mode 100644 index 00000000..18c69641 --- /dev/null +++ b/i18n/en/docusaurus-theme-classic/navbar.json @@ -0,0 +1,22 @@ +{ + "logo.alt": { + "message": "Feature Flag and A/B Testing Managment platform", + "description": "The alt text of navbar logo" + }, + "item.label.Home": { + "message": "Home", + "description": "Navbar item with label Home" + }, + "item.label.Getting Started": { + "message": "Getting Started", + "description": "Navbar item with label Getting Started" + }, + "item.label.SDKs": { + "message": "SDKs", + "description": "Navbar item with label SDKs" + }, + "item.label.Contributing": { + "message": "Contributing", + "description": "Navbar item with label Contributing" + } +} diff --git a/i18n/ja/code.json b/i18n/ja/code.json index b64b56c0..7b616edc 100644 --- a/i18n/ja/code.json +++ b/i18n/ja/code.json @@ -1,11 +1,11 @@ { "theme.ErrorPageContent.title": { - "message": "This page crashed.", + "message": "このページはクラッシュしました。", "description": "The title of the fallback page when the page crashed" }, "theme.ErrorPageContent.tryAgain": { - "message": "Try again", - "description": "The label of the button to try again when the page crashed" + "message": "もう一度試してください", + "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.NotFound.title": { "message": "ページが見つかりません", @@ -24,15 +24,15 @@ "description": "The ARIA label for close button of announcement bar" }, "theme.blog.archive.title": { - "message": "Archive", + "message": "アーカイブ", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { - "message": "Archive", + "message": "アーカイブ", "description": "The page & hero description of the blog archive page" }, "theme.BackToTopButton.buttonAriaLabel": { - "message": "Scroll back to top", + "message": "ページ上部へ戻る", "description": "The ARIA label for the back to top button" }, "theme.blog.paginator.navAriaLabel": { @@ -229,5 +229,65 @@ "theme.docs.sidebar.expandButtonAriaLabel": { "message": "サイドバーを開く", "description": "The ARIA label and title attribute for expand button of doc sidebar" + }, + "theme.admonition.note": { + "message": "注記", + "description": "The default label used for the Note admonition (:::note)" + }, + "theme.admonition.tip": { + "message": "ヒント", + "description": "The default label used for the Tip admonition (:::tip)" + }, + "theme.admonition.danger": { + "message": "危険", + "description": "The default label used for the Danger admonition (:::danger)" + }, + "theme.admonition.info": { + "message": "備考", + "description": "The default label used for the Info admonition (:::info)" + }, + "theme.admonition.caution": { + "message": "注意", + "description": "The default label used for the Caution admonition (:::caution)" + }, + "theme.NavBar.navAriaLabel": { + "message": "Main", + "description": "The ARIA label for the main navigation" + }, + "theme.docs.sidebar.navAriaLabel": { + "message": "Docs sidebar", + "description": "The ARIA label for the sidebar navigation" + }, + "theme.docs.sidebar.closeSidebarButtonAriaLabel": { + "message": "Close navigation bar", + "description": "The ARIA label for close button of mobile sidebar" + }, + "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { + "message": "Toggle navigation bar", + "description": "The ARIA label for hamburger menu button of mobile navigation" + }, + "cmfcmf/d-s-l.searchBar.placeholder": { + "message": "検索...", + "description": "Placeholder shown in the searchbar" + }, + "cmfcmf/d-s-l.searchBar.clearButtonTitle": { + "message": "Clear", + "description": "Title of the button to clear the current search input" + }, + "cmfcmf/d-s-l.searchBar.detachedCancelButtonText": { + "message": "Cancel", + "description": "Text of the button to close the detached search window" + }, + "cmfcmf/d-s-l.searchBar.submitButtonTitle": { + "message": "Submit", + "description": "Title of the button to submit a new search" + }, + "cmfcmf/d-s-l.searchBar.noResults": { + "message": "該当する結果はありません。", + "description": "message shown if no results are found" + }, + "theme.tags.tagsPageTitle": { + "message": "タグ", + "description": "The title of the tag list page" } } diff --git a/i18n/ja/docusaurus-plugin-content-docs/current.json b/i18n/ja/docusaurus-plugin-content-docs/current.json new file mode 100644 index 00000000..2799d6a8 --- /dev/null +++ b/i18n/ja/docusaurus-plugin-content-docs/current.json @@ -0,0 +1,74 @@ +{ + "version.label": { + "message": "Next", + "description": "The label for version current" + }, + "sidebar.docs.category.Quickstart": { + "message": "クイックスタート", + "description": "The label for category Quickstart in sidebar docs" + }, + "sidebar.docs.category.Creating Feature Flags": { + "message": "フィーチャーフラグの作成", + "description": "The label for category Creating Feature Flags in sidebar docs" + }, + "sidebar.docs.category.Testing With Flags": { + "message": "フラグを使用したテスト", + "description": "The label for category Testing With Flags in sidebar docs" + }, + "sidebar.docs.category.Client": { + "message": "クライアント", + "description": "The label for category Client in sidebar docs" + }, + "sidebar.docs.category.Server": { + "message": "サーバー", + "description": "The label for category Server in sidebar docs" + }, + "sidebar.docs.category.Documentation Style": { + "message": "Documentation Style", + "description": "The label for category Documentation Style in sidebar docs" + }, + "sidebar.docs.doc.Bucketeer Docs": { + "message": "Bucketeer ドキュメント", + "description": "The label for the doc item Bucketeer Docs in sidebar docs, linking to the doc bucketeer-docs" + }, + "sidebar.docs.doc.Introduction": { + "message": "概要", + "description": "The label for the doc item Introduction in sidebar docs, linking to the doc getting-started/introduction" + }, + "sidebar.docs.doc.Create an account": { + "message": "アカウントの作成", + "description": "The label for the doc item Create an account in sidebar docs, linking to the doc getting-started/create-an-account" + }, + "sidebar.docs.doc.Bucketeer Vocabulary": { + "message": "Bucketeer用語", + "description": "The label for the doc item Bucketeer Vocabulary in sidebar docs, linking to the doc getting-started/bucketeer-vocabulary" + }, + "sidebar.docs.doc.Overview": { + "message": "概要", + "description": "The label for the doc item Overview in sidebar docs, linking to the doc integration/index" + }, + "sidebar.docs.doc.API Keys": { + "message": "API キー", + "description": "The label for the doc item API Keys in sidebar docs, linking to the doc feature-flags/api-keys" + }, + "sidebar.docs.doc.Pushes": { + "message": "プッシュ", + "description": "The label for the doc item Pushes in sidebar docs, linking to the doc integration/pushes" + }, + "sidebar.docs.doc.Notifications": { + "message": "通知", + "description": "The label for the doc item Notifications in sidebar docs, linking to the doc integration/notifications" + }, + "sidebar.docs.doc.Optimize with tags": { + "message": "タグを使用して最適化する", + "description": "The label for the doc item Optimize with tags in sidebar docs, linking to the doc best-practices/optimize-bucketeer-with-tags" + }, + "sidebar.docs.doc.Contributing": { + "message": "貢献", + "description": "The label for the doc item Contributing in sidebar docs, linking to the doc contribution-guide/contributing" + }, + "sidebar.docs.category.Auto operation": { + "message": "自動オペレーション", + "description": "The label for category Auto operation in sidebar docs" + } +} diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/best-practices/optimize-bucketeer-with-tags.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/best-practices/optimize-bucketeer-with-tags.mdx new file mode 100644 index 00000000..e81ea6ea --- /dev/null +++ b/i18n/ja/docusaurus-plugin-content-docs/current/best-practices/optimize-bucketeer-with-tags.mdx @@ -0,0 +1,96 @@ +--- +title: タグによるBucketeerの最適化 +# sidebar_position: +slug: /best-practices/optimize-with-tags +description: Describe the impact of using tags with feature flags and the best practices to define them. +tags: ['best-practices', 'tags'] +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +Bucketeerのインテグレーションと活用は簡単で、設定と利用を完全にコントロールすることができます。ただし、一歩間違えればサーバーの応答時間やコストに大きな影響を与え、最終的にユーザーエクスペリエンスに影響を与えます。そこで、[フィーチャーフラグの使用](/feature-flags)で詳しく説明するこのトピックについて、簡単に説明します。 + +[インテグレーションプロセス](/getting-started/quickstart/integrate-bucketeer)のステップ 3 では、`featureTag`を指定する必要があります。簡単に理解できるように、コードを以下に示します: + + + + + +```kotlin showLineNumbers +// Configure the SDK +val config = BKTConfig.builder() + .apiKey("YOUR_API_KEY") + .apiEndpoint("YOUR_API_ENDPOINT") + .featureTag("YOUR_FEATURE_TAG") + .build() +``` + + + + +```dart showLineNumbers +// Configure the SDK +final config = BKTConfigBuilder() + .apiKey("YOUR_API_KEY") + .apiURL("YOUR_API_URL") + .featureTag("YOUR_FEATURE_TAG") + .build(); +``` + + + + +```swift showLineNumbers +// Configure the SDK +let config = BKTConfig( + apiKey: "YOUR_API_KEY", + apiURL: "YOUR_API_URL", + featureTag: "YOUR_FEATURE_TAG" +) +``` + + + + +```js showLineNumbers +// Configure the SDK +const config = defineBKTConfig({ + apiKey: 'YOUR_API_KEY', + apiEndpoint: 'YOUR_API_URL', + featureTag: 'YOUR_FEATURE_TAG', + appVersion: 'YOUR_APP_VERSION', +}); +``` + + + + +```sh showLineNumbers +not available +``` + + + + +```sh showLineNumbers +not available +``` + + + + +`featureTag`は、フィーチャーフラグを作成する際に定義され、2つの目的があります。第1に、Bucketeerダッシュボードのタグリスト内で検索するのに役立ちます。第2に、`featureTag`はBucketeerシステムの使用を最適化する上で重要な役割を果たします。 + +フィーチャータグは、ユーザーを評価するためにサーバー呼び出しを行う際のリミッターとして機能します。したがって、呼び出しがタグを使用しない場合や、多数のフラグで使用されるタグを使用する場合、エバリュエーションのために大量のフィーチャーフラグが返されます。フラグが少ない小規模なシステムでは、これは問題にならないかもしれません。しかし、システムが拡張するにつれて、エバリュエーション呼び出しを識別および最適化するためにタグを使用しないと、サーバー上で過剰な処理が行われ、運用コストが増加する可能性があります。さらに、応答時間が長くなり、ユーザーエクスペリエンスに悪影響を与える可能性があります。したがって、ターゲットを絞った断定的なタグを使用することで、以下のことが可能になります: + +- 必要な側面だけを分析することにより、エバリュエーションプロセスを加速します。 +- サーバとローカルアプリケーション間の情報トラフィックを削減します。 + +Bucketeerでのタグの使用は、パフォーマンスやコストに多大な影響を与える重要なものですが、その使用は任意です。 + +:::tip + +Bucketeerチームは、オペレーションを最適化するために`featureTag`の使用を強く推奨します。 + +::: diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/bucketeer-docs.md b/i18n/ja/docusaurus-plugin-content-docs/current/bucketeer-docs.md new file mode 100644 index 00000000..202680fa --- /dev/null +++ b/i18n/ja/docusaurus-plugin-content-docs/current/bucketeer-docs.md @@ -0,0 +1,119 @@ +--- +title: Bucketeer Docs +sidebar_position: 1 +slug: / +description: Describes what the Bucketeer is and its solution. In addition, the page also provides an overview of the main sections covered in the documentation. +tags: ['home', 'guide', 'presentation', 'overview', 'contact'] +--- + +import Button from '@site/src/components/button/Button'; +import ButtonShelf from '@site/src/components/button-shelf/ButtonShelf'; + +# Bucketeerドキュメントへようこそ + +Bucketeerドキュメントへようこそ。ここは、Bucketeerプラットフォーム、インテグレーション、SDKに関するあらゆる情報を得ることができるサイトです。Bucketeerソリューションを効果的に活用するために必要なすべての情報がここにあります。以下の便利なナビゲーションボタンを使用することで、目的のセクションにすばやくアクセスすることができます。さらにこのページでは、Bucketeerの主な特徴や機能を詳しくご紹介します。 + + +