Internationalization

VEF includes an application i18n layer for framework messages, validation output, and error responses.

Supported Languages

The framework currently embeds:

Language code
zh-CN
en

Default application language:

Setting	Value
default language	zh-CN

Public API

The public i18n API is intentionally small:

API	Purpose
i18n.T(messageID, data...)	translate with graceful fallback
i18n.Te(messageID, data...)	translate with explicit error reporting
i18n.SetLanguage(code)	switch global language at runtime
i18n.GetSupportedLanguages()	list supported language codes
i18n.IsLanguageSupported(code)	check whether a language is supported
i18n.New(config)	create a dedicated translator instance

Most application code only needs i18n.T(...).

Translator Model

The public abstraction is i18n.Translator:

Method	Purpose
T(messageID, data...)	translate and fall back to the message ID
Te(messageID, data...)	translate and return explicit errors

Configuration Model

The constructor config type is:

Type	Purpose
i18n.Config	supplies embedded locale files through Locales embed.FS

Language Selection

At startup, the framework chooses the language in this order:

Priority	Source
1	VEF_I18N_LANGUAGE
2	framework default language (zh-CN)

i18n.SetLanguage(...) can switch the process-level translator later, which is especially useful in tests.

Where i18n Appears Automatically

Even if you never call the i18n package directly, it already affects:

Area	Effect
result.Ok(...) and result.Err(...)	localized success and error messages
validation output	translated field labels and custom rule messages
built-in resource errors	localized framework responses

So i18n in VEF is not only for UI text. It is part of the backend response contract.

Minimal Example

package userinfo

import (
  "github.com/gofiber/fiber/v3"

  "github.com/coldsmirk/vef-framework-go/i18n"
  "github.com/coldsmirk/vef-framework-go/result"
)

func UserInfoNotImplemented(ctx fiber.Ctx) error {
  return result.ErrNotImplemented(
    i18n.T(result.ErrMessageUserInfoLoaderNotImplemented),
  )
}

Validation Integration

Validation integrates with i18n in two important ways:

Mechanism	Effect
label_i18n	field labels are translated
custom validator rule translations	framework custom rules return localized messages

That makes request validation output much more readable in real applications.

Practical Advice

• use i18n.T(...) for ordinary application code
• use i18n.Te(...) only when you need explicit translation error handling
• treat i18n.SetLanguage(...) as mainly a testing or controlled runtime helper
• remember that result messages are already localized, so backend responses are part of your i18n surface

Next Step

Read Validation to see how translated field labels surface in request errors.