Trongate PHP Framework Docs
Introduction
Basic Concepts
Understanding Routing
Intercepting Requests
Module Fundamentals
Database Operations
Templates
Helpers
Form Handling
Form Validation
Working With Files
Image Manipulation
Working With Dates & Times
Language Control
Authorization & Authentication
Tips And Best Practices

Multilingual Form Validation

Trongate makes it easy to support form validation in multiple languages. The framework stores error messages in language-specific files and you can easily switch between languages on demand.

How It Works

Trongate's validation system loads error messages from language files based on the current language setting. When a validation error occurs, the framework displays the translated message for the selected language.

Key Concept: Language files are separate from your application code. You can add support for new languages simply by creating new language files - no changes to your validation rules are needed.

Language File Structure

Language files are stored in the following directory structure:

Each language uses a two-character ISO language code:

  • en - English
  • fr - French
  • es - Spanish
  • de - German
  • it - Italian
  • pt - Portuguese
  • ja - Japanese
  • zh - Chinese

Language File Format

Each language file contains a PHP array of error messages. Keys match the validation rule names, and values are the translated error messages:

Placeholder Substitution

Error messages use two types of placeholders that are automatically replaced:

Placeholder Replaced With Example
[label] The field label from set_rules() "The email address field is required."
[param] Rule parameter (e.g., length, value) "The username field must be at least 3 characters long."

Setting the Validation Language

Use to switch the validation language:

When validation fails, error messages will be displayed in French.

Pro Tip: Language preference is stored in the session ($_SESSION['validation_lang']), so it persists across requests. Once you set a language, it remains active until you change it or reset it.

Resetting to Default Language

Use to revert validation messages to the default language (English):

This method removes the language preference from the session, allowing the framework to use the default language.

Real-World Example: Multi-Language Site

Here's a complete example of a multilingual registration form:

In the view file, pass the language as a hidden field so it persists through form submission:

Adding a New Language

To add support for a new language, follow these steps:

Step 1: Create the Language Directory

Create a new directory in the validation module:

Step 2: Create the Language File

Create validation_errors.php in that directory with translated error messages:

Step 3: Use the New Language

Now you can use the new language in your validation:

Important: Ensure all error message keys in your new language file match the keys in the default English file. If a key is missing, the framework will display "The [label] field failed validation."

Language Fallback Behavior

The validation system handles missing language files gracefully:

  1. First, it looks for a language file matching the requested language code (e.g., fr/validation_errors.php)
  2. If that file doesn't exist, it falls back to the default English language file (en/validation_errors.php)
  3. If a specific error message key is missing from a language file, it displays a generic error message

Best Practice: Always keep your English language file complete with all possible error messages. This ensures a graceful fallback if a translated language file is incomplete or missing.

Complete List of Language Strings

Here are all the validation error message keys you should include in your language files:

Standard Validation Rules

File Validation Rules

Image Validation Rules

Upload and Security Rules

Best Practices

  1. Validate the language code: Always whitelist acceptable language codes before setting a language. This prevents invalid language codes from being used.
  2. Pass language as a hidden field: When using forms, include the language as a hidden field so it persists through validation errors.
  3. Use ISO 639-1 codes: Stick to two-character language codes (en, fr, es, etc.) for consistency and compatibility.
  4. Keep language files in sync: When you add a new validation rule, update all language files with translations for that rule's error message.
  5. Create a language constant (optional): Define a constant like DEFAULT_VALIDATION_LANG for your application's default language.
  6. Store user language preference: Save the user's language preference in their account or a cookie for personalization.
  7. Use natural field labels: Use lowercase, natural language for field labels so error messages read naturally in all languages: "email address" not "email_address".
  8. Test all languages: Verify that error messages display correctly in each supported language before deploying.
  9. Include comprehensive translations: Don't leave error messages in English if you're supporting other languages - translate all messages for a professional user experience.

Custom Error Messages in Different Languages

When using custom validation callbacks, define error messages in your language files and simply return the key - the framework will handle the rest.

For example, in a language file such as fr/validation_errors.php you could add:

Then, your validation callback could be written like so:

In the scenario described above, Trongate will:

  1. Get the currently loaded language.
  2. Attempt to read a language file associated with the currently loaded language.
  3. Attempt to find and return an error message from the language file whose key matches the returned value from the form validation callback.

If a matching error message cannot be found, the returned string will be rendered in the same manner as would happen with a normal custom form validation callback.

Configuration Constants

If you are building a website that does not have English as the default language, you can define a default validation language in your application configuration:

The framework will use this default language if no language has been explicitly set and no language preference exists in the session.

Session Behavior

Language preference is stored in the session ($_SESSION['validation_lang']):

  • When you call set_language('fr'), it sets $_SESSION['validation_lang'] = 'fr'
  • This preference persists for the entire session (or until changed)
  • When you call reset_language(), it unsets the session variable
  • When validating, the framework checks the session variable for the current language setting

Session Security: Since language preference is stored in the user's session, it's safe from tampering. However, you should still validate language codes on the server side before using them.

Common Scenarios

Scenario 1: User Selects Language from Dropdown

Scenario 2: Load User's Preferred Language Automatically

Scenario 3: Multilingual API Response