동적 데이터의 현지화

데이터베이스에 저장된 데이터를 현지화하는 모범 사례에 대한 조언을 찾고 있습니다. 모든 정적 텍스트가 파일을 사용하여 지역화 된 웹 응용 프로그램에서 작업하고 있습니다. 관리자가 UI를 사용하여 구성 할 수있는 몇 가지 옵션이 있습니다.이 옵션은 데이터베이스에 저장되어 있으며 이러한 값을 지역화해야합니다.동적 데이터의 현지화

우리는 몇 가지 가능한 아이디어를 생각해 냈습니다. 이 솔루션에 대한 귀하의 생각은 무엇입니까? 더 나은 옵션이 있습니까 아니면 표준 모범 사례가 있습니까?

당이 필드를 전문 현지화

이것은 best practices for multilanguage database design 제안 솔루션입니다. 각 현지화 된 필드에 대해 별도의 테이블을 만들 것입니다. 예를 들어, 우리가 color_id, color_name 및 color_description 열이있는 테이블 colors을 가지고 가정, 우리는 지역화되지 않은 데이터와 color_translations 테이블 color_id, locale, color_name 및 color_description 필드와 color 테이블에 그것을 깰 수 있습니다.

그러나 고객은 번역을하기 위해 현지화 파일을 제 3 자에게 보내는 경우가 많아 까다로워집니다.

단일 테이블 현지화

또 다른 옵션은 데이터베이스 현지화의 모든 표현하는 하나의 테이블을 생성하는 것입니다 :

CREATE TABLE localized_text 
(
    key   VARCHAR(256) NOT NULL, 
    locale  CHAR(5) NOT NULL, 
    value  VARCHAR(256), 
    PRIMARY KEY (key, locale) 
);

이 오프 사이트 현지화에 대한 수출하는 것이 더 쉽습니다을하지만 추가 간접적 인 수준.

출처

2010-06-28 Ross

"여러 옵션"이 DB에 코드로 저장되고 앱 프리젠 테이션 수준으로 번역 된 이유가 있습니까? 어쨌든 나는 많은 diff를위한 많은 다른 번역을 가진 거대한 테이블이기 때문에, 옵션 1이 훨씬 더 깨끗하다고 생각합니다. 모델은 지옥을 빨리 바꿀 수 있습니다. –

데이터베이스에 코드를 저장하는 것에 대한 주요 반대 의견은 사용자가 두 가지 다른 장소로 이동해야한다는 것입니다. 번역을 위해 현지화 파일을 보내지 만 소규모 고객에게 이상적인 것은 아닙니다. 더 큰 회사조차도 키를 UI에서 파일로 복사하여 번역해야합니다. 가능한 한 해결책은 필요한 경우 현지화 파일을 수정하기 위해 UI를 업데이트하는 것일 수 있습니다. 누구든지 그 생각을 가지고 있습니까? – Ross

옵션 # 1을 수행하고 고객이 앱 외부에서 맞춤 콘텐츠를 번역하는 데 사용할 간단한 가져 오기/내보내기 도구를 구현합니다. –

각 현지화 된 필드에 대해 별도의 표를 생성합니다. 예를 들어,

이 colors 테이블 만 정적 텍스트입니다 가정 .... 우리가 color_id, color_name 및 color_description 열이있는 테이블 색상을 가지고 가정, 확실한 선택이에 열을 추가하는 것입니다, 아마 이름 locale 그리고 관심있는 모든 로케일에 대한 행을 추가하십시오. 그런 다음 고객의 로케일에 가입하여 원하는 단일 설명을 작성하십시오.

지역화 된 설명은 다 대일 관계를 도입하기 때문에이 기능을 사용하려면 정적 설명과 로캘 독립적 데이터를 분리해야합니다. 임시 방편으로 메인 테이블에 영어 설명을 남기고 모든 설명이 사라지면 드롭 할 수 있습니다.

출처

2013-03-14 04:43:19

동적 데이터의 현지화

답변

관련 문제