Skip to main content

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.

Dragon Guard WMS Web is a multilingual application targeting three locales: Spanish (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:
src/app/core/i18n/translation.service.ts
There is no separate JSON or XLIFF file per locale. Translations are defined as typed objects inside 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 standalone t pipe wherever text appears in an Angular template. The pipe resolves the current locale automatically through TranslationService.
<!-- Labels and headings -->
<span>{{ 'common.save' | t }}</span>
<h2>{{ 'receipts.title' | t }}</h2>

<!-- Input placeholder -->
<input [placeholder]="'common.search' | t" />

<!-- PrimeNG tooltip -->
<button
  pButton
  [pTooltip]="'common.back' | t"
  icon="pi pi-arrow-left"
></button>

<!-- PrimeNG dialog header -->
<p-dialog [header]="'shipments.confirmTitle' | t">
  ...
</p-dialog>

<!-- Toast (called from TypeScript — see below) -->
Never write literal strings directly in templates. The following examples are prohibited:
<!-- ❌ Wrong — hardcoded label -->
<span>Save</span>

<!-- ❌ Wrong — hardcoded placeholder -->
<input placeholder="Search..." />

<!-- ❌ Wrong — hardcoded tooltip -->
<button [pTooltip]="'Go back'"></button>
Every user-facing string — including those that “will never change” — must go through the t pipe or TranslationService.

TypeScript Usage

Inject TranslationService into services, components, or resolvers whenever you need a translated string in TypeScript code (toasts, dynamic messages, log-friendly labels).
import { TranslationService } from 'src/app/core/i18n/translation.service';

@Component({ ... })
export class PackagesComponent {

  constructor(private translations: TranslationService) {}

  showError() {
    // Simple key lookup
    const message = this.translations.translate('packages.failed');
    this.messageService.add({ severity: 'error', summary: message });
  }

  showApplied(name: string) {
    // Dynamic text with a placeholder value
    const detail = this.translations.format('packages.appliedDetail', { name });
    this.messageService.add({ severity: 'success', detail });
  }
}
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

1

Open translation.service.ts

Navigate to src/app/core/i18n/translation.service.ts. Locate the dictionary objects for es, en, and pt-BR.
2

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.*).
// Inside the es dictionary
'inventory.lowStockWarning': 'Stock por debajo del mínimo',

// Inside the en dictionary
'inventory.lowStockWarning': 'Stock below minimum threshold',

// Inside the pt-BR dictionary
'inventory.lowStockWarning': 'Estoque abaixo do mínimo',
3

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.
4

Verify with language switching

Switch the UI to each of the three locales and confirm the key resolves correctly in every context where it appears.

Dynamic Text with format()

When a translated string must embed a runtime value — a name, a count, a code — use translations.format(key, values) instead of string interpolation.
// Dictionary entry (in all three locales)
// 'packages.appliedDetail': 'Package {{name}} applied successfully'

// TypeScript call
const detail = this.translations.format('packages.appliedDetail', { name: pkg.code });
<!-- If you need dynamic text directly in a template, bind to a computed property -->
<span>{{ appliedMessage }}</span>
Define the placeholder tokens in your dictionary values using double-brace syntax: {{variableName}}. Keep placeholder names consistent across all three locale dictionaries for the same key.

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.
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.
  • 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 height or min-height on the chart card in CSS or component styles.
  • Do not pad the chart card with extra whitespace to make it “look fuller”.
Do not set a large fixed height on the dashboard chart container. Fixed oversized chart cards produce large empty areas for low-volume tenants and communicate a broken or unfinished UI. Always use a proportional, data-driven height approach.

QA Verification Checklist

Before delivering any screen that contains user-facing text, verify language switching across every surface.
1

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.
2

Menu and sidebar

After login, confirm all sidebar navigation entries and section headers display in the active locale.
3

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.
4

List pages

Verify column headers, filter placeholders, pagination labels, empty-state messages, and action button labels on all list views.
5

Detail and form pages

Verify field labels, section headings, required-field indicators, save/cancel button labels, and form validation messages.
6

Tooltips

Hover over every pTooltip-enabled control on the changed screen and confirm the tooltip text is translated.
7

Dialogs

Open every confirmation, detail, and form dialog on the changed screen. Verify the header, body text, and action buttons are translated.
8

Toasts

Trigger success, error, and warning toasts on the changed screen. Confirm summary and detail text are translated and no raw key names (e.g., packages.failed) are visible.

Build docs developers (and LLMs) love