VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Translate Like a Pro | Localize Search Filters, Facets and Query Builders Without Changing What Users Search For

Search localization is not finished when the search box accepts another language. Users also rely on filters, facets, ranges, operators, sort choices, category counts and advanced query builders to express exactly what they want. A mistranslated filter can change the query itself even when every result title is perfectly localized.

Searches for search filter localization, faceted search localization, query builder localization, multilingual filters, search facets translation, advanced search localization and localized search UI describe a distinct reader job. Elasticsearch’s current documentation treats filters and aggregations as executable query structures that narrow or group documents; the displayed label is language, but the underlying field, bucket and predicate are data logic.

This guide explains how to localize filters, facets and query builders without silently changing what is included, excluded, counted or sorted. It covers stable field identity, translated labels, facet buckets, ranges, Boolean operators, dates, numbers, category aliases, locale-aware values, result counts, zero-result states, URLs, saved searches, analytics, accessibility and regression testing.

This article belongs to eduKateSG’s Master Art of Translation architecture. It is world-facing and add-only, and it extends the professional localization layer without replacing the established owners for search, developer tools, release control, quality assurance or translation operations.


Quick answer

Keep field IDs, operators, range boundaries and query structure stable. Localize labels, help text, display values and category names through explicit mappings. Never let translated words become the machine query unless the product was intentionally designed for language-aware semantic parsing.

  • Separate field identity from labels.
  • Preserve Boolean and comparison operators.
  • Map localized facets to stable bucket IDs.
  • Format dates and numbers without moving boundaries.
  • Persist saved searches as structured state.
  • Verify query payloads and result sets.

1. Separate field identity from labels

A backend field such as product.category or author_id should remain stable while the interface label changes by locale. This matters because saved searches, APIs and analytics depend on consistent field identity.

Method. Use canonical field IDs and a locale resource for the visible label. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. Users may see a natural translation of Category while the system still queries product.category.

Failure pattern. Using the target-language label as the field key breaks queries when the locale changes. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Switch locales and compare serialized query objects. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

2. Treat facets as bucket views

A facet label represents a bucket or concept rather than arbitrary prose. This matters because faceted search systems group records into stable buckets and expose counts.

Method. Map each bucket ID to localized labels and synonyms without rewriting the bucket. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. A canonical color code can display different words in different languages.

Failure pattern. Sending the translated word as the backend bucket value makes filters dependent on UI copy. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Select the same concept in two locales and compare backend parameters. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

3. Preserve include and exclude semantics

Positive and negative filters must remain opposites. This matters because one mistranslated negation can reverse the result set.

Method. Bind localized control labels to explicit include/exclude operation IDs. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. Exclude out-of-stock should remove those records, not surface them.

Failure pattern. A softened target label sounds like show unavailable items. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Use a fixture containing both included and excluded records. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

4. Keep AND, OR and NOT explicit

Boolean grouping is executable logic. This matters because ordinary conjunctions can be ambiguous when nested.

Method. Use established logical terms plus visible grouping and parentheses where appropriate. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. A AND (B OR C) must not be presented as (A AND B) OR C.

Failure pattern. Flattening the wording hides precedence. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Run a query whose output differs under the two groupings. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

5. Localize numeric ranges without moving thresholds

The stored minimum, maximum and comparison operator are numeric logic. This matters because localized decimal separators and units are display concerns.

Method. Parse locale-aware input into canonical numeric values and format only for presentation. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. A range 1.5–2.5 can display with comma decimals without changing floats.

Failure pattern. The translated UI sends localized number strings directly to a parser expecting source punctuation. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Test exact boundary items. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

6. Preserve inclusive and exclusive comparisons

At least, more than, no more than and under encode different operators. This matters because a single equality boundary changes membership.

Method. Map each target phrase to >=, >, <= or < and test it with the boundary value. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. At least 10 includes 10; more than 10 does not.

Failure pattern. Near-synonyms in the target language are treated as interchangeable. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Test 9, 10 and 11. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

7. Compute relative dates in the intended zone

Today, yesterday and this week describe calendar windows. This matters because server UTC may not match the user’s local date.

Method. Compute ranges using the product’s user-time-zone rule and localize only the visible phrase. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. Two users can see Today while the internal UTC boundaries differ.

Failure pattern. One global UTC boundary shifts results around midnight. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Test users on opposite sides of UTC midnight. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

8. Match facet-count wording to count logic

Counts may reflect global buckets or the currently filtered universe. This matters because the number is meaningful only relative to the aggregation model.

Method. Document count behavior and choose wording such as available results or total accordingly. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. A brand selection may recompute color counts within that brand.

Failure pattern. The UI says total while showing context-filtered counts. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Apply another filter and inspect count changes. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

9. Handle zero-count states deliberately

Zero available matches does not always mean a category is unsupported. This matters because the state can be temporary under current filters.

Method. Distinguish disabled, unavailable under current filters and globally unsupported states. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. A size can return when another selected filter is removed.

Failure pattern. The target label says not supported and misleads users. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Remove the restricting predicate. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

10. Generate active-filter chips from structured state

A chip is a human rendering of field, operator and value. This matters because concatenated fragments can become ambiguous across languages.

Method. Use complete localized patterns for each filter type. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. Price under 100 can reorder naturally in the target sentence.

Failure pattern. English fragment order is preserved in a language that needs different syntax. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Remove the chip and confirm only that predicate disappears. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

11. Separate structured filters from search synonyms

A facet bucket and a free-text synonym are adjacent but distinct mechanisms. This matters because one changes structured selection while the other changes retrieval analysis.

Method. Keep bucket mapping independent from the synonym layer covered by multilingual search and collation. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. A category can have several local search aliases while preserving one canonical facet ID.

Failure pattern. Changing a facet translation accidentally modifies synonym expansion. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Test structured and free-text searches separately. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

12. Disambiguate colliding translated labels

Two different fields can translate to the same visible word. This matters because users need to know which object they are constraining.

Method. Add domain qualifiers such as Order status and Account status. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. Both can remain separate IDs even when the base word is identical.

Failure pattern. The builder shows two identical Status controls. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. A native reviewer can predict the affected data field. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

13. Localize sort labels without changing keys

Newest, price low-to-high and highest rated map to stable sort field/direction pairs. This matters because a reversed phrase reverses the ordering.

Method. Bind every localized label to a canonical sort key. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. Price ascending remains price:asc even if target wording changes order.

Failure pattern. Low-to-high maps to descending. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Use a known ordered fixture. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

14. Persist saved searches as structured queries

A saved search is durable user intent. This matters because translated labels may change after copy edits or locale switches.

Method. Store field IDs, operators and values, then regenerate labels at display time. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. A saved category filter opens under a new language with the new label but same results.

Failure pattern. Saved text labels stop resolving after translation updates. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Save in one locale and reopen in another. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

15. Localize validation without rewriting the query

A query-builder error explains a malformed condition. This matters because repair guidance must point to the right field and rule.

Method. Generate messages from structured error codes with localized field labels. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. Minimum must not exceed maximum can reference the localized price field.

Failure pattern. A generic Invalid filter gives no route to repair. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Fix the condition from the target message alone. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

16. Keep shareable search URLs portable

A shared URL should preserve query semantics across locales where product design allows. This matters because translated parameter values create fragile links.

Method. Use canonical query parameters or encoded structured state and render labels locally. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. color=red can remain stable while the UI displays the local word.

Failure pattern. A target-language category string no longer resolves in another locale. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Open the same link under two languages. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

17. Measure usage with stable IDs

Analytics should compare the same filter across markets. This matters because localized labels fragment telemetry.

Method. Emit canonical field/value IDs plus locale as separate dimensions. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. One color-filter ID can be compared across French and German.

Failure pattern. Dashboards treat every translation as a separate feature. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Inspect events after locale switching. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.

18. Regression-test query equivalence

The serialized predicate and result set are the executable truth. This matters because screenshots cannot reveal a misbound operator.

Method. Add known filters and expected results to the localization regression suite. The implementation should make that mapping explicit enough that a second team can inspect it without relying on the memory of the original translator or developer.

Example. A query can assert exact included record IDs in every locale.

Failure pattern. A fluent label maps to the wrong predicate. The danger is not merely awkward wording; it is that human-facing language can silently alter the system decision, object identity or historical state that the interface is meant to expose.

Verification. Compare query objects and result membership. A useful release test checks both what the user reads and what the machine actually executes, stores, retrieves or resolves.


A repeatable operating sequence

A safe search-filter workflow begins with stable query semantics and overlays target-language labels and locale formatting.

  • Inventory fields, operators, buckets and sort keys.
  • Assign stable IDs.
  • Create locale labels and disambiguation.
  • Format numbers/dates at presentation time.
  • Persist structured state in saves and URLs.
  • Keep telemetry canonical.
  • Test facet counts and zero states.
  • Compare query payloads and result sets.

Use this sequence as a loop rather than a one-way checklist. When final testing reveals a problem, trace it back to the earliest useful cause—source wording, object identity, data type, query structure, workflow graph, schema, ref, or product state—and repair that source when possible.

Worked scenarios

1. Price boundary reversal

A translated under-100 label actually maps to >=100. The key risk is a small language error changing commercial results.

Bind the phrase to <100 and test records at 99.99, 100 and 100.01. Then verify the result in the real system rather than approving the sentence in isolation.

2. Two status fields collapse

Order status and account status have identical target labels. The key risk is users filtering the wrong object.

Add contextual qualifiers while preserving separate IDs. Then verify the result in the real system rather than approving the sentence in isolation.

3. Saved filter breaks after locale switch

The saved state contains translated category text. The key risk is display language becoming machine identity.

Migrate to concept IDs and regenerate labels. Then verify the result in the real system rather than approving the sentence in isolation.

4. Facet counts confuse users

Counts remain global while users assume current-filter availability. The key risk is wording and aggregation semantics diverging.

Align copy with actual count behavior or change the query model deliberately. Then verify the result in the real system rather than approving the sentence in isolation.

5. Today uses server UTC

The relative-date filter shifts around local midnight. The key risk is same phrase representing the wrong calendar window.

Compute boundaries in the intended user time zone. Then verify the result in the real system rather than approving the sentence in isolation.

6. Shared link fails in another language

The URL contains localized category labels. The key risk is links becoming language-fragile.

Encode canonical values and localize only rendering. Then verify the result in the real system rather than approving the sentence in isolation.

Search filters and query builders: twenty professional practice cases

Treat each case as a small diagnostic lab. Identify the invariant, the localizable layer, the evidence needed to decide, and the final test that would prove the localized interface preserves the original operation.

1. A brand facet has a localized display name

Keep its underlying brand ID stable. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

2. An OR group contains three categories

Preserve grouping and operator semantics. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

3. A slider displays comma decimals

Keep canonical numeric values beneath the UI. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

4. A date filter says before 2025

Test the exact exclusive boundary. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

5. A rating filter shows 4+

Map it to >=4, not exactly 4. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

6. A filter label expands by 70%

Reflow the UI rather than abbreviating into ambiguity. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

7. A facet value lacks a translation

Use an approved fallback while keeping the bucket ID. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

8. A regional synonym is common

Add a search alias without changing facet identity. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

9. Two abbreviations collide

Use fuller target labels. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

10. A user removes one filter chip

Delete exactly that predicate. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

11. A sort option says best

Replace subjective wording with the actual sorting criterion. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

12. A price range displays local currency

Do not silently convert currency unless product logic does. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

13. A taxonomy label is renamed

Keep saved searches linked to the same concept ID. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

14. An advanced field accepts free text

Separate label localization from language analysis of input. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

15. Zero-count facets are hidden

Do not imply the category does not exist. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

16. A post-filter changes hits not buckets

Make count wording consistent with that model. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

17. Counts use compact notation

Format 1K/1 000 locally without changing the integer. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

18. A URL carries a date range

Keep canonical timestamps. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

19. Nested groups wrap badly

Fix layout without flattening logic. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

20. Telemetry stores translated labels

Add canonical IDs for cross-market comparison. Write down why the choice is safe, which machine identity or semantic rule must remain stable, and what evidence would show that your assumption is wrong.

Then change one condition—locale, data type, user role, branch, query, device or stored object—and repeat the test. This changed-condition pass is what separates a durable localization rule from a one-off fix.

Implementation notes for production teams

A production localization of search filters, facets and query builders should have a written source specification before language work begins. That specification does not need to be elaborate, but it should identify the machine objects that are invariant, the labels that may change by locale, the product states a reviewer must exercise, and the owners who can resolve ambiguity. When these boundaries are absent, reviewers tend to compensate with wording changes that make one screen look better while weakening consistency elsewhere.

Change management matters just as much as first translation. New fields, actions, operators, schema objects, workflow nodes or repository states should trigger a focused localization review when their semantics change. A cosmetic source edit may require no functional retest; a renamed operation that changes behavior does. Teams therefore benefit from binding language review to semantic version or product change rather than treating every modified string as equally important.

Training should use real artifacts instead of abstract terminology alone. Give translators representative screenshots, serialized examples, sample queries, workflow traces, database objects or repository histories, depending on the product. Let reviewers see what happens before and after an action. This gives them evidence for choosing precise target language and exposes cases where the source itself is ambiguous.

Telemetry and support evidence can also improve localization. Repeated filter reversals, failed automation setup, database-action confusion or merge-recovery errors may reveal that users are misunderstanding the interface. These signals do not prove a translation defect by themselves, but they are strong prompts for in-context review. Combine them with issue reproduction and native-language judgment rather than optimizing only for complaint counts.

Finally, keep a recovery path. A localized interface can ship a wrong mapping even after careful review. Teams should be able to identify the affected resource, restore the previous approved label or mapping, and verify that saved user state remains intact. The point is not to make mistakes impossible; it is to make them observable, reversible and less likely to recur.

Evidence worth keeping

Keep the approved source definition, target terminology decision, representative screenshot or state capture, the stable machine identifier, the test case used for sign-off, and the release version in which the localization shipped. Together these artifacts form a compact explanation of what the translated interface was supposed to mean.

When to revisit the design

Revisit the localization whenever the underlying semantic model changes, when a new locale exposes an ambiguity, when a platform upgrade changes behavior, or when production evidence shows users repeatedly interpreting the same control incorrectly. Do not wait for a full rewrite. Small, well-scoped corrections at the semantic boundary usually cost less and protect more downstream content.

Release checklist

  • Field IDs are stable.
  • Facet IDs are stable.
  • Boolean logic is preserved.
  • Range boundaries are unchanged.
  • Relative dates use correct time zones.
  • Count wording matches aggregation behavior.
  • Ambiguous labels are disambiguated.
  • Sort keys/directions stay stable.
  • Saved searches store structured state.
  • Shareable URLs preserve semantics.
  • Analytics uses canonical IDs.
  • Regression confirms result equivalence.

Frequently asked questions

Should facet values be translated?

Display labels often should be, but the bucket or concept identity should remain stable. The important discipline is to keep the translated explanation separate from the underlying technical identity or executable semantics.

Can translated labels be sent to the backend?

Usually that is fragile; use explicit mappings to canonical fields and values. The important discipline is to keep the translated explanation separate from the underlying technical identity or executable semantics.

Why are counts difficult?

Because counts can be computed in different filter contexts and the language must describe the actual model. The important discipline is to keep the translated explanation separate from the underlying technical identity or executable semantics.

How should ranges be localized?

Localize formatting while preserving exact operators and numeric boundaries. The important discipline is to keep the translated explanation separate from the underlying technical identity or executable semantics.

What about saved searches?

Persist the structured query so intent survives locale and copy changes. The important discipline is to keep the translated explanation separate from the underlying technical identity or executable semantics.

Can sort labels change?

Yes, but each must map to the same field and direction. The important discipline is to keep the translated explanation separate from the underlying technical identity or executable semantics.

How does this differ from multilingual search?

This article owns structured filter semantics; free-text analysis, synonyms and collation remain with the existing search owner. The important discipline is to keep the translated explanation separate from the underlying technical identity or executable semantics.

What is the strongest QA test?

Compare serialized queries and known result sets across locales. The important discipline is to keep the translated explanation separate from the underlying technical identity or executable semantics.

Selected references and next routes

Conclusion

Filters are executable meaning disguised as interface text. Their labels can change; their predicates cannot.

When stable identities, precise operator language and result-set regression work together, users can refine search naturally in their own language without the system quietly searching for something else.

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading