front end or back end의 api 오류 메시지 국제화?

front end or back end의 api 오류 메시지 국제화?

우리 팀은 현재 back end에서 제공하는 json api를 front end에서 사용하는 웹 프로젝트를 진행하고 있습니다.우리가 사용하는 기술은 Spring boot와 AngularJS입니다.api에는 다음과 같은 표준 오류 형식이 있습니다.

{
    "errorCode": "1111",
    "message": "Error occurred: some error message",
    "developerMessage": "message for developer"
}

오류 응답에는 필드 유효성 검사 오류 목록(선택 사항)도 포함될 수 있습니다.문제는 사용자 오류 메시지 번역을 어디서 해야 하느냐는 것입니다.백엔드가 요청의 로케일에 따라 이미 번역된 메시지를 반환해야 하는지 아니면 프론트엔드가 errorCode와 i18n 메커니즘을 사용해야 하는지.back end(Spring i18n 지원) 및 front end(angular-translate) 모두에 i18n 메커니즘이 있습니다.

가장 좋은 방법은 무엇입니까?각 접근 방식의 장단점은 무엇입니까?어떤 조언이든 감사히 받겠습니다.

저는 모든 것을 프론트엔드에 현지화해서 할 것입니다.백엔드는 ID를 전송하고 클라이언트 앱을 현지화된 텍스트로 변환합니다.

이점:

• 모든 것을 위한 단일 번역 소스 - 버튼, 툴팁 등 및 오류 메시지
• 포맷 지원 - 메시지의 일부 부분을 굵게/클릭 가능/등으로 만들어야 할 수도 있습니다. 이 부분은 프론트엔드에서 수행해야 합니다.
• 클라이언트 전용 유효성 검사 - 클라이언트 측 유효성 검사에 대한 오류 메시지는 동일한 오류에 대한 서버 측 메시지와 같아야 합니다(백엔드 현지화를 사용하면 일부 변환을 복제할 수 있음).
• 언어 불가지론적 테스트가 가능합니다.
• 언어에 구애받지 않는 백엔드가 가능합니다. 번역을 위해 백엔드에 로케일이 필요 없습니다.
• 클라이언트에 최대한 가까운 현지화를 권장하는 일반적인 권장 사항과 일치합니다.
• 앞으로 더 많은 백엔드 변환을 수행할 유인을 제거합니다.

단점:

• 새로운 오류에 대한 번역은 불가능합니다.클라이언트 앱이 번들로 제공된 후 백엔드에 오류가 정의된 경우 클라이언트는 일반 메시지를 표시해야 합니다(필요한 경우 새 오류 ID를 표시할 수 있음).
• 더 복잡한 번들링

여러 클라이언트 앱을 지원하려면 빌드에서 번들링 단계에서 resx 변환이 필요할 수 있습니다.클라이언트가 필요로 하는 형식으로 리소스 파일을 생성하므로 단일 번역 소스를 유지할 수 있습니다.

이렇게 해야 한다면 백엔드에 로케일이 있고 오류가 발생하기 때문에 백엔드에서 이 작업을 수행했을 것입니다. 따라서 백엔드에서 로컬화된 오류가 발생할 것으로 예상할 수 있습니다.또한 시스템의 연결이 해제되므로, 백엔드에 새로운 기능/변경이 수행되고 새로운 오류가 추가되는 경우 오류 때문에 프론트 엔드 피스를 해제할 필요가 없습니다.

또한, 일단 이것이 확장되고 여러 백엔드 시스템이 있으면 위의 접근 방식이 잘 작동합니다. 모든 오류 생성자가 각자의 위치를 관리해야 하기 때문입니다.

언급URL : https://stackoverflow.com/questions/30109787/internationalization-of-api-error-messages-on-front-end-or-back-end