Skip to content

feat(mobile app): expose app translations via REST API for mobile clients#39959

Open
divyanshu-patil wants to merge 2 commits intoRocketChat:developfrom
divyanshu-patil:fix/commands
Open

feat(mobile app): expose app translations via REST API for mobile clients#39959
divyanshu-patil wants to merge 2 commits intoRocketChat:developfrom
divyanshu-patil:fix/commands

Conversation

@divyanshu-patil
Copy link
Copy Markdown
Contributor

@divyanshu-patil divyanshu-patil commented Mar 30, 2026

Proposed changes

Adds a new REST endpoint GET /api/v1/apps.translations that aggregates i18n translation strings from all installed and enabled Rocket.Chat Apps.

Currently, App translations (e.g. slash command descriptions from Jitsi, Giphy, etc.) are only injected into the web client at runtime via TAPi18next.addResourceBundle(). The React Native client has no way to access these translations, causing raw internal keys like app-3b387ba9-f57c-44c6-9810-8c0256abd64c.command_description to be displayed to users instead of human-readable text.

This endpoint solves that by reading languageContent directly from each app's storage item and returning a flat merged map of all translation keys for the requested language, with English as a fallback.

Example response:

{
  "language": "en",
  "translations": {
    "app-3b387ba9-f57c-44c6-9810-8c0256abd64c.command_description": "Generate a Jitsi conference call.",
    "app-3b387ba9-f57c-44c6-9810-8c0256abd64c.command_params": "username"
  },
  "success": true
}

Issue(s)

RocketChat/Rocket.Chat.ReactNative#7071

Related PRs

RocketChat/Rocket.Chat.ReactNative#7072

Steps to test or reproduce

  1. Install any Rocket.Chat App that registers a slash command (e.g. Jitsi)
  2. Call the new endpoint:
curl -X GET \
  'http://localhost:3000/api/v1/apps.translations?language=en' \
  -H 'X-Auth-Token: your-token' \
  -H 'X-User-Id: your-user-id'
  1. Verify the response contains human-readable translation values for all installed app keys
  2. Test with a language that doesn't exist for an app (e.g. ?language=fr when only en is available) — should fall back to English strings

Further comments

  • The Apps orchestrator is imported lazily inside the action function (await import(...)) to avoid a circular initialization crash at boot time — importing it at module level causes API.v1 to be undefined when the apps communication chain loads
  • Apps with no languageContent are silently skipped
  • This is the server-side counterpart to the React Native client PR which consumes this endpoint, caches translations in WatermelonDB, and uses them to resolve slash command descriptions in the autocomplete UI

@divyanshu-patil divyanshu-patil requested a review from a team as a code owner March 30, 2026 07:33
@dionisio-bot
Copy link
Copy Markdown
Contributor

dionisio-bot bot commented Mar 30, 2026

Looks like this PR is not ready to merge, because of the following issues:

  • This PR is missing the 'stat: QA assured' label
  • This PR is missing the required milestone or project

Please fix the issues and try again

If you have any trouble, please check the PR guidelines

@changeset-bot
Copy link
Copy Markdown

changeset-bot bot commented Mar 30, 2026

⚠️ No Changeset found

Latest commit: 1b230da

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Mar 30, 2026

Walkthrough

Added a new REST endpoint GET /apps.translations to the API server that retrieves and aggregates app translations for a specified language. The endpoint validates the optional language query parameter, initializes the apps manager, iterates enabled apps to extract their translations with per-app error handling, and returns merged results with app-prefixed keys.

Changes

Cohort / File(s) Summary
API Server Entrypoint
apps/meteor/app/api/server/index.ts
Added import of new i18n v1 module to register translation endpoints during server initialization.
i18n Endpoint Implementation
apps/meteor/app/api/server/v1/i18n.ts
New file implementing GET /apps.translations endpoint with AJV-based parameter validation (language string, min 2 chars), typed 200/400/401 response schemas, language normalization (default 'en', split and lowercase), lazy apps manager retrieval, and per-app translation extraction with error handling and prefixed key merging.

Sequence Diagram

sequenceDiagram
    actor Client
    participant API as API Server
    participant Validator as Validator (AJV)
    participant Manager as Apps Manager
    participant App as Enabled Apps
    participant Storage as App Storage

    Client->>API: GET /apps.translations?language=pt-BR
    API->>Validator: Validate language parameter
    Validator-->>API: ✓ Valid
    API->>API: Normalize language: "pt-br"
    API->>Manager: getManager()
    Manager-->>API: Manager instance (or null)
    alt Manager exists
        API->>Manager: get({ enabled: true })
        Manager-->>API: List of enabled apps
        loop For each app
            API->>Storage: app.getStorageItem().languageContent
            Storage-->>API: Language content map
            API->>API: Select translations for "pt-br" or fallback to "en"
            API->>API: Merge with prefix "app-${appId}.${key}"
        end
    else Manager unavailable
        API-->>Client: 400 Failure response
    end
    API-->>Client: 200 { language, translations, success: true }
Loading

Estimated Code Review Effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested Labels

type: feature

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The PR title accurately describes the main feature being added: a new REST API endpoint to expose app translations for mobile clients. It directly relates to the core change in the changeset.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 2 files

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
apps/meteor/app/api/server/v1/i18n.ts (1)

40-40: Underscore-based locale codes will not be normalized.

The split on '-' handles BCP-47 tags like "en-US""en", but locale codes using underscores (e.g., "pt_BR") will remain as-is and likely fail to match stored translations. If mobile clients might send underscore-based locales, consider normalizing both separators:

-const language = (this.queryParams.language ?? 'en').split('-')[0].toLowerCase();
+const language = (this.queryParams.language ?? 'en').split(/[-_]/)[0].toLowerCase();
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@apps/meteor/app/api/server/v1/i18n.ts` at line 40, Normalize incoming locale
separators for the language extraction in i18n.ts: instead of only splitting
this.queryParams.language on '-' (used to set the language variable), split or
normalize both '-' and '_' (e.g., replace '_' with '-' or split on /[-_]/)
before taking the primary subtag and lowercasing it so underscore-based codes
like "pt_BR" become "pt" and match stored translations.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@apps/meteor/app/api/server/v1/i18n.ts`:
- Line 40: Normalize incoming locale separators for the language extraction in
i18n.ts: instead of only splitting this.queryParams.language on '-' (used to set
the language variable), split or normalize both '-' and '_' (e.g., replace '_'
with '-' or split on /[-_]/) before taking the primary subtag and lowercasing it
so underscore-based codes like "pt_BR" become "pt" and match stored
translations.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: e84cb8ef-2747-4c91-9805-d4bbdb7ba104

📥 Commits

Reviewing files that changed from the base of the PR and between 4235cd9 and 1b230da.

📒 Files selected for processing (2)
  • apps/meteor/app/api/server/index.ts
  • apps/meteor/app/api/server/v1/i18n.ts
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: cubic · AI code reviewer
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{ts,tsx,js}

📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)

**/*.{ts,tsx,js}: Write concise, technical TypeScript/JavaScript with accurate typing in Playwright tests
Avoid code comments in the implementation

Files:

  • apps/meteor/app/api/server/index.ts
  • apps/meteor/app/api/server/v1/i18n.ts
🧠 Learnings (10)
📓 Common learnings
Learnt from: d-gubert
Repo: RocketChat/Rocket.Chat PR: 37547
File: packages/i18n/src/locales/en.i18n.json:634-634
Timestamp: 2025-11-19T12:32:29.696Z
Learning: Repo: RocketChat/Rocket.Chat
Context: i18n workflow
Learning: In this repository, new translation keys should be added to packages/i18n/src/locales/en.i18n.json only; other locale files are populated via the external translation pipeline and/or fall back to English. Do not request adding the same key to all locale files in future reviews.
Learnt from: smirk-dev
Repo: RocketChat/Rocket.Chat PR: 39625
File: apps/meteor/app/api/server/v1/push.ts:85-97
Timestamp: 2026-03-14T14:58:58.834Z
Learning: In RocketChat/Rocket.Chat, the `push.token` POST/DELETE endpoints in `apps/meteor/app/api/server/v1/push.ts` were already migrated to the chained router API pattern on `develop` prior to PR `#39625`. `cleanTokenResult` (which strips `authToken` and returns `PushTokenResult`) and `isPushTokenPOSTProps`/`isPushTokenDELETEProps` validators already exist on `develop`. PR `#39625` only migrates `push.get` and `push.info` to the chained pattern. Do not flag `cleanTokenResult` or `PushTokenResult` as newly introduced behavior-breaking changes when reviewing this PR.
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38974
File: apps/meteor/app/api/server/v1/im.ts:220-221
Timestamp: 2026-02-24T19:09:09.561Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs for apps/meteor/app/api/server/v1 endpoints, maintainers prefer to avoid any logic changes; style-only cleanups (like removing inline comments) may be deferred to follow-ups to keep scope tight.
📚 Learning: 2026-02-24T19:09:09.561Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38974
File: apps/meteor/app/api/server/v1/im.ts:220-221
Timestamp: 2026-02-24T19:09:09.561Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs for apps/meteor/app/api/server/v1 endpoints, maintainers prefer to avoid any logic changes; style-only cleanups (like removing inline comments) may be deferred to follow-ups to keep scope tight.

Applied to files:

  • apps/meteor/app/api/server/index.ts
📚 Learning: 2026-03-12T10:26:26.697Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 39340
File: apps/meteor/app/api/server/v1/im.ts:1349-1398
Timestamp: 2026-03-12T10:26:26.697Z
Learning: In `apps/meteor/app/api/server/v1/im.ts` (PR `#39340`), the `DmEndpoints` type intentionally includes temporary stub entries for `/v1/im.kick`, `/v1/dm.kick`, `/v1/im.leave`, and `/v1/dm.leave` (using `DmKickProps` and `DmLeaveProps`) even though no route handlers exist for them yet. These stubs were added to preserve type compatibility after removing the original `DmLeaveProps` and related files. They are planned for cleanup in a follow-up PR. Do not flag these as missing implementations when reviewing this file until the follow-up is merged.

Applied to files:

  • apps/meteor/app/api/server/index.ts
  • apps/meteor/app/api/server/v1/i18n.ts
📚 Learning: 2026-03-16T21:50:42.118Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39676
File: .changeset/migrate-users-register-openapi.md:3-3
Timestamp: 2026-03-16T21:50:42.118Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs, removing endpoint types and validators from `rocket.chat/rest-typings` (e.g., `UserRegisterParamsPOST`, `/v1/users.register` entry) is the *required* migration pattern per RocketChat/Rocket.Chat-Open-API#150 Rule 7 ("No More rest-typings or Manual Typings"). The endpoint type is re-exposed via a module augmentation `.d.ts` file in the consuming package (e.g., `packages/web-ui-registration/src/users-register.d.ts`). This is NOT a breaking change — the correct changeset bump for `rocket.chat/rest-typings` in this scenario is `minor`, not `major`. Do not flag this as a breaking change during OpenAPI migration reviews.

Applied to files:

  • apps/meteor/app/api/server/index.ts
  • apps/meteor/app/api/server/v1/i18n.ts
📚 Learning: 2026-02-25T20:10:16.987Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38913
File: packages/ddp-client/src/legacy/types/SDKLegacy.ts:34-34
Timestamp: 2026-02-25T20:10:16.987Z
Learning: In the RocketChat/Rocket.Chat monorepo, packages/ddp-client and apps/meteor do not use TypeScript project references. Module augmentations in apps/meteor (e.g., declare module 'rocket.chat/rest-typings') are not visible when compiling packages/ddp-client in isolation, which is why legacy SDK methods that depend on OperationResult types for OpenAPI-migrated endpoints must remain commented out.

Applied to files:

  • apps/meteor/app/api/server/index.ts
📚 Learning: 2026-03-20T13:52:29.575Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 39553
File: apps/meteor/app/api/server/v1/stats.ts:98-117
Timestamp: 2026-03-20T13:52:29.575Z
Learning: In `apps/meteor/app/api/server/v1/stats.ts`, the `statistics.telemetry` POST endpoint intentionally has no `body` AJV schema in its route options. The proper request body shape (a `params` array of telemetry event objects) has not been formally defined yet, so body validation is deferred to a follow-up. Do not flag the missing body schema for this endpoint during OpenAPI migration reviews.

Applied to files:

  • apps/meteor/app/api/server/index.ts
  • apps/meteor/app/api/server/v1/i18n.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In the Rocket.Chat repository, do not reference Biome lint rules in code review feedback. Biome is not used even if biome.json exists; only reference Biome rules if there is explicit, project-wide usage documented. For TypeScript files, review lint implications without Biome guidance unless the project enables Biome rules.

Applied to files:

  • apps/meteor/app/api/server/index.ts
  • apps/meteor/app/api/server/v1/i18n.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In this repository (RocketChat/Rocket.Chat), Biome lint rules are not used even if a biome.json exists. When reviewing TypeScript files (e.g., packages/ui-voip/src/providers/useMediaSession.ts), ensure lint suggestions do not reference Biome-specific rules. Rely on general ESLint/TypeScript lint rules and project conventions instead.

Applied to files:

  • apps/meteor/app/api/server/index.ts
  • apps/meteor/app/api/server/v1/i18n.ts
📚 Learning: 2026-02-24T19:09:01.522Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38974
File: apps/meteor/app/api/server/v1/im.ts:220-221
Timestamp: 2026-02-24T19:09:01.522Z
Learning: In Rocket.Chat OpenAPI migration PRs for endpoints under apps/meteor/app/api/server/v1, avoid introducing logic changes. Only perform scope-tight changes that preserve behavior; style-only cleanups (e.g., removing inline comments) may be deferred to follow-ups to keep the migration PR focused.

Applied to files:

  • apps/meteor/app/api/server/v1/i18n.ts
📚 Learning: 2026-02-23T17:53:06.802Z
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 35995
File: apps/meteor/app/api/server/v1/rooms.ts:1107-1112
Timestamp: 2026-02-23T17:53:06.802Z
Learning: During PR reviews that touch endpoint files under apps/meteor/app/api/server/v1, enforce strict scope: if a PR targets a specific endpoint (e.g., rooms.favorite), do not propose changes to unrelated endpoints (e.g., rooms.invite) unless maintainers explicitly request them. Focus feedback on the touched endpoint's behavior, API surface, and related tests; avoid broad cross-endpoint changes in the same PR unless requested.

Applied to files:

  • apps/meteor/app/api/server/v1/i18n.ts
🔇 Additional comments (4)
apps/meteor/app/api/server/index.ts (1)

47-47: LGTM!

The import correctly registers the new i18n route module and is properly placed before the openApi import which must remain last.

apps/meteor/app/api/server/v1/i18n.ts (3)

43-44: Comment documents a critical non-obvious constraint.

The coding guidelines advise avoiding code comments, but this one explains a necessary workaround for a circular initialization crash. Given that the PR objectives also highlight this requirement, keeping the comment is justified for maintainability.


57-82: Solid per-app error isolation.

The try/catch around each app's translation extraction ensures that a single app's failure (e.g., malformed storage) doesn't prevent other apps' translations from being returned. The fallback from the requested language to English also aligns with the stated requirements.


84-85: LGTM!

The response structure correctly matches the declared 200 schema, including an empty translations object when no apps provide translations for the requested language.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

community type: feature Pull requests that introduces new feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant