Spring框架结合Elasticsearch后端，如何实现数据的国际化支持？

Hey there! I’ve worked on several projects involving Spring + Elasticsearch with multi-language support for product data, so I can share some practical insights here. Let’s break down your options first, then cover other approaches and what I ended up using.

1. Separate Elasticsearch Index for Translations #

• Pros: Excellent query performance since Elasticsearch is built for search. You can optimize each index with language-specific analyzers (e.g., english for English, ik for Chinese) to boost search relevance.
• Cons: Higher maintenance overhead. For multiple languages, you’ll need to manage separate indexes and ensure tight data sync when products are updated/created. Query logic also gets more complex as you have to switch indexes based on the current language. This works okay for a small number of languages but scales poorly with more.

2. Store Translations in a Database #

• Pros: Easier to maintain relationships with core product data (using foreign keys or product IDs), and transactional updates are straightforward. If you already use a relational DB for product metadata, this fits into your existing workflow.
• Cons: Worse query performance compared to Elasticsearch—especially for full-text search on translated content. You’ll also have to make extra DB calls alongside ES queries, adding latency. You’d likely need caching (like Redis) to mitigate this, adding another layer of complexity.

3. Store Translations in Property Files #

• Pros: Super simple to implement since Spring already supports property file internationalization. No extra storage systems needed.
• Cons: This only works for static, pre-defined content—not dynamic data like product descriptions or expert notes that vary per item. Storing hundreds/thousands of product translations in property files leads to bloated files, slow loading, and a maintenance nightmare (you can’t update translations without redeploying). Definitely skip this for dynamic product data.

Multi-Field/Nested Document Storage in the Same Index #

This is the most common pattern I’ve seen for multi-language Elasticsearch data. You store translations directly alongside core product data in the same document, in one of two ways:

Option A: Language-Specific Subfields #

{
  "product_id": 123,
  "price": 99.99,
  "product_description": {
    "en": "High-quality wireless headphones with noise cancellation",
    "zh": "高品质无线降噪耳机",
    "fr": "Casques sans fil de haute qualité avec annulation de bruit"
  },
  "expert_note": {
    "en": "Great for long flights",
    "zh": "非常适合长途飞行",
    "fr": "Parfait pour les longs vols"
  }
}

• Pros: A single query retrieves all product data + translations. Data consistency is easy to maintain (update once, all languages stay in sync). You can apply language-specific analyzers to each subfield for better search.
• Cons: Document size grows with each language added, but this is rarely an issue unless you have dozens of languages.

Option B: Nested Translation Objects #

If you prefer grouping translations by language instead of field:

{
  "product_id": 123,
  "price": 99.99,
  "translations": [
    {
      "lang": "en",
      "product_description": "...",
      "expert_note": "..."
    },
    {
      "lang": "zh",
      "product_description": "...",
      "expert_note": "..."
    }
  ]
}

• Pros: Clean structure if you need to add new translatable fields later (no need to modify the root schema).
• Cons: Queries require filtering the nested translations array by lang, which adds a bit of complexity but is manageable with Elasticsearch’s nested queries.

Dynamic Templates + Field Aliases #

For projects with a large number of languages, use Elasticsearch’s dynamic templates to auto-create language-specific fields (e.g., product_description_en, product_description_zh) with the right analyzers. Then use field aliases to dynamically point to the correct language field based on the user’s locale. For example, an alias product_description could map to product_description_en when the locale is English.

I’ve used the multi-field subfield approach (Option A above) for most of my e-commerce multi-language projects. Here’s why:

1. Data Consistency: No risk of core product data and translations getting out of sync since everything lives in one document.
2. Query Efficiency: One ES query gets all the data I need—no extra DB calls or cross-index queries.
3. Search Optimization: I can configure analyzers per language subfield (e.g., english stemmer for English, ik_max_word for Chinese) to make search more relevant for each locale.
4. Simplicity: The schema is easy to understand, and code logic is straightforward—just append the language code to the field name when fetching data (e.g., product_description.${locale}).

• Stick to a consistent naming convention for language fields (e.g., field_lang or nested objects) to keep your code clean.
• Don’t repeat non-translatable fields (like price) across languages—keep them in the root document.
• If you have 10+ languages, consider separate indexes, but invest in a reliable sync mechanism (like Elasticsearch Reindex API or CDC tools) to keep data in sync.
• For cross-language search, use Elasticsearch’s multi_match query to target all language subfields and sort results by relevance to the user’s locale.

内容的提问来源于stack exchange，提问作者Sameer Malhotra