public class InputFieldError {

    private String field;
    private String message;

    // getter and setter
}

8. Validation Message Types

Let’s initiate an update request to the REST service /user with the following request body:

{
    "email": ""
}

As a reminder, the User object must contain a non-empty email. Therefore, we expect that this request triggers a validation error.

8.1. Standard Message

We’ll see the following typical response with an English message if we don’t provide any language information in the request:

{
    "fieldErrors": [
        {
            "field": "email",
            "message": "must not be empty"
        }
    ]
}

Now, let’s initiate another request with the following accept-language HTTP header:

accept-lanaguage: zh-tw

The service interprets that we’d like to use Chinese. It retrieves the message from the corresponding resource bundle. We’ll see the following response that includes the Chinese validation message:

{
    "fieldErrors": [
        {
            "field": "email",
            "message": "不得是空的"
        }
    ]
}

These are standard validation messages provided by the Java Bean Validation. We can find an exhaustive list of messages from the Hibernate validator, which serves as the default validation implementation.

However, the messages we saw don’t look nice. We probably want to change the validation message to provide more clarity. Let’s take a move to modify the standardized messages.

8.2. Overridden Message

We can override default messages defined in Java Bean Validation implementation. All we need to do is define a property file that has the basename ValidationMessages.properties:

jakarta.validation.constraints.NotEmpty.message=The field cannot be empty

With the same basename, we’ll create another property file ValidationMessages_zh.properties for Chinese as well:

jakarta.validation.constraints.NotEmpty.message=本欄不能留空

Upon calling the same service again, the response message is replaced by the one we defined:

{
    "fieldErrors": [
        {
            "field": "email",
            "message": "The field cannot be empty"
        }
    ]
}

However, the validation message still looks generic despite overriding the message. The message itself doesn’t reveal which field goes wrong. Let’s proceed to include the field name in the error message.

8.3. Customized Message

In this scenario, we’ll dive into customizing validation messages. We defined all customized messages in the CustomValidationMessages resource bundle earlier.

Then, we’ll apply the new message {validation.email.notEmpty} to the validation annotation to the User DTO. The curly bracket indicates the message is a property key linking it to the corresponding message within the resource bundle:

public class User {
    @NotEmpty(message = "{validation.email.notEmpty}")
    private String email;

    // getter and setter
}

We’ll see the following message when we initiate a request to the service:

{
    "fieldErrors": [
        {
            "field": "email",
            "message": "Email cannot be empty"
        }
    ]
}

8.4. Interpolated Message

We’ve improved the message significantly by including the field name in the message. However, a potential challenge arises when dealing with many fields. Imagine a scenario where we have 30 fields, and each field requires three different types of validations. This would result in 90 validation messages within each localized resource bundle.

We could utilize message interpolation to address this issue. Interpolated messages operate on placeholders that are replaced dynamically with actual values before presenting them to users. In the scenario that we mentioned before, this approach reduces the number of validation messages to 33, containing 30 field names and three unique validation messages.

@Documented
@Target({METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER, TYPE_USE})
@Retention(RUNTIME)
@Constraint(validatedBy = {FieldNotEmptyValidator.class})
public @interface FieldNotEmpty {
    String message() default "{validation.notEmpty}";
    String field() default "Field";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
}

@FieldNotEmpty operates as a constraint and uses FieldNotEmptyValidator as the validator implementation:

public class FieldNotEmptyValidator implements ConstraintValidator<FieldNotEmpty, Object> {
    private String message;
    private String field;

    @Override
    public boolean isValid(Object value, ConstraintValidatorContext context) {
        return (value != null && !value.toString().trim().isEmpty());
    }
}

The isValid(…) method performs the validation logic and simply determines whether the value is not empty. If the value is empty, it retrieves localized messages for the attribute field and message corresponding to the current locale from the request context. The attribute message is interpolated to form a complete message.

Upon execution, we observe the following result:

{
    "fieldErrors": [
        {
            "field": "email",
            "message": "{field.personalEmail} cannot be empty"
        }
    ]
}

The message attribute and its corresponding placeholder are successfully retrieved. However, we’re expecting {field.personalEmail} to be replaced by the actual value.

8.5. Custom MessageInterpolator

public class RecursiveLocaleContextMessageInterpolator extends AbstractMessageInterpolator {
    private static final Pattern PATTERN_PLACEHOLDER = Pattern.compile("\\{([^}]+)\\}");
    private final MessageInterpolator interpolator;

    public RecursiveLocaleContextMessageInterpolator(MessageSourceResourceBundleLocator interpolator) {
        this.interpolator = interpolator;
    }

    @Override
    public String interpolate(MessageInterpolator.Context context, Locale locale, String message) {
        int level = 0;
        while (containsPlaceholder(message) && (level++ < 2)) {
            message = this.interpolator.interpolate(message, context, locale);
        }
        return message;
    }

    private boolean containsPlaceholder(String code) {
        Matcher matcher = PATTERN_PLACEHOLDER.matcher(code);
        return matcher.find();
    }
}

RecursiveLocaleContextMessageInterpolator is simply a decorator. It reapplies interpolation with the wrapped MessageInterpolator when it detects the message contains any curly bracket placeholder.

We’ve completed the implementation, and it’s time for us to configure Spring Boot to incorporate it. We’ll add two provider methods to MessageConfig:

@Bean
public MessageInterpolator getMessageInterpolator(MessageSource messageSource) {
    MessageSourceResourceBundleLocator resourceBundleLocator = new MessageSourceResourceBundleLocator(messageSource);
    ResourceBundleMessageInterpolator messageInterpolator = new ResourceBundleMessageInterpolator(resourceBundleLocator);
    return new RecursiveLocaleContextMessageInterpolator(messageInterpolator);
}

@Bean
public LocalValidatorFactoryBean getValidator(MessageInterpolator messageInterpolator) {
    LocalValidatorFactoryBean bean = new LocalValidatorFactoryBean();
    bean.setMessageInterpolator(messageInterpolator);
    return bean;
}

The getMessageInterpolator(…) method returns our own implementation. This implementation wraps ResourceBundleMessageInterpolator, which is the default MessageInterpolator in Spring Boot. The getValidator() is for registering the validator to use our customized MessageInterpolator within our web service.

Now, we’re all set, and let’s test it once more. We’ll have the following complete interpolated message with the placeholder replaced by the localized message as well:

{
    "fieldErrors": [
        {
            "field": "email",
            "message": "Personal Email cannot be empty"
        }
    ]
}

9. 結論

在本文中，我們深入探討了在多語言應用程序中交付本地化消息的過程。

我們首先制定了完整實施的關鍵步驟的大綱，從使用屬性文件作為消息存儲庫並使用 UTF-8 進行編碼開始。Spring Boot 集成簡化了基於客户端區域設置的首選項的消息檢索。Java Bean Validation，以及自定義註釋和消息插值，允許針對特定語言定製錯誤響應。

通過結合使用這些技術，我們能夠為 REST Web 服務提供本地化驗證響應。