Skip to content

Community translation - v3.0 (SDK & Browser plugin) #3780

Description

@ZuzanaOdstrcilova

1. Problem

Community translation delivers best value if contributing is easy. The most natural place to translate is in the running app, in context, where the contributor sees the string in its real place. Bringing community suggestions to in-context lowers the barrier, brings more contributors and better quality.

Today in-context translating does not support all functionality, including community suggestions. v1.0 and v2.0 give us the suggestion and voting backend, so this issue builds the in-context experience on top of it.


2. Appetite

2 weeks, 1 developer.


3. Solution

Reuse the backend from the previous community translation pitches (v1.0, v2.0) and the suggestion feature.
The frontend will be applied to the plugin UI; there will be small UX / UI changes, but the functionality will be similar.
This brings the existing platform suggestions feature 1:1 into the in-context dialog (SDK, plugin). It applies to anyone with suggest permission, not only community contributors.

Shared core: the in-context Suggest dialog

  • A suggestion component inside the in-context dialog
  • Voting on each suggestion
  • Accept / decline / delete etc. according to specific permission of the user
  • A "Suggest" button - if the user has suggestion permission

Note: The dialog must reflect each user's effective permission. A community suggest-only user must never be able to edit, even though a user can be both a member and have a suggest role (current logic of Suggestion: Advanced settings / Suggestions mode + Translation protection).

Auth: a suggest-scoped API key

  • Community contributors and the API key - need discussion on how to design this.
  • Proposal - first version: We will still use the API keys, but API scopes will be restricted. The same scope for community translation - while creating an API key, hide "scope settings" - just show the scopes the user will get.

4. Basic Drawings

Will be specified later (in-context dialog, API key settings...)


5. Rabbit Holes

  • Project goes from public to private. What happens to community contributors and their pending suggestions when a project is unpublished. 
  • There is no in-context commenting. A community translator cannot comment on a key in-context to flag a bad existing translation. Missing for that case. We will not solve it in this pitch, but needs to be addressed later.

6. No-Goes

  • Anonymous / public suggesting without authentication - later.
  • Anything beyond mirroring the platform dialog - this cycle only ports the existing functionality, with small UX / UI changes. No new in-context features.

7. Success Criteria

Functional

  • With a suggest-scoped key, a user can, on a production app using Tolgee, select a string in context (via the plugin or the SDK), see existing suggestions, and submit their own, which appears in the platform.
  • The user can delete their own suggestion and vote on suggestions (from v2.0). They cannot edit the live translation.

Metadata

Metadata

Assignees

Labels

pitchThe pitch according to the Shape-up approach

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions