Automated Internationalization Platform for Cloud Music Overseas Project

Overview

This article describes the exploration and practice of multi‑language support in the Cloud Music overseas project, from manual copy management to a fully automated multilingual management system called the Qianyu Platform. It explains how the team improved development efficiency, solved common i18n problems such as semantic clarity, copy maintenance, and performance optimization, and provides valuable experience for building multilingual applications.

Background

International products must adapt their text to local languages. Maintaining separate code bases for each region wastes resources. The Cloud Music overseas team separated language resources from the code so that the same build can render texts, images, etc., for different locales without internal code changes.

This article focuses on the experience of developing the consumer side of multilingual copy, including development efficiency, project optimization, and practical implementation.

Popular i18n Libraries

Before introducing the Cloud Music solution, the article reviews common i18n libraries.

i18next and react-i18next

i18next is a JavaScript library for frontend internationalization. It offers a simple API, supports JSON, PO and other resource formats, and enables dynamic loading and caching of translation resources.

react-i18next is a React binding for i18next, providing components and higher‑order components to handle language switching, translation, and pluralization.

Usage

import i18n from "i18next");
import { initReactI18next } from "react-i18next";
import LanguageDetector from "i18next-browser-languagedetector";

i18n
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    debug: true,
    fallbackLng: "en",
    interpolation: { escapeValue: false },
    resources: {
      en: { translation: { welcome: "Welcome to my website" } },
      zh: { translation: { welcome: "欢迎来到我的网站" } }
    }
  });
export default i18n;

import { useTranslation, Trans } from "react-i18next";

function App() {
  const { t } = useTranslation();
  return (
{t("welcome")}
);
}
export default App;

vue-i18n

vue-i18n provides similar capabilities for Vue.js applications, supporting multiple language strategies, dynamic loading, and component interpolation.

const messages = {
  en: { message: { hello: 'hello world' } },
  ja: { message: { hello: 'こんにちは、世界' } }
};

const i18n = new VueI18n({
  locale: 'ja',
  messages,
});
{{ $t("message.hello") }}

Both libraries share similar usage patterns: developers embed translation keys in code, and the runtime loads the appropriate language text.

Problems with Traditional i18n Usage

Complex syntax and low efficiency (t('key') requires mental mapping).

Not semantically clear; many raw keys break readability.

Difficult to trace bugs because you must locate the key then the text.

Maintenance burden: changing copy requires code changes.

Redundant code leads to performance overhead.

High migration cost for existing projects.

Evolution of the Solution

1. Qianyu Management Platform

The team first tried Excel for copy management, which suffered from low reuse, high maintenance cost, and poor communication.

To address these issues, they built a centralized i18n management system (Qianyu) with the following features:

Unified internationalization platform for iOS, Android, frontend, and backend.

Notification to translators via enterprise communication tools.

Length comparison across languages to keep UI consistent.

Bulk import/export via Excel.

Integration with translation services.

Version control for traceability.

Role‑based permission management.

The platform dramatically improves efficiency, quality, and reduces communication friction.

Usage Flow

Create an application (one per project or app).

Create modules (one per page or feature).

Add copy.

Publish to CDN.

The article does not discuss the production‑side copy editor in detail; existing commercial i18n platforms can be referenced.

2. Qianyu Automation

Background

Initially the overseas C‑side used i18next/react‑i18next directly. The team later realized the workflow required frequent platform switches, CDN version updates, and the t('module:key') syntax was not expressive.

Automation goals:

Simplify code writing by replacing $i18n('中文') with a more readable form.

Automatically generate keys and upload new copy to the platform.

Trigger automatic publishing after upload.

Automate version management by reading cached version numbers.

Developers now only need to wrap Chinese text with $i18n() ; the rest (translation upload, CDN publishing, version handling) is performed automatically.

Implementation Details

Architecture Diagram

The solution consists of two phases.

Phase 1 – Automatic Copy Replacement

Technical Implementation : a custom Babel plugin scans the AST, finds $i18n('你好') expressions, looks up the corresponding module:key in Qianyu, and replaces the node with t('module:key') .

Iteration Updates : later versions also support pure Chinese literals, removing the need for explicit $i18n() calls.

{
  return {
    visitor: {
      Program: {
        enter(programPath, { filename }) {
          programPath.traverse({
            StringLiteral(path) { visitorCallback(path, filename); },
            JSXText(path) { visitorCallback(path, filename); },
            CallExpression(path) { ExpressionCallback(path, filename); },
          });
        },
      },
    },
  };
}

The plugin handles five writing styles: pure Chinese literals, $i18n('中文') , variable interpolation, object‑style $i18n({ module, key }) , and component‑rich strings.

function visitorCallback(path, filename) {
  const CNValue = path.node.value.trim();
  if (!(isChinese(CNValue) && !isIgnoreNode(path))) return;
  const languageModules = DefaultLangObj;
  const currentModuleName = getModuleNameByRelativePath(
    Path.relative(i18nConfig.rootPath, filename),
  );
  const currentCNObj = LOCAL_DOC?.["zh-CN"]?.[currentModuleName] || {};
  const textKey = Object.keys(currentCNObj).find(
    (key) => currentCNObj[key] === CNValue,
  );
  const languageText = languageModules?.[currentModuleName]?.[textKey] || CNValue;
  path.replaceWith(t.stringLiteral(languageText));
}

function ExpressionCallback(path, filename) {
  if (t.isObjectExpression(node?.arguments[0])) {
    if (!hasComponentAttr && keyFind && moduleFind) {
      const languageModules = DefaultLangObj;
      const key = keyFind.value.value;
      const module = moduleFind.value.value;
      const languageText = languageModules?.[module]?.[key];
      const valuesProps = findProperty(properties, VALUES);
      const newLiteral = t.stringLiteral(languageText);
      path.replaceWith(newLiteral);
      path.skip();
    }
    if (hasComponentAttr) {
      // component handling omitted for brevity
    }
  }
  if (t.isLiteral(node?.arguments[0])) {
    // similar logic for pure literals
  }
}

Phase 2 – Automatic Copy Extraction & Upload

Process : a Git commit hook runs commit scanning, compares changed files with the cache generated in Phase 1, and uploads new or modified copy to Qianyu.

Auto‑publish : after upload, the platform automatically updates the version number, ensuring the next build fetches the latest copy.

Performance Optimization (2.2)

While the automation improved developer experience, it introduced performance challenges:

Loading all language resources from CDN increases first‑paint time.

Additional library size (i18next, react‑i18next) inflates bundle size.

Rendering must wait for i18n initialization.

Static‑site generation (SSG) is not friendly to the original approach.

To solve these, the team adopted a multi‑build strategy: each language gets its own build containing only the needed resources, eliminating unnecessary code and enabling SSG.

{
  'zh-CN': { hello: '你好' },
  'en-US': { hello: 'hello' }
}

import React from "react";

const Main = () => {
  return
你好
;
};

When building for English, the source is transformed to:

import React from "react";

const Main = () => {
  return
hello
;
};

The build output is placed under dist/${I18N_LANGUAGE} , e.g., dist/en-US , dist/zh-CN , allowing language‑specific asset loading and reducing bundle size.

. 
├── en-US 
├── id-ID 
├── tr-TR 
└── zh-CN 
...

WebView pages now request resources via language‑prefixed paths such as /en-US/pageA , ensuring the correct language bundle is served.

Conclusion

The article summarizes the Cloud Music overseas project's journey from manual multilingual copy handling to a fully automated, performance‑optimized internationalization platform. The solution improves development efficiency, reduces maintenance overhead, and delivers a lightweight, fast experience for global users, while still leaving room for further optimization.