diff --git a/sidebarTolgeeCli.js b/sidebarTolgeeCli.js index f2844bc08..647570586 100644 --- a/sidebarTolgeeCli.js +++ b/sidebarTolgeeCli.js @@ -18,5 +18,6 @@ module.exports = { ], }, 'migration-to-v2', + 'faq', ], }; diff --git a/tolgee-cli/extraction/syncing-strings.mdx b/tolgee-cli/extraction/syncing-strings.mdx index bbf0e4795..2e4bda874 100644 --- a/tolgee-cli/extraction/syncing-strings.mdx +++ b/tolgee-cli/extraction/syncing-strings.mdx @@ -35,6 +35,31 @@ When running this command on CI, the CLI automatically adds review annotation wa See an example [here](https://github.com/tolgee/tolgee-platform/commit/ddfff41#diff-84dc9ca52993f2d66eda975f622361460f83d659ce6ddf1a0c086e6ca8c328ccR46). ::: +### Duplicate key detection limitations + +Currently, the CLI does **not** detect when the same key appears multiple times in your code with different default values. For example, if you have: + +```jsx + + +``` + +The CLI will not warn you about this conflict. This is a known limitation that may be addressed in future versions. + +**Workaround**: Use consistent default values across your codebase, or rely on the Tolgee Platform as the single source of truth for translations rather than default values in code. + +### Default values and base language behavior + +When you first sync a key with a default value, the CLI will create the key in your Tolgee project and set the default value as the translation for your base language. However, **subsequent changes to default values in your code will not automatically update the base language translation** in Tolgee. + +For example: +1. You add `` and run `tolgee sync` +2. Tolgee creates the key "welcome" with "Welcome" as the English (base language) translation +3. Later, you change the code to `` +4. Running `tolgee sync` again will **not** update the English translation to "Welcome Back" + +This is by design to prevent conflicts between code changes and translations managed in the Tolgee Platform. + ## Comparing projects You can think of this utility as a dry-run of `tolgee sync`. You can use it to see the added/removed strings and diff --git a/tolgee-cli/faq.mdx b/tolgee-cli/faq.mdx new file mode 100644 index 000000000..32990f01f --- /dev/null +++ b/tolgee-cli/faq.mdx @@ -0,0 +1,112 @@ +--- +id: faq +title: Frequently Asked Questions +--- + +This page addresses common questions and misconceptions about the Tolgee CLI. + +## Key Management and Default Values + +### Q: Does the CLI detect duplicate keys with different default values? + +**A: No, currently the CLI does not detect this scenario.** + +If you have the same key with different default values in your code: + +```jsx + + +``` + +The CLI will not warn you about this conflict. This is a known limitation that may be addressed in future versions. + +**Workaround**: Use consistent default values across your codebase, or rely on the Tolgee Platform as the single source of truth for translations rather than default values in code. + +### Q: Why don't default values automatically update my base language translations? + +**A: This is by design to prevent conflicts between code and platform translations.** + +When you first sync a key, the default value becomes the base language translation. However, subsequent changes to default values in code will not update the platform translation. This prevents situations where: + +- A developer changes a default value in code +- A translator or PM has already refined the wording in the platform +- The two sources of truth conflict with each other + +### Q: How can I search for strings in my code if I only use keys and not default values? + +**A: This depends on your approach to translation management.** + +If you follow Tolgee's recommended approach of using the platform as the single source of truth: +- **Best approach**: Use in-context editing (available only for native JS SDKs with DevTools plugin) to click directly on the string in your app, then search for the key +- **Alternative**: Search for keys in your code: `grep -r "save-btn" src/`, then look up the actual translation in the Tolgee Platform + +If you maintain fallback translations in your code: +- You can search for both keys and translation strings +- But you'll need to manage consistency between code and platform + +## Best Practices and Workflow + +### Q: Should I keep default values in my code? + +**A: Tolgee recommends against using default values as the source of truth.** + +Here's why: +- **Single source of truth**: Having translations in both code and platform creates confusion +- **Team collaboration**: PMs, UX designers, and translators can update wording directly in the platform +- **Consistency**: Prevents conflicts between developer changes and translator/PM changes + +**Recommended approach**: Use keys without default values, and rely on the Tolgee Platform for all translation content. + +### Q: How should I handle translations in production? + +**A: NEVER use API keys in production. You have two recommended options:** + +**Option 1: Export translations as static assets** +1. Use `tolgee pull` to download translations to local files during your build process +2. Bundle these files with your application +3. Keep these files in version control +4. Update them regularly via `tolgee pull` in your CI/CD pipeline + +**Option 2: Use Tolgee Content Delivery** +- Configure your app to load translations from Tolgee's Content Delivery using the `BackendFetch` plugin +- No API keys required in production +- Automatic updates when translations change (up to 15 minutes for global CDN propagation) + +Both approaches give you: +- No API key exposure in production +- Reliable performance without direct platform dependency +- Platform as single source of truth during development + +### Q: How do I handle the workflow where I want to update translations from code? + +**A: Update translations directly in the Tolgee Platform, not in code.** + +Instead of changing default values in code: +1. Update the translation in the Tolgee Platform UI +2. Use the platform's features like translation memory, suggestions, and collaboration +3. Pull the updated translations to your local files if needed + +This workflow: +- Keeps the platform as the authoritative source +- Allows non-developers to manage translations +- Prevents conflicts and inconsistencies + +## Technical Limitations + +### Q: Should I avoid having multiple keys with the same translation text? + +**A: No, Tolgee actually recommends against de-duplication of translation strings.** + +While some developers worry about translating the same phrase multiple times (e.g., having both `save-btn` and `submit-btn` keys with the text "Save"), this is actually beneficial because: + +- **Context matters**: The same text can have different meanings in different contexts +- **Future flexibility**: You may want to change the wording in one place but not another +- **Semantic clarity**: Keys should represent their purpose, not just their current text + +For example, `save-document` and `save-settings` might both currently say "Save", but you may later want to change one to "Save Document" while keeping the other as "Save". + +### Q: Can I force the CLI to update base language translations from default values? + +**A: No, this is not supported and goes against Tolgee's recommended workflow.** + +The CLI is designed to treat the platform as the authoritative source for translations. If you need to update base language translations, do so directly in the Tolgee Platform. diff --git a/tolgee-cli/introduction.mdx b/tolgee-cli/introduction.mdx index a457c20df..e3d6a8564 100644 --- a/tolgee-cli/introduction.mdx +++ b/tolgee-cli/introduction.mdx @@ -13,6 +13,25 @@ You can find the **source code** of the CLI on [GitHub](https://github.com/tolge +## Best Practices + +### Single Source of Truth + +Tolgee recommends using the **Tolgee Platform as the single source of truth** for all translations, rather than maintaining default values in your code. This approach: + +- **Prevents conflicts** between code changes and translator/PM updates +- **Enables collaboration** - non-developers can manage translations directly +- **Maintains consistency** across your entire localization workflow + +### Recommended Workflow + +1. **Extract keys without default values** from your code using the CLI +2. **Manage all translation content** in the Tolgee Platform +3. **Use `tolgee pull`** to download translations as local fallback files +4. **Keep fallback files in version control** for offline functionality + +This workflow decouples translation content from code, allowing your team to iterate on wording without requiring code changes. + ## Features ### Easy project configuration