Error message

Learn how to configure validation error messages with automatic i18n translation, manual field-level messages, or hardcoded custom messages in your DTOs using the `@tradinos/cms-backend-entity`

Validation Messages

A comprehensive guide for handling validation error messages in DTOs with i18n support using the @tradinos/cms-backend-entity package.

Overview

This guide covers different approaches to configure validation error messages in your NestJS application. You can configure validation messages at the global level (metadata) or at the field level (DTOs), with support for automatic translation, manual i18n, or hardcoded messages.

---

Global i18n Validation (Recommended)

Configuration

To enable automatic translation for all validation messages across your application, configure the metadata option in EntityModule.register:

import { i18nValidatorBasedValidationErrorMessage } from '@tradinos/cms-backend-entity';

EntityModule.register({
  metadata: {
    authorization: true,
    validationErrorMessage: i18nValidatorBasedValidationErrorMessage(),
  },
});

How it works

• Source: Imported from @tradinos/cms-backend-entity

• Translation: Uses the i18n configuration defined in app.module.ts

• Language Support: Automatically translates based on the request language (Arabic/English)

• Translation Files: Works with src/i18n/en/validation.json and src/i18n/ar/validation.json

Benefits

• ✅ Automatically translates all validation messages

• ✅ No need to specify message in each decorator

• ✅ Consistent translation across all entities

• ✅ Easy to maintain and update

---

Field-Level Validation in DTOs

You have three options for field-level validation messages:

Option A: i18n Translated Messages

Use i18nValidationMessage for field-specific translated messages:

import { i18nValidationMessage } from 'nestjs-i18n';

@IsEmail({}, {
  message: i18nValidationMessage('validation.INVALID_EMAIL'),
})
email: string;

Example from codebase:

// src/domain/authentication/dtos/sign-in.dto.ts
@IsEmail({}, {
  message: i18nValidationMessage('validation.INVALID_EMAIL'),
})
email: string;

How it works:

• Import from nestjs-i18n

• Looks up translations in src/i18n/en/validation.json and src/i18n/ar/validation.json

• Translates based on current request language

---

Option B: Hardcoded Custom Messages

Use @ValidationErrorMessage decorator for field-specific hardcoded messages:

import { ValidationErrorMessage } from '@tradinos/cms-backend-entity';

@ValidationErrorMessage({
  "max-length": "The value must be less than or equal to 255 characters"
})
@FieldLabel<any, I18nTranslations>({ label: "labels.project.createdAt" })
createdAt!: Date;

How it works:

• Import from @tradinos/cms-backend-entity

• Hardcoded messages (no translation)

• Specify message for each validation rule

Use cases:

• ✅ Custom hardcoded message

• ❌ No translation (same message in all languages)

• ✅ Useful for static messages that don't need translation

---

Option C: Default class-validator Messages

Use class-validator decorators without specifying a message:

import { IsString, IsNotEmpty, MaxLength } from 'class-validator';

@IsString()
@IsNotEmpty()
@MaxLength(255)
name: string;

Example from codebase:

// src/domain/user/dtos/user.dto.ts
@IsString()
@ApiProperty({ type: String })
@MinLength(1)
@MaxLength(1024)
@IsNotEmpty()
name!: string;

How it works:

• Uses default class-validator messages (English only)

• Examples: "must be a string", "should not be empty"

• Inherits from metadata if i18nValidatorBasedValidationErrorMessage() is configured

---

Summary Table

Scenario	In metadata	In DTO	Translation
Auto-translated	i18nValidatorBasedValidationErrorMessage()	No message (inherits from metadata)	✅ Yes
Manual i18n	i18nValidatorBasedValidationErrorMessage()	i18nValidationMessage('validation.XXX')	✅ Yes
Hardcoded custom	i18nValidatorBasedValidationErrorMessage()	@ValidationErrorMessage({ "max-length": "..." })	❌ No
Default	No validationErrorMessage	No message	❌ No

---

Complete Example

Configuration in app.module.ts

EntityModule.register({
  metadata: {
    authorization: true,
    validationErrorMessage: i18nValidatorBasedValidationErrorMessage() // ✅
  }
})

Field-level examples

Using i18n in DTO:

// src/domain/authentication/dtos/sign-in.dto.ts
@IsEmail({}, {
  message: i18nValidationMessage('validation.INVALID_EMAIL'), // ✅
})
email: string;

Inheriting from metadata:

// src/domain/user/dtos/user.dto.ts
@IsString() // ✅ No message = inherits from metadata
@IsNotEmpty()
name!: string;

Result:

• ✅ Messages automatically translated from metadata

• ✅ Some fields use i18nValidationMessage directly

• ✅ Some fields without message (inherit from metadata)

• ✅ Can use @ValidationErrorMessage for hardcoded custom messages

---

i18n Translation Files

English (src/i18n/en/validation.json)

{
  "INVALID_EMAIL": "Invalid Email",
  "FIELD_REQUIRED": "This field is required",
  "MUST_BE_STRING": "Must be a string",
  "MAX_LENGTH_255": "Maximum length is 255 characters"
}

Arabic (src/i18n/ar/validation.json)

{
  "INVALID_EMAIL": "إيميل غير صالح",
  "FIELD_REQUIRED": "هذا الحقل مطلوب",
  "MUST_BE_STRING": "يجب أن يكون نص",
  "MAX_LENGTH_255": "الحد الأقصى للطول 255 حرف"
}

---

Best Practices

1. Use global i18n (i18nValidatorBasedValidationErrorMessage) for consistent translation across all entities

2. Use field-level i18n (i18nValidationMessage) when you need specific translations for certain fields

3. Use hardcoded messages (@ValidationErrorMessage) only for static messages that don't need translation

4. Avoid default messages when building multilingual applications

---

Related Topics

• Entity Options - Learn about other EntityModule configuration options

• Localization - Understand how localization works in the Entity module

• Error Handling - See how validation errors are handled