Lược đồ đa ngôn ngữ phù hợp, hoặc quá mức cần thiết?


8

CẬP NHẬT 2 : Tôi thực sự đã kết thúc việc sử dụng này và thật tuyệt vời sau một vài điều chỉnh. Đây là bài viết của tôi về thiết kế thực tế của nó và đang hoạt động: http://tim.hithlonde.com/2013/lemon-schema-works/

Tôi đang xây dựng một ứng dụng web và tôi muốn nó hỗ trợ nhiều ngôn ngữ. Cấu trúc này có hai thành phần:

  1. Kết nối ngôn ngữ ('tiếng Anh', 'Deutch', v.v.) với các thuật ngữ và có một viên đá Rosetta kết nối các thuật ngữ và thuật ngữ trong ngôn ngữ cụ thể.
  2. Nhóm điều khoản theo trang. Tôi không muốn nói, CHỌN term1, term2, v.v. thông qua hơn 30 thuật ngữ tôi có thể cần trên một trang. Tôi muốn hỏi trang mà họ đang kết nối.

Đây là cấu trúc bảng được đề xuất của tôi (lưu ý tất cả các id có mối quan hệ / chỉ mục trong số chúng để thực hiện các truy vấn rất hiệu quả):

Sơ đồ

  * locale
      * id
      * value //English, Deutch, etc//
  * terms
    * id
    * value //In English//
  * page 
    * id
    * value //Think add entry, menu//
  * page_group //group all terms to a page, for easy pulling//
    * id
    * page.id
    * term.id
  * rosetta
    * id
    * locale.id
    * term.id
    * value //french word for amount, description, etc//

Điều này sẽ cho phép các truy vấn như:

SELECT localization.value,
        terms.value
FROM localization
INNER JOIN terms ON terms.id=localization.termid
INNER JOIN page_group ON page_group.termid=localization.termid
INNER JOIN page ON page.id=page_group.pageid
INNER JOIN locale ON locale.id=localization.localeid
WHERE page.value='add_entry' AND locale.id=custlangid
ORDER BY terms.id

Tôi chỉ phải yêu cầu hai mục; id ngôn ngữ mà tôi cần và trang tôi cần. Nó sẽ phục vụ tất cả các điều khoản, bằng ngôn ngữ được chỉ định, là một phần của nhóm thuật ngữ cho trang đó.

Tôi nghĩ rằng đây là một cấu trúc thực sự tốt, nhưng tôi sẽ thích một số thông tin phản hồi.

CẬP NHẬT : Để làm rõ, chúng tôi chỉ nói về nội địa hóa các thành phần UI . (nhãn, điều hướng, văn bản hữu ích) Tất cả thông tin người dùng nhập vào sẽ được lưu trữ trong unicode, không phải trong lược đồ này.

CẬP NHẬT 2 : Tôi thực sự đã kết thúc bằng cách sử dụng này, và nó thật tuyệt. Đây là bài viết của tôi về thiết kế thực tế và đang hoạt động: http://tim.hithlonde.com/2013/lemon-schema-works/


1
Thông thường (từ những gì tôi đã thấy) nội địa hóa được thực hiện thông qua các mẫu trên mặt web của mọi thứ. Những loại công cụ bạn đang tìm cách bản địa hóa từ phía cơ sở dữ liệu?
Philᵀᴹ

Tôi muốn bản địa hóa tất cả các nhãn, menu điều hướng và bất kỳ văn bản hữu ích nào (cảnh báo, v.v.) Lý do của tôi để lấy cái này từ db là, tôi không muốn logic đó trong các mẫu của mình. Trong các mẫu của tôi, tôi muốn <?php echo $term['term_in_english'];?>tôi đang phấn đấu cho một cách tiếp cận MVC vững chắc.
Tim Habersack

Câu trả lời:


6

Chúng tôi đã thực hiện rất nhiều điều này và người dùng (hành chính) được phép sửa các bản dịch trực tiếp. (Bạn vẫn có thể muốn có một lớp bộ đệm, nhưng tôi hoàn toàn thất vọng với việc điều khiển nó bằng cơ sở dữ liệu thực chứ không phải các tệp tài nguyên - nó cung cấp cho bạn rất nhiều sức mạnh để truy vấn và tìm những thứ cần dịch, v.v.). Tôi nghĩ rằng lược đồ của bạn có thể tốt, vì vậy tôi sẽ chuyển qua một số thứ chúng tôi đã học với hy vọng rằng nó hữu ích.

Một điều bạn đã bỏ qua là cụm từ với các điểm chèn. Trong ví dụ dưới đây, trật tự được đảo ngược và ngôn ngữ vẫn là tiếng Anh, nhưng đây có thể rất dễ dàng là hai ngôn ngữ khác nhau - giả vờ đây chỉ là hai ngôn ngữ thường đặt mọi thứ theo một trật tự khác.

Hello, <username> you have <x> points!

You've got <x> points to spend, <username>!

Trong pre-.NET của chúng tôi, chúng tôi đã có một thói quen đã chèn để các cụm từ trông như thế này:

Hello, {0:username} you have {1:points} points!

You've got {1:points} points to spend, {0:username}!

Điều này rõ ràng đơn giản sẽ được sử dụng trong mã của bạn như <%= String.Format(phrase, username, points); %>hoặc tương tự

Mà đã giúp người dịch một chút. Nhưng .NET String.FOrmat không hỗ trợ bình luận trong chuỗi định dạng, thật không may.

Như bạn nói, bạn sẽ không muốn xử lý điều đó trong php của bạn với nhận thức địa phương hoặc cụm từ meta.

Vì vậy, những gì chúng tôi đã có là một bảng cụm từ tổng thể:

cụm từ, tiếng Anh, thông tin bổ sung

và một bảng địa phương:

cụm từ, localeid, dịch

Bạn cũng đã giả sử với INNER THAM GIA rằng các phiên bản được bản địa hóa tồn tại - chúng tôi có xu hướng loại bỏ chúng cho đến khi chúng được dịch, do đó, truy vấn của bạn cuối cùng sẽ không trả về gì cả (thậm chí không phải mặc định)

Nếu bản dịch không tồn tại, chúng tôi mặc định là tiếng Anh, sau đó chuyển sang mã được cung cấp (trong trường hợp cơ sở dữ liệu không có ID và cũng không rõ mã nhận dạng cụm từ "TXT_LNG_WRNNG_INV_LOW" thực sự đang cố lấy ) - vì vậy tương đương với truy vấn này là những gì chúng tôi đã sử dụng:

SELECT COALESCE(localized.translation, phrase.english, @fallback)
FROM DUAL
LEFT JOIN phrase
    ON phrase.phraseid = @phraseid
LEFT JOIN localized
    ON localized.phraseid = phrase.phraseid
    AND localized.localeid = @localeid

Rõ ràng, bạn có thể nhận được tất cả mọi thứ cùng một lúc bằng hệ thống trang của mình.

Chúng tôi có xu hướng không liên kết mọi thứ với trang vì chúng được sử dụng lại rất nhiều giữa các trang (và không chỉ trong các đoạn hoặc điều khiển trang), nhưng điều đó chắc chắn là tốt.

Trong trường hợp ứng dụng gốc Windows của chúng tôi, chúng tôi đã sử dụng tệp phản chiếu và tệp ánh xạ từ thẻ điều khiển sang thẻ dịch để dịch thuật không yêu cầu biên dịch lại (trong các ứng dụng trước .NET, chúng tôi phải gắn thẻ các điều khiển bằng Thẻ hoặc đặc biệt khác tính chất). Điều này có lẽ có một chút vấn đề hơn trong PHP hoặc ASP.NET MVC, nhưng có thể trong ASP.NET nơi có một mô hình trang phía máy chủ đầy đủ.

Để thử nghiệm, rõ ràng bạn có thể truy vấn để tìm bản dịch bị thiếu rất dễ dàng. Để tìm những nơi cần được gắn thẻ, hãy dịch toàn bộ từ điển cụm từ bằng cách sử dụng pig-latin hoặc Klingon hoặc một cái gì đó như thay thế mọi ký tự không phải không gian bằng? - tiếng Anh nên nổi bật và cho bạn biết rằng một số bản rõ trần trụi đã len lỏi vào HTML của bạn.


Cảm ơn vì điều này! Tôi đã không nghĩ về các điểm chèn. Tôi không tin rằng ứng dụng của tôi thực sự sẽ có bất kỳ ứng dụng nào, nhưng thật tốt khi ghi nhớ. Ngoài ra, cảm ơn các ý kiến ​​về lược đồ. Tôi đã thực hiện thiết kế DB được một thời gian rồi, nhưng không có một nhóm đồng nghiệp tốt để so sánh các ghi chú, điều đó khiến tôi không chắc chắn vào những thời điểm mà tôi đang đi đúng hướng. :)
Tim Habersack

0

Thông thường các bản dịch được thực hiện bởi các công ty chuyên gia bên ngoài. Như vậy, sẽ rất rắc rối khi quản lý nội dung dịch bên trong cơ sở dữ liệu. Họ tốt hơn hết là quản lý trong "gói" hoặc tệp thuộc tính thông qua một số loại tính năng ngôn ngữ được cung cấp bởi nền tảng của bạn. Để đạt được điều đó, trong cơ sở dữ liệu, bạn chỉ cần đặt một bản ghi nhớ cho chuỗi. Sau đó, dựa trên ngôn ngữ mong muốn, bạn sẽ tra cứu trong gói. ví dụ.

Data:
Employee_Status = empl_status.active

language Bundles:
Employee.us:  
  empl_status.active=Active

Employee.es
  empl_status.active=<spanish translation goes here>

To get the localized content:
    String status = getLocalizedContent("Employee","empl_status.active", "us");
    String status = getLocalizedContent("Employee","empl_status.active", "es");
    String status = getLocalizedContent("Employee","empl_status.active");

Tôi bối rối, vì chúng ta đang nói về điều tương tự. Tôi sẽ xây dựng tương đương với của bạn getLocalizedContent. Ngoại trừ ở cấp độ bộ điều khiển, tôi sẽ yêu cầu tất cả các thuật ngữ được kết nối với một trang và ngôn ngữ tôi muốn sử dụng. Hàm đó sẽ gọi truy vấn mà tôi đã mô tả ở trên và thực hiện một số phép thuật để tôi lấy lại một mảng kết hợp, trong đó khóa sẽ là ghi nhớ và giá trị sẽ là thuật ngữ. Số lượng thuật ngữ UI sẽ nhỏ (<100) vì vậy tôi không thấy đó là vấn đề khi quản lý nó trong DB. Có lẽ tôi sẽ xây dựng một giao diện đơn giản để nhập các cụm từ được dịch và các trang được gói.
Tim Habersack

0

Chỉ cần tạo 3 bảng

1.) Thạc sĩ ngôn ngữ (LangId, LangName)

2.) Tài nguyên chính (ResourceMasterId, TableId, CộtId, Cột Tên)

3.) Chi tiết tài nguyên (ResourceMasterId, LangId, Value)

khóa tổng hợp (ResourceMasterId, LangId) trên Chi tiết tài nguyên

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.