[UX/i18n][zh-CN] “Plugins” and “Apps” are confusing and appear as duplicate entry points

Summary

In the Codex client, the Simplified Chinese terminology and navigation for Plugins and Apps make their relationship difficult to understand.

This is both a localization issue and an information-architecture issue: GitHub appears as separate top-level entries under both 插件 (Plugins) and 应用 (Apps), with separate pages and toggles, while the UI does not clearly explain their containment, dependency, or different responsibilities.

Related in-app feedback ID: 01a0464a-eead-7fc2-b27f-19c626fc0df1

Current behavior

1. The management page presents 插件 (Plugins), 应用 (Apps), MCP, and 技能 (Skills) as parallel top-level tabs.
2. GitHub appears in both the Plugins tab and the Apps tab, with a separate entry and toggle in each.
3. The GitHub Plugin detail page contains an Apps section listing GitHub and GitHub Enterprise.
4. The GitHub App detail page exposes the connection state and 104 read/write operations.
5. The UI does not make it clear:
   • whether the two GitHub entries are duplicates;
   • whether both must be enabled;
   • what each toggle controls;
   • how Plugins, Apps, MCP, and Skills relate to each other;
   • what stops working when either entry is disabled.

Why the Chinese terminology is confusing

In common Simplified Chinese product terminology:

• 应用 usually means a complete user-facing application or primary entry point.
• 插件 usually means a component or tool that adds capabilities to another product.

The current UI appears to present the opposite relationship:

• the GitHub Plugin acts as the upper-level package, workflow, and discovery entry;
• the GitHub App provides the authenticated connection and the concrete callable operations.

This makes it natural for Chinese users to assume that the App is the main entry and the Plugin is the underlying tool, even though the product structure presented in the detail pages suggests otherwise.

User impact

Users must understand the internal plugin architecture before they can confidently configure GitHub. The duplicate name and separate toggles create uncertainty about which item to enable, which one grants permissions, and whether enabling or disabling one affects the other.

Suggested design

Prefer one user-facing GitHub entry, for example:

GitHub
Extension enabled · Account connected · 104 tools available

Its detail page could combine:

• account connection;
• available tools and capabilities;
• read/write permissions;
• GitHub Enterprise configuration;
• advanced component settings.

Apps, MCP servers, and Skills can remain separate internally while being shown under an Advanced settings or Components section.

If the current navigation must remain, consider clarifying the Simplified Chinese labels:

• 插件 → 扩展包 or 功能包 (Extension/Capability package)
• 应用 → 连接器 or 工具与连接 (Connector/Tools & connections)

At minimum, each entry should explain its role, dependencies, and toggle behavior.

Expected result

A user should be able to understand, without knowing the internal architecture:

1. what GitHub enables;
2. whether the account is connected;
3. which permissions and tools are available;
4. what each toggle changes;
5. how the components relate to the single GitHub integration.

Additional context

Screenshots of the Plugins list, Apps list, GitHub Plugin detail page, and GitHub App operations page were included with the related in-app feedback session.

Start by reviewing the Plugins and Apps management pages and the GitHub Plugin and App detail pages shown in the attached screenshots. Trace how the two entries, toggles, connection state, permissions, and tools are presented. Done means users can identify one GitHub integration, understand its connection and permissions, and know what each toggle changes without internal architecture knowledge.