Tolgee Platform Documentation

repository·main·Indexed 26 days ago

https://github.com/tolgee/tolgee-platform

An open-source localization platform for developers featuring embedded translation via SDKs, in-context editing, and automated machine translation workflows. The platform includes a Model Context Protocol (MCP) server for AI coding assistants, a UI library with Storybook documentation, and comprehensive observability using OpenTelemetry, Grafana, and Prometheus.

Tokens
31.1K
Snippets
97
Records
186
Agent score
88%

What's inside Tolgee

  1. Understand the Alerting Flow

    main

    Alerting in the local observability stack follows a continuous pipeline to transform trace data into proactive notifications:

    1. Spans arrive at Tempo: Application trace data is ingested.
    2. Metrics Generator computes RED metrics: Calculates Rate, Errors, and Duration.
    3. Metrics written to Prometheus: Metrics are stored as time series.
    4. Grafana evaluates alert rules: Periodically checks conditions against Prometheus data.
    5. Alertmanager sends notifications: Triggers alerts when conditions are met.

    Available Metrics for Alerting: These metrics are automatically generated from traces and can be queried via the Prometheus datasource in Grafana:

    MetricTypeUse Case
    traces_spanmetrics_latency_buckethistogramPercentile latency alerts (p95, p99)
    traces_spanmetrics_calls_totalcounterRequest rate, error rate alerts
    traces_spanmetrics_size_totalcounterThroughput alerts
  2. Observability Capabilities in Tolgee

    main

    Tolgee implements observability through three core capabilities:

    1. Distributed Tracing: Uses the OpenTelemetry Java Agent to follow requests across service boundaries (Spring MVC, JDBC, Redis, HTTP clients).
    2. Log Correlation: The OTEL agent injects trace_id and span_id into the SLF4J MDC, allowing Logback to include them in log outputs. This enables jumping from a trace to its logs.
    3. Metrics: RED metrics (Request rates, Error rates, Latency percentiles) are generated from traces by the backend (e.g., Tempo's metrics_generator) and stored in Prometheus.
  3. Understand the Translation View Query Refactor

    main

    The Translation View query, which powers the following endpoints, has been refactored for performance:

    • GET /v2/projects/{projectId}/translations
    • GET /v2/projects/{projectId}/keys/trash

    Key architectural changes:

    • Two-query pattern: Instead of one massive SQL query with numerous LEFT JOINs, the system now uses a slim main query that returns only key-level columns, followed by a separate batched query to fetch translation rows. This ensures the main query's complexity remains constant regardless of the number of languages selected.
    • Filter implementation: Translation-level filters are now expressed as EXISTS subqueries rather than joins. This prevents row multiplication and eliminates the need for expensive GROUP BY operations.
    • Batched counts: Comment, suggestion, and QA issue counts are now fetched via batched queries instead of being inlined as correlated subqueries in the main SELECT list.
    • Optimization for many languages: Multi-language filters (like filterOutdatedLanguage applied to multiple languages) are collapsed into a single language_id IN (...) subquery to reduce overhead.
  4. Understand Translation View Query Filtering Logic

    main

    Tolgee uses two primary filter classes to manage query conditions in the translation view:

    1. QueryGlobalFiltering: Applies to keys as a whole. This includes filters for key id/name, namespace, search, screenshots, branch, tags, and tasks.
    2. QueryTranslationFiltering: Applies to translations within specific languages. This includes filters for state, has-comments, has-suggestions, label, auto-translated, and outdated status.

    Important Semantics:

    • Translation-level filters are OR-ed together during query construction in TranslationsViewQueryBuilder.getWhereConditions. For example, combining filterState=en,TRANSLATED with filterHasUnresolvedCommentsInLang=de returns the union of the two sets, not the intersection.
  5. Disable the Tolgee provider in Storybook

    main

    To disable the Tolgee provider for a component or a specific story, set parameters.tolgee.disable to true. You can re-enable it for specific stories by setting it to false.

    import React from 'react';
    import { ConfirmButton } from './ConfirmButton';
    
    export default {
      component: ConfirmButton,
      parameters: { tolgee: { disable: true } }, // meta level disable
    };
    
    export const ButtonWithoutTolgee = {};
    
    export const ButtonWithTolgee = {
      parameters: { tolgee: { disable: false } }, // story level enable
    };
  6. Run Static Analysis for Frontend and Backend

    main

    Frontend

    Before committing, run prettier, eslint, and tsc to ensure code quality and pass the static check workflow:

    cd webapp
    npm run prettier
    npm run tsc
    npm run eslint

    Backend

    Use the ktlintFormat Gradle task to format Kotlin code:

    ./gradlew ktlintFormat
    # Frontend
    cd webapp
    npm run prettier
    npm run tsc
    npm run eslint
    
    # Backend
    ./gradlew ktlintFormat
  7. Step-by-step manual E2E environment setup

    main

    If you need to run the E2E environment manually (e.g., for debugging), follow these steps:

    1. Prepare environment: Follow the project's development guide.
    2. Install dependencies: Run npm ci within the e2e directory.
    3. Start Frontend: Run the webapp with the VITE_APP_API_URL pointing to the E2E backend port (8201).
    4. Start Docker Services: Run the required Docker services (such as the fake SMTP server) using the runDockerE2eDev Gradle task.
    5. Start Backend: Run the server application using the e2e Spring profile.
    6. Run Tests: Execute the openE2eDev Gradle task to start the tests.
    7. Cleanup: Stop the Docker services using stopDockerE2e.
  8. Override the Tolgee language in Storybook

    main

    You can override the default language for a component (meta level) or a specific story (story level) by setting the globals.tolgeeLanguage property.

    import React from 'react';
    import { ConfirmButton } from './ConfirmButton';
    
    export default {
      component: ConfirmButton,
      globals: { tolgeeLanguage: 'fr' }, // meta level override
    };
    
    export const ButtonFr = {};
    
    export const ButtonDe = {
      globals: { tolgeeLanguage: 'de' }, // story level override
    };
  9. Compute metrics using TraceQL Metrics

    main

    TraceQL metrics allow you to derive time-series metrics directly from trace data at query time without prior configuration. This is ideal for ad-hoc exploration and investigating hypotheses using any span attribute.

    Syntax

    Append a metrics function to a TraceQL selector using a pipe (|):

    { selector } | metrics_function()

    How to Query

    1. In Grafana Explore, select Tempo as the datasource.
    2. Enter your metrics query (ensuring it ends with a | function()).
    3. Click Run query.

    Grouping Results

    You can group the resulting time-series by specific attributes using the by clause:

    { status = error } | rate() by (span.http.route)
    { span.http.route = "/v2/projects" && status = error } | rate()