Operations changed “Pending Shipment” to “Awaiting Shipment” and the admin buttons all disappeared at once—who should own status copy?

When a status field is represented by 0, 1, and 2, the question of who provides the display copy should not be decided by which side saves effort. It should be decided by how often the copy changes, how many clients consume it, and whether it needs customer-specific or multilingual variants. Based on 2026 project delivery experience, a more reliable split is this: the API accepts only the raw status code; display copy is provided centrally by the backend or through a dictionary API; the frontend does not participate in translation. Hardcoding Chinese copy in the frontend only pays off in small systems with a single client, few statuses, and copy that does not change for a long time. Below, this article clarifies the decision criteria, the on-the-ground costs, and verifiable acceptance criteria.

Status codes and display copy are two different things

A status code is a contract between systems, used for branching logic, queries, statistics, and storage. Copy is for people to read, and it changes with operations terminology, brand language, customer customization, and multilingual requirements. Putting the two into the same field means the value intended for machines changes together with the value intended for people; one wording change forces regression testing of every branch.

A typical counterexample seen in projects is this: the API returns status as a Chinese string such as “Pending Shipment,” and the frontend compares strings to control button visibility. Operations changes “Pending Shipment” to “Awaiting Shipment,” and the buttons all disappear the next day. This is not frontend carelessness; code and name were never layered from the start.

Besides pages, there are two consumers that are easily forgotten: exported files and operations logs. In the Excel file exported by operations, the status column contains 0 and 1; customer service cannot understand it and has to ask engineering. On-call staff checking logs see numbers as well, and troubleshooting efficiency drops noticeably. These two places actually need unified copy even more.

• Raw code: stable, enumerable, and documented; used only for judgement and storage; new values are added for new statuses, and old values are never reused.
• Display name: changeable, translatable, and customizable per customer; used only for rendering and never for conditional logic.
• Semantic level: indicates whether the status is in progress, terminal, or exceptional, and determines whether it can be canceled, refunded, or included in statistics.

Where does hardcoding Chinese copy in the frontend start to hurt?

A common situation on delivery sites looks like this: one admin system has to serve three clients at the same time—a PC admin console, a mini program, and a mobile app. Operations tweaks the copy weekly, there is no unified glossary when the project starts, and the schedule is tight. To meet the launch deadline, the first version hardcodes a status mapping in each of the three frontends; at the time, it really does save time. About two months after launch, operations changes three pieces of wording. The three clients have to be scheduled for separate releases. During the days when versions are not aligned, the wording customer service sees does not match what users see. Later rework goes through two rounds, and one round coincides with a mini program review delay. This kind of cost does not appear on development day; it is paid when the copy first changes.

When there is a single client, copy almost never changes, and there is no multilingual plan, hardcoding in the frontend is indeed easier; there is no need to deny that. The problem is that it puts something changeable into the release cycle: as soon as either the number of clients or the frequency of copy changes rises, maintenance cost does not grow linearly. Based on experience ranges, when 2–3 clients run in parallel, the typical range for one wording adjustment to take effect across all clients is 3–7 days; if the change is made through backend dictionary configuration, the typical range is a few hours to 1 business day.

• If mapping is done only in the frontend, backend logs and exported files still contain 0/1, and operations cannot match them to statuses.
• The same status is written differently on different pages—“Paid” and “Payment Complete” coexist—so customer service scripts do not align.
• When the backend adds a new status value, older frontend versions do not recognize it, and the page shows blank or undefined.
• Only when internationalization requirements come up does it become clear that Chinese text was used as the key, and the mapping has to be rewritten.

Comparing three approaches: how many layers does one copy change touch?

Each approach has its costs. Looking at three dimensions—whether a copy change requires a release, whether multiple clients stay consistent, and whether internationalization is needed—makes the conclusion clearer. Below is an experience-range summary based on common 2026 delivery practices; the choice depends on the number of clients and the frequency of changes.

• Frontend hardcoding: copy changes require releases; separate implementations across clients easily diverge; internationalization basically requires rework. Suitable for internal systems with a single client, few statuses, and stable copy.
• Backend returns Chinese copy: changes take effect by editing the dictionary table or configuration; multiple clients are naturally consistent; multilingual support can switch by request header or tenant. The cost is an extra field in the API, and someone must own copy maintenance.
• Dictionary API plus frontend mapping: business APIs return only codes; the frontend fetches the dictionary once at startup and caches it. Suitable for scenarios with a large status set shared across modules. The cost is an extra request and a cache, and when dictionary versions are inconsistent, old copy may briefly appear.

For end-to-end time of one copy change, the experience ranges are roughly: frontend hardcoding typically 1–3 business days (including regression and release window); backend dictionary or configuration typically 0.5–1 business day; the dictionary API approach is close to the latter for subsequent copy changes, but the first dictionary setup takes 2–5 extra days. When there are fewer than a dozen statuses and only one client is served, the difference between the first two approaches is not obvious. Once there are more than two or three clients, or copy must be customized per customer, the latter two are easier. There is no precise threshold here, and do not force a dictionary system onto a small tool with only two or three statuses just for consistency.

After codes, names, and semantics are separated, what should acceptance check?

The reason to split into three layers—code, name, and semantics—is that their change frequencies are very different: codes hardly change; names may change once a week; semantics follow business rules but rarely change. Putting things with different change frequencies into the same field inevitably makes them drag each other down.

1. Define codes first: use numbers or short strings, write them into the API documentation, and note which version added them and whether they are deprecated; add new values only and never reuse old ones. Deprecated codes are easy to miss: old data still contains them, and if the dictionary does not include them, the frontend renders them as blank.
2. Then define names: maintain copy separately in a dictionary table or language pack, with keys mapping one-to-one to codes, allowing one code to map to multiple languages or multiple sets of customer copy.
3. Then define semantics: list whether each code is terminal, whether it can be canceled, and whether it is included in statistics. This is the basis for button visibility and backend validation. Do not stop at copy mapping while leaving whether a button can be clicked in frontend if statements.

A practical acceptance bar has three checks: pick any historical order, and operations, customer service, and engineering all see the same copy; add a new status, and the frontend can display it normally without code changes; the status column in exported files is not purely numeric. If all three pass, the layering is basically in place, and what remains is just maintenance habit.

Where this applies and where it does not

This approach suits business systems with many statuses, many clients, and changing copy, such as orders, tickets, and approval flows—modules with clear state machines. Conversely, for an admin backend whose statuses are only Enabled/Disabled and never change over time, building a separate dictionary adds maintenance cost, and the investment is out of proportion to the benefit.

• Appropriate: more than 10 statuses, or new status values have been added within a year; the same backend serves more than two clients; there are customer-specific copy or multilingual requirements; exports, reports, and customer service back office all need to see statuses.
• Not necessary: a single-client internal tool with two or three statuses that do not change long term; the frontend is purely display and has no interaction branching on status; the team has no dedicated person to maintain the dictionary, so adding one means nobody updates it.

The boundary to make clear is this: layering codes and copy solves the problem of “one copy change triggering a chain of cascading edits”; it does not solve a messy state machine design. If the transition rules are not clear, layering will still be messy. In that case, sort out the transitions first, not the dictionary.

Frequently asked questions

If the backend returns Chinese copy directly, is the API no longer reusable?

No, but keep the code. A common practice is to return both status and statusText: use only status for logic and only statusText for display. Later, changing wording or adding multilingual support does not require changing the logic.

When an older frontend does not recognize a newly added status code, what is the usual fallback?

For unknown codes, display “Other” or the raw code; do not render a blank. Mark the added version in the documentation, and based on experience allow a transition period of one or two versions—typically a range of 1–2 release cycles.

In multilingual scenarios, should copy be stored in the database or in language packs?

Split by change frequency. Wording that operations will change goes in the dictionary table; fixed copy that ships with code goes in language packs. Both should use keys to associate with status codes. Do not use the Chinese text itself as the key, or translations will no longer match once changed.

If all status copy is handed to the backend, will the API become heavier?

One status field adds only a few dozen bytes; in most scenarios this is not a bottleneck. For high-traffic list pages, the API can return only codes and the frontend can look them up from a cached dictionary. Weigh the specific choice based on actual measurements.

If you currently have a system where status codes are scattered everywhere, start with the module that has more statuses. List three columns—code, copy, and semantics—first make exports and logs use unified copy, and then gradually consolidate hardcoded frontend mappings. Internal systems with few clients and stable statuses do not need forced refactoring; maintain them as they are and write the codes into the API documentation.