다국어 웹사이트를 만드는 방법

다국어 웹사이트를 만드는 방법

닫힘.이 질문은 더 필요합니다.집중적인현재 답변을 수락하고 있지 않습니다.

---

이 질문을 개선하고 싶으십니까?이 게시물을 편집하여 하나의 문제에만 초점을 맞추도록 질문을 업데이트합니다.

9년 전에 문을 닫았습니다.

이 질문을 개선합니다.

PHP와 MySQL에서 동적인 다국어 웹사이트를 만드는 방법을 알려줄 수 있는 사람이 있습니까?저는 그것에 대해 전혀 모릅니다.구글에 검색해봤는데 좋은 해결책이 없었습니다.

누가 나에게 단계별 가이드를 제공해 줄 수 있습니까?가능하면 다국어 웹사이트 데모를 만듭니다.또는 그것에 대한 자세한 설명이 나와 있는 링크를 참조해 주세요.

짧은 대답: 고려해야 할 변수와 해야 할 일이 많기 때문에 짧은 대답은 없습니다.그래서...

긴 답변:저는 제가 할 수 있는 한 그것을 분해할 것이지만, 당신의 질문만큼 광범위한 질문에 대한 "모두에게 좋은" 대답은 없습니다.

첫째, 당면한 작업의 변수:

1. 언어 목록: 사이트가 사전 정의된 언어 집합으로 되어 있습니까? 아니면 다양하고 이질적으로 되어 있습니까?예를 들어, 사이트는 완전히 두 개의 잘 정의된 언어로 이중 언어로 구성될 수 있습니다(또는 다른 예를 들어, 영어/카탈란어/스페인어 사이트를 운영합니다). 또는 다른 언어로 다른 섹션을 사용할 수 있습니다(예를 들어, MS의 사이트를 보십시오: 대부분이 동질적이지만 블로그, KB 기사,일부 문서는 지원되는 언어의 하위 집합으로 제공됩니다.

2. 번역 출처: 컨텐츠가 귀하 또는 일부 협력자에 의해 각 관련 언어로 제공됩니까?또는 일부 버전은 단일 "기본" 언어의 번역 소프트웨어를 통해 실행됩니까?첫 번째 접근법은 콘텐츠를 제작하는 데 많은 추가 작업이 필요하지만 두 번째 접근법보다 더 높은 품질의 결과를 산출합니다.

3. 언어 자체: 1)과 2)에 답을 얻으면 어떤 언어로 작업하고 있는지 정확히 알아야 합니다.방언(예: 미국 영어 + 영국 영어 또는 아르헨티나 스페인어 + 스페인어)을 포함하는 경우 검색 엔진과 관련하여 몇 가지 "내용 중복" 문제가 발생할 수 있지만, 이에 대한 자세한 내용은 여기에서 너무 주제와 맞지 않습니다(잠재적인 문제에 대해 알고 있음).

4. 추상적인 언어를 목표로 하고 있습니까(예: 제 사이트는 방문자가 어디에 있든 상관없이 세 가지 언어를 제공합니다. 제가 가지고 있는 것이 바로 그것이므로 원하는 것을 선택하십시오); 아니면 다른 지역/국가를 목표로 하고 있습니까?후자의 경우 언어 이외의 다른 항목(예: 시간대, 통화 또는 날짜/시간 형식 규칙)에 신경을 써야 하기 때문에 상황이 더 복잡해질 수 있지만 국가별 TLD를 사용할 수 있다는 이점을 얻을 수 있습니다.

위의 내용을 잘 파악한 후 작업을 시작합니다.처리해야 하는 가장 중요한 작업은 다음과 같습니다.

1. 언어 탐지: 가장 합리적인 접근 방식은 GET 매개 변수(URL의 ?dll=en-us와 같은 것)를 사용하는 것입니다.또한 언어 인수가 없는 URL이 요청될 때 일부 쿠키 및/또는 IP 지리 위치를 사용하여 폴백할 수 있습니다..example.com/index.php?lang=en-us또는example.com/en-us/home개인적으로, 저는 제 .htaccess 파일에 대해 ModRewrite 권한을 부여하는 파워를 좋아하지만, 그것은 Apache 기반 서버에서만 작동합니다.

2. 컨텐츠 관리: DB에서 컨텐츠를 가져오는 경우(예: 기사 컨텐츠), 포함 파일(빵 조각, 메뉴, 사이트 전체 제목 등에 일반적) 또는 기타 방법에 관계없이 컨텐츠의 각 버전(언어)을 분리할 수 있는 방법이 필요합니다.다음은 이 작업을 수행하는 방법에 대한 몇 가지 예입니다.

   • DB 콘텐츠에 대해서는 확실한 필드 명명 패턴을 생각해내고 고수하는 것이 가장 좋습니다.를 들어, 저는 예를들어, 첨합니다부나는을 합니다._en,_es또는_ca에 종속된 합니다. DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ?는 이렇게하면다같은표현올수콘있액다습니세바할텐스에츠른로으음과▁withions▁like다▁this있▁the와 같은 표현으로 올바른 내용에 접근할 수 있습니다.$row["title_$lang"].
   • 포함 파일의 경우에도 파일 명명 규칙이 가장 현명한 접근 방식입니다.이 저의경우, 일이다끝음납으로 경우가 ..en.php,.ca.htm기타. 내 포함 통화는 다음과 같습니다.include("some-filename.$lang.php).
   • 때때로 PHP 코드에서 직접 작은 텍스트 덩어리를 뱉습니다(예를 들어 표 제목에 레이블을 지정할 때).동일한 키를 가진 "청크" 배열을 정의하는 언어별 포함 파일 또는 Geert가 제안한 것과 같은 DB 테이블을 사용할 수 있습니다.전자의 접근 방식은 개발하는 데 더 적은 작업이 필요하고 후자는 유지하는 데 더 적은 작업이 필요합니다(특히 혼자 작업하지 않는 경우).

3. 언어 선택: 매우 중요합니다. URL 자체에서 GET 인수를 조정하는 것 외에 사용자가 자신의 언어를 선택할 수 있는 방법을 제공해야 합니다.페이지가 처음에는 사용자가 전혀 모르는 언어로 되돌아가도 이해할 수 있기 때문에 소수의 언어의 경우 "플래그"가 잘 작동하는 경우가 많습니다.더 많은 언어의 경우 드롭다운 메뉴(뷰포트 공간 측면)가 더 효율적이지만 시각적(즉, 텍스트가 아닌) 힌트를 추가해야 합니다.일부 사이트에서는 입력 시 언어를 선택하도록 강제하고 각 언어의 홈 페이지에 대한 링크만 제공합니다.개인적으로, 저는 제 사이트의 메뉴 위에 제 세 개의 플래그가 눈에 띄고, 각각 언어 인수만 변경된 현재 주소를 가리킵니다.이와 같은 코드는 매우 잘 작동할 수 있습니다.

---

function translatedURI($new_lang) {
    return str_replace("lang=$lang", "lang=$new_lang", "http://" . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"];
}

---

4. CMS 조정: 사이트(또는 일부)가 CMS, 토론 게시판 등을 사용하면 상황이 상당히 복잡해질 수 있습니다.제 경험으로 말하자면, 저는 3개의 독립 포럼처럼 보이는 방식으로 3개의 주요 범주(언어당 1개)로 나뉘어진 제 사이트에 phpBB 포럼을 가지고 있습니다(그러나 사용자들은 실제로는 동일한 보드의 범주에 불과하기 때문에 그 중 하나에 로그인/등록하기만 하면 됩니다).이것이 원활하게 작동하기 위해 내가 해야 했던 수정은 내가 여전히 지키는 제정신의 마지막 잔재를 위협했습니다:S.이러한 경우에는 사용 중인 특정 소프트웨어의 문서 및 지원 기능을 찾아보는 것이 좋습니다.

지금은 그게 제가 생각할 수 있는 전부입니다.저는 당신이 소매를 걷어붙이고 일을 시작할 수 있는 충분한 양을 가져야 한다고 생각합니다.그런 다음, 만약 여러분이 여러분의 길에서 어떤 벽에 부딪힌다면, 저는 여러분이 더 구체적인 답을 얻을 것이라고 확신합니다.

이게 도움이 되길 바랍니다.

항상 사용하는 솔루션은 가능한 모든 메시지가 포함된 데이터베이스 테이블을 만드는 것입니다.각 메시지에 대해 코드(약어)를 사용하여 검색합니다.예를 들어 다음과 같습니다.

lang  id        message
en    login     Login
en    lostpass  Lost your password?
de    login     Anmelden
de    lostpass  Paswort vergessen?
nl    login     Aanmelden
nl    lostpass  Wachtwoord vergeten?

번역 검색은 보통 MySQL 쿼리를 사용하여 충분히 빠르지만 스크립트가 로드될 때 모든 메시지를 배열에 저장하고 메모리에 로드할 수도 있습니다.사용자는 항상 원하는 언어를 설정할 수 있어야 하며 웹 브라우저에서 설정한 언어 헤더에 맹목적으로 의존하지 마십시오.

저는 지금 아주 작은 CMS를 디자인하고 있습니다. 다국어여야 합니다.

제가 가장 걱정하는 특징 중 하나는 고객이 자발적으로 언어를 추가하거나 제거하기로 결정할 수 있다는 것입니다.

이러한 이유로, 저는 데이터베이스 테이블에 접미사를 추가하는 설계를 목표로 하는 것이 아니며, 테이블 이름을 수정하거나 동적 이름을 사용하여 액세스하거나 언어를 정의하거나 제거할 때마다 필드를 추가하거나 제거할 수 없습니다.

데이터베이스를 좋아하고 유지 관리가 쉽기 때문에 파일도 사용하지 않을 것입니다.

그리고 마지막으로, 저는 두 가지 유형의 번역을 생각합니다.

1. 웹 텍스트.
2. 내용 텍스트.

따라서 제 디자인의 목표는 다음과 같습니다.

• languages 언어가 정의된 테이블입니다.
• 변환 모든 메시지를 포함하는 단일 테이블은 다음과 같습니다.
• [table] table_name 내용을 변환할 테이블의 이름입니다.
• [field] field_name 내용이 변환될 필드의 이름입니다.
• [proxy] row_id 변환할 항목의 행 식별자.
• [언어] 텍스트가 번역되는 언어입니다.
• 번역된 텍스트를 문자로 보냅니다.

즉, 단일 언어 시나리오에서 내용을 포함하는 필드의 테이블은 항상 번역 테이블에 있기 때문에 내용이 무효화됩니다.

이렇게 하면 SQL 쿼리의 복잡성이 증가하지만 번역을 쉽게 유지할 수 있는 도구를 개발할 수 있습니다.또한 SQL의 복잡성은 솔루션을 구현할 때 한 번만 존재합니다.이러한 구현이 적절하게 설계되면 사이트의 유지보수/확장성이 큰 문제가 될 필요가 없습니다.

편집:

개발자 친구들과 몇 가지 대화를 나눈 결과, 제가 접근하고 있는 솔루션이 단일 테이블에 너무 많은 비용을 부과하고 있다고 생각합니다.

지금부터 연구할 또 다른 접근 방식은 다음과 같이 각 "번역 가능한 테이블"에 대한 추가 테이블을 만드는 것입니다.

• any_compatable_table:필드를 변환해야 하는 테이블
• any_compatable_table_configuration:변환이 저장될 테이블입니다.
• [field] field_name 내용이 변환될 필드의 이름입니다.
• [proxy] row_id 변환할 항목의 행 식별자.
• [언어] 텍스트가 번역되는 언어입니다.
• 번역된 텍스트를 문자로 보냅니다.

이 구성표는 첫 번째 구성표의 개념을 상속하지만 테이블별로 내용을 구분합니다.이 대체 솔루션은 성능을 향상시키고 인덱스 문제와 같은 문제를 분리할 수 있습니다.

"번역 가능한 테이블"당 추가 번역 테이블은 원래 테이블과 동시에 작성됩니다.

SQL 쿼리의 경우 복잡성은 여전히 동일합니다.첫 번째 접근 방식은 변환 테이블을 검색하기 위해 테이블 이름이 필요하지만 두 번째 접근 방식은 테이블 이름에 접미사 "_translations"를 추가하기만 하면 됩니다.

언급URL : https://stackoverflow.com/questions/2487171/how-to-make-a-multilanguage-website