28 lines
1.7 KiB
Markdown
28 lines
1.7 KiB
Markdown
# Dictionary Localization Design
|
|
|
|
## Goal
|
|
|
|
Eliminate visible English enum/dictionary values from ERP business screens by translating status, type, source, role, warehouse, inventory, stocktake, and maintenance codes to Chinese at the display layer.
|
|
|
|
## Scope
|
|
|
|
- Keep database and API enum values unchanged, such as `ACTIVE`, `RAW`, `PURCHASE_IN`, and `STOCKTAKE_LOSS`.
|
|
- Centralize frontend translations in `frontend/src/utils/dictionaries.js`.
|
|
- Update pages that currently render enum values directly, especially inventory, equipment, employee, purchase, stocktake, and dashboard-style views.
|
|
- Unknown enum codes should not be shown raw in business UI. They should display a Chinese fallback while retaining the raw code in `title` where useful for diagnosis.
|
|
|
|
## Design
|
|
|
|
- Expand dictionary maps for common business enum groups: status, quality status, inventory transaction type, source document type, warehouse type, item type, purchase source, maintenance type, miniapp role, and stocktake row status.
|
|
- Add formatter functions such as `formatWarehouseTypeLabel`, `formatItemTypeLabel`, `formatPurchaseSourceTypeLabel`, `formatMaintenanceTypeLabel`, `formatMiniappRoleLabel`, and `formatStocktakeRowStatusLabel`.
|
|
- Replace direct template output like `{{ order.maintenance_type }}` and `{{ person.role_names.join(" / ") }}` where values may be English enum codes.
|
|
- Keep user-entered free text unchanged. Only known internal enum/code fields are localized.
|
|
|
|
## Verification
|
|
|
|
- Add a frontend static check to verify key enum maps and high-risk views use formatter functions.
|
|
- Run existing inventory static checks.
|
|
- Run frontend build.
|
|
- Run targeted backend compile or tests only if backend files are changed.
|
|
|