[Feature] Implement Internationalization (i18n) for Backend Custom Error Messages

[VampireAchao]

Search before asking

• I had searched in the feature and found no similar feature requirement.

Description

Currently, our application's internationalization (i18n) is implemented only on the frontend, leading to a mismatch between the backend's custom error messages and the frontend's i18n messages. This can cause confusion for users who receive error messages that do not align with their selected language settings.

To address this, I propose that we implement a system where the backend sends error status codes rather than specific messages. The frontend would then be responsible for interpreting these status codes and displaying the corresponding i18n message. This would allow for a more consistent user experience and ensure that error messages are presented in the user's selected language.

Usage Scenario

Imagine a user who has set their language preference to Spanish. When an error occurs, the backend currently sends an error message in English. With the proposed system, the backend would send an error code, and the frontend would display the corresponding error message in Spanish, adhering to the user's language preference.

Related issues

No related issues found.

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[VampireAchao]

@wangsizhu0504 @RocMarshal ，Can you help me finish this?

[wangsizhu0504]

@wangsizhu0504 @RocMarshal ，Can you help me finish this?

ok, cool

[VampireAchao]

That sounds like a reasonable approach, but I believe it would be better to have all the i18n localization files placed on the frontend. This way, the frontend can handle all the translations internally and keep the display logic separate from the backend services. It also simplifies the backend since it only needs to provide error codes, and we won't need to maintain a separate i18n querying API. Let me know your thoughts on this. Kriszu ***@***.***> 于2024年1月29日周一 11:42写道：

…

@wangsizhu0504 <https://github.com/wangsizhu0504> @RocMarshal <https://github.com/RocMarshal> ，Can you help me finish this? ok, cool, We can provide an api interface to query i18n, and the other interfaces will return errorCode instead of the original error message.what do you think — Reply to this email directly, view it on GitHub <#3520 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMSNTBGGWGQT77PHTA6EFEDYQ4LDLAVCNFSM6AAAAABCOXCTH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTHEYDSNZXGE> . You are receiving this because you were assigned.Message ID: ***@***.***>

[wangsizhu0504]

That sounds like a reasonable approach, but I believe it would be better to have all the i18n localization files placed on the frontend. This way, the frontend can handle all the translations internally and keep the display logic separate from the backend services. It also simplifies the backend since it only needs to provide error codes, and we won't need to maintain a separate i18n querying API. Let me know your thoughts on this. Kriszu @.> 于2024年1月29日周一 11:42写道：
…
@wangsizhu0504 https://github.com/wangsizhu0504 @RocMarshal https://github.com/RocMarshal ，Can you help me finish this? ok, cool, We can provide an api interface to query i18n, and the other interfaces will return errorCode instead of the original error message.what do you think — Reply to this email directly, view it on GitHub <#3520 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMSNTBGGWGQT77PHTA6EFEDYQ4LDLAVCNFSM6AAAAABCOXCTH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTHEYDSNZXGE . You are receiving this because you were assigned.Message ID: @.>

You can put the internationalization identifier chosen by the front-end user into the header of the api interface, and the back-end will parse the internationalization field in the header and return an error message dynamically.

headers:{
 language: ‘zh_cn’ 
}

[VampireAchao]

I agree

[wolfboys]

Thanks for your feedback. We are closing this issue because it is outdated.