여러 (사내) 프로젝트를위한 문자열 번역 데이터베이스 구축

우리 회사에는 기존 번역 ms-sql 테이블이 다음과 같은 문자열을 저장합니다.

Id |     Key     | Language | Value 
 1 | hello-world |  nl-BE   | Hallo Wereld
 2 | hello-world |  en-GB   | Hello World

시스템에는 3 개의 언어가 있으며 앞으로 최대 10 개 언어로 성장할 것으로 예상됩니다.

이 테이블은 번역 데이터베이스에 대한 데이터베이스 연결을 열고 번역을 캐시하는 매우 다른 여러 프로젝트 (약 60 개 프로젝트, 주로 웹 사이트 / 웹 응용 프로그램 및 일부 웹 서비스)에서 읽습니다.

프론트 엔드 개발자들의 의견은 UIto가 번역의 가장 큰 단점은 어떤 프로젝트가 어떤 문자열을 사용하는지 알 수 없다는 것입니다.

그들은 때로는 7 개의 프로젝트를 중단하고 있다는 것을 모르고 문자열을 수정합니다.

이제 그들은 같은 것을 입력 this.Translate("Hello World")하면 시스템이 나머지를 처리합니다.

나는 물론 그들을 강요 할 수는 this.Translate("Hello World","AwesomeApplication1")있지만 많은 프로젝트에서 상당히 많은 리팩토링이 필요할 것 같습니다.

이 솔루션을 어떻게 제공 하시겠습니까? 개발자로서 번역에 "프로젝트 이름"을 어떻게 제공 하시겠습니까? 이것을 데이터베이스에 어떻게 저장 하시겠습니까?

중요 사항 : 번역 재사용은 중앙 집중식 데이터베이스의 요점이므로 번역을 통해 하나의 프로젝트로 범위를 지정하십시오.

1|hello-world|nl-BE|Hallo Wereld|MyAwesomeApplicatoin1
5|hello-world|nl-BE|Hallo Wereld!|MyAwesomeApplicatoin2

실제로 원하는 옵션이 아닙니다.

나는 다음과 같은 것을 선호한다 :

1|hello-world|nl-BE|Hallo Wereld|MyAwesomeApplicatoin1,MyAwesomeApplicatoin2

또는 테이블에 이름을 넣는 것과 동등한 외래 키.

최신 정보

데이터베이스 정규화에 대한 조언을 바탕으로 지금까지 다음과 같은 것을 생각해 냈습니다.

//this allows me to distinquish if translations where added by developer or by translator

UPDATE2 : 텍스트 대신 edmx를 추가했습니다. 사람들이 관심이 있다면 WCF 프로젝트를 github 할 수 있다면이 개념을 포장하여 다른 사람들이 테스트하고 사용할 수 있습니다.

예비 참고 사항 # 1 : 현재 번역이 어떻게 유지되고 있는지 알려주지 않습니다.

예비 참고 사항 # 2 : 데이터베이스가 정규화되지 않았습니다. 어떤 솔루션을 취하 든 먼저 데이터베이스를 표준화하십시오 . 지금 그렇게하지 않으면 나중에 끔찍한 유지 보수 문제가 발생합니다

이것이 내가 할 일입니다.

1. 서버에 프로그램 ID를 다시 전달하도록 변환 호출을 다시 작성하십시오.

2. 백엔드 번역기는 아직 존재하지 않는 경우 데이터베이스 테이블에 문자열을 넣고 프로그램 ID로 태그를 지정합니다.

3. 문자열이 이미 존재하는 경우 프로그램 ID가 문자열이 작성된 원래 프로그램 ID와 일치하는 경우에만 업데이트됩니다. 그렇지 않은 경우 충돌 알림을 반환하십시오.

변형 :

• 프로그램 ID 대신 '개발자 ID / 번역기 ID'를 사용할 수 있습니다. 외국어를 아는 사람들과 그들이 알고 있다고 생각하는 사람들이 있기 때문에 더 잘 생각합니다. 첫 번째 그룹 만 수정 권한이 있습니다.

• 문자열을 사용하는 모든 프로그램의 ID를 DB에 저장하여 어떤 프로그램이 충돌하는지 알 수 있습니다.

• 이 '소유권'을 각 개별 언어로 확장 할 수 있습니다. 한 사람은 영어를, 다른 사람은 네덜란드어를 할 수 있습니다.

• 데이터베이스가 정규화되면 "프로그램 A는 언어 1,2,3에 있고 B는 3과 5에 있습니다"와 같은 빌드 복잡성을 추가합니다.

또한 누락 된 번역 등을 보여주는 별도의 '번역 유지 관리'프로그램을 작성하는 것이 좋습니다. 2 단계 인증으로 한 번 수행했습니다. 각 번역은 두 번째 사람 (보통 원어민)이 심사해야합니다.

그들이 'this'를 참조하고 있기 때문에 (예를 들어 생성자를 통해) 프로젝트 이름을 'this'에 한 번 할당 할 수 있고 변환 함수에 대한 인터페이스는 코더에 대해 변경되지 않습니다. 후드 아래에서 프로젝트 이름을 데이터베이스 쿼리에 추가합니다. 또는 '이것'을 통해 프로젝트 이름을 스스로 알 수 있습니다. 그것은 당신이 수업을 어떻게 구성했는지에 달려 있습니다.

저장을 위해 다음과 같은 작업을 수행 할 수 있습니다.

1 ! hello-world ! nl-EN ! Hello World  ! *
2 ! hello-world ! nl-EN ! Howdy, World ! CowboyApp
3 ! hello-world ! nl-EN ! Arrgh        ! PirateApp

와일드 카드를 사용하여 모든 앱에 일반 번역을 적용하고 특정 앱의 번역을 재정의하려는 경우 특정 앱 이름을 적용하십시오. 이렇게하면 중복이 최소화됩니다.

어떤 프로그램이 어떤 번역을 사용하고 있는지 알기 위해이 정보를 알고 있습니다. 해당 정보를 직접 조사하고 싶지 않으면 번역 요청을 기록 할 수 있습니다.

모든 프로젝트가 C #으로 작성되고 모든 번역기 호출이 다음과 같은 경우

this.Translate("hello-world")

여기서 "hello-world"는 번역 테이블의 핵심입니다. 정규식을 사용하여 작은 소스 코드 스캐너를 작성하여 모든 번역기 호출을 찾아 키워드에 해당 프로젝트 이름을 지정하는 것은 어렵지 않습니다. 이런 식으로 기존 코드 또는 번역기 인터페이스를 변경할 필요가 없습니다.

프로그램의 실제 구조에 따라 어셈블리의 IL 코드에서 해당 정보를 추출하는 것이 더 쉬울 수 있습니다. 이 예제 코드 를 사용하여 어셈블리를 구문 분석하는 번역 목적으로도 얼마 전에 비슷한 작업을 수행했습니다 .