1. Problem
Tolgee is already used by many open-source projects, but it has no safe way to translate with a community. To involve outsiders today, you must add them to your project. Then they are members you have to manage, they count as paid seats, and you have to set their permissions. And even limited translate rights let them modify all strings in a language. Owners want something simpler: hand the community a link and let them contribute, without administering them, counting them as users, or dealing with permissions. We already have suggestions, which partly cover this, but they are only an intermediate step toward full community translation.
This is one of our top priorities this quarter, with strong user demand. In the age of AI translation, where quality varies, it makes even more sense to let the community and native speakers propose and review translations.
We need a better way: community members can only propose suggestions, while someone with permission approves and merges. They work through a limited view, without exposing the project or paying per volunteer.
2. Appetite
2 weeks, 1 developer.
This is tight for the full scope, so the public projects page ships as a simple v1 (list + basic search).
3. Solution
Allow the project to be public
- Project settings: a "Public project" checkbox.
- Project view: a "Public project" / "Private project" icon.
- A public list of projects at "tolgee.io/public-projects".
- Simple list of Projects with basic search.
- Opening a project or contributing requires login / registration; only the list itself is public.
- Each project in the public view shows its icon, name, organization, and description (possibly some small stats).
- Categories and advanced filters come later.
Permissions
- Enable Tolgee users to propose translations of strings in public projects
- Enable project owners or people with specific permission to review the proposal and accept it
"Community permission"
- A new community permission, granted by a public project page link, not by adding the person as a project member or paid seat.
- Community members can only view translations and project stats, and propose suggestions.
- They cannot edit or overwrite strings, change state, or access anything else in the project.
Note: Community can comment on a translation. So if the current translation (e.g. done by AI) is not good, they can comment on it there.
Suggestions
- Community translators see a view with all suggestions and can suggest their own translation.
Suggestion
- A contributor only sees a Suggest button. They cannot change the live translation.
- The translation view shows 3 suggestions by default, with a "more" button.
- The accept / decline and hide logic will change:
- After accepting one suggestion, the others do not disappear.
- A new "accept and hide" action hides them when the user really wants to, but for community purposes all suggestions should stay visible.
- After suggesting, a contributor can still delete their own suggestion (already exists).
- A user from the organization with the right permission can accept or decline a suggestion. Accepting promotes it to the live translation (already exists).
Billing
- A community contributor is a separate identity, not a regular project member. They are not counted as a paid seat.
4. Basic Drawings
5. Rabbit Holes
- Billing. Community contributors must never count as paid seats. Be aware of future change of billing (per string). For now we ignore it.
- How the system knows a user is a contributor. The architecture can be a rabbit hole. For now: a user is a contributor if they suggest (or vote, in the future).
- What the public view exposes. Solution: define exactly what a public project shows (translations, dashboard, export, and AI - the community can only read AI settings).
- Un-publishing a project. Solution: the view stays the same for the private project; the community simply loses permission to access it.
- Branching. Solution: the community works on non-protected branches only.
6. No-Goes
- Project categories on the public page, and special rich UI for the first version.
- Adding new languages by the community (can be problematic, owner-only for now).
- Community changing translation state (translated / reviewed).
- Voting (next ShapeUp cycle).
- The in-context SDK (next ShapeUp cycle).
7. Success Criteria
Functional
- An open-source project can accept community translations end-to-end: owner marks project public → contributor finds it on the public page → registers → proposes → owner reviews and accepts.
- Community contributors do not appear as paid seats.
- Contributors can never overwrite existing strings.
Growth & reach
- More users: signups coming through public-project links and new contributor registrations.
- More activity: number of community suggestions, and the share of suggestions owners accept.
- More backlinks / reach: public project pages drive backlinks and SEO to Tolgee.
1. Problem
Tolgee is already used by many open-source projects, but it has no safe way to translate with a community. To involve outsiders today, you must add them to your project. Then they are members you have to manage, they count as paid seats, and you have to set their permissions. And even limited translate rights let them modify all strings in a language. Owners want something simpler: hand the community a link and let them contribute, without administering them, counting them as users, or dealing with permissions. We already have suggestions, which partly cover this, but they are only an intermediate step toward full community translation.
This is one of our top priorities this quarter, with strong user demand. In the age of AI translation, where quality varies, it makes even more sense to let the community and native speakers propose and review translations.
We need a better way: community members can only propose suggestions, while someone with permission approves and merges. They work through a limited view, without exposing the project or paying per volunteer.
2. Appetite
2 weeks, 1 developer.
This is tight for the full scope, so the public projects page ships as a simple v1 (list + basic search).
3. Solution
Allow the project to be public
Permissions
"Community permission"
Suggestions
Suggestion
Billing
4. Basic Drawings
5. Rabbit Holes
6. No-Goes
7. Success Criteria
Functional
Growth & reach