Dragon Guard WMS Web is a multilingual application targeting three locales: Spanish (Documentation Index
Fetch the complete documentation index at: https://mintlify.com/CodexaCP/DG_WEB/llms.txt
Use this file to discover all available pages before exploring further.
es), English (en), and Brazilian Portuguese (pt-BR). Every label, placeholder, tooltip, toast summary, dialog header, and menu entry visible to an end user must be served through TranslationService or the standalone t pipe. Hardcoded strings in templates or TypeScript are never acceptable — they break language switching and make QA verification impossible.
Supported Languages
Spanish
es — primary language for Dragon Guard WMS deployments in Latin America. All new keys must include a Spanish value.English
en — secondary language used by administrators and integration teams. All new keys must include an English value.Brazilian Portuguese
pt-BR — third supported locale for Brazilian operations. All new keys must include a pt-BR value.Translation File Location
All three language dictionaries live in a single file:translation.service.ts. When you add a new key, add it to all three dictionaries in the same commit.
Keeping all dictionaries in one file makes it impossible to ship a key in one language while forgetting another. Always add
es, en, and pt-BR values together.Template Usage
Use the standalonet pipe wherever text appears in an Angular template. The pipe resolves the current locale automatically through TranslationService.
TypeScript Usage
InjectTranslationService into services, components, or resolvers whenever you need a translated string in TypeScript code (toasts, dynamic messages, log-friendly labels).
Use
translate(key) for static keys. Use format(key, values) for any string that embeds a runtime value. Never build dynamic strings with string concatenation or template literals containing hardcoded words.Adding a New Translation Key
Open translation.service.ts
Navigate to
src/app/core/i18n/translation.service.ts. Locate the dictionary objects for es, en, and pt-BR.Add the key to all three dictionaries
Add your new key-value pair to every locale in the same edit. Group related keys under the same namespace prefix (e.g.,
receipts.*, shipments.*, common.*).Use the key in templates and TypeScript
Reference the new key with the
t pipe in templates or translate() / format() in TypeScript. Do not ship the key unused.Dynamic Text with format()
When a translated string must embed a runtime value — a name, a count, a code — usetranslations.format(key, values) instead of string interpolation.
Dashboard Chart Rules
The Dragon Guard WMS Web dashboard uses a single line chart that compares selected WMS entities over time.Line Chart Only
The dashboard chart must always be a line chart. Do not replace it with a bar chart, pie chart, or any other visualization type. Adding a separate widget with a different chart type is permitted.
Temporal Ranges
The chart supports four fixed time ranges: 1d, 30d, 90d, and 365d. Do not add, remove, or rename these range options.
Required Date Fields
Any new dataset added to the chart must provide one of the following resolvable date fields:
createdAt, systemCreatedAt, receiptDate, shipmentDate, documentDate, or postingDate.No Demo Chart Data
The chart must display live WMS data. Demo or mock datasets must never appear in production routes.
Chart Container Height Rules
The chart container height is intentionally proportional to its content — it is not a fixed oversized card.Why proportional height?
Why proportional height?
Sparse tenants with low transaction volumes would see a large, mostly empty chart card if the height were fixed. That feels broken and wastes screen space. The container grows only when the maximum Y-axis value genuinely requires more vertical room.
What this means in practice
What this means in practice
- Keep the base chart height compact for low-volume datasets.
- Allow the height to grow dynamically when high Y-axis values require additional vertical resolution.
- Do not set a large fixed
heightormin-heighton the chart card in CSS or component styles. - Do not pad the chart card with extra whitespace to make it “look fuller”.
QA Verification Checklist
Before delivering any screen that contains user-facing text, verify language switching across every surface.Login screen
Switch locale before logging in. Confirm all labels, input placeholders, button text, and validation messages on the login screen render in the selected language.
Menu and sidebar
After login, confirm all sidebar navigation entries and section headers display in the active locale.
Dashboard
Confirm the dashboard heading, chart labels, range selector options, and any card titles are translated. No hardcoded English (or Spanish) strings should appear when a different locale is active.
List pages
Verify column headers, filter placeholders, pagination labels, empty-state messages, and action button labels on all list views.
Detail and form pages
Verify field labels, section headings, required-field indicators, save/cancel button labels, and form validation messages.
Tooltips
Hover over every
pTooltip-enabled control on the changed screen and confirm the tooltip text is translated.Dialogs
Open every confirmation, detail, and form dialog on the changed screen. Verify the header, body text, and action buttons are translated.