Ứng dụng đa ngôn ngữ MVC 4

Question

Tôi đang tạo một ứng dụng mới ngay bây giờ và tôi muốn làm mọi thứ ngay từ đầu để tôi có thể phát triển với nó trong tương lai.

Tôi đã xem xét một số hướng dẫn về cách tạo ứng dụng hỗ trợ đa ngôn ngữ, nhưng tôi không thể tìm ra người phù thủy để sử dụng.

Một số hướng dẫn cũ và tôi không biết liệu chúng có lỗi thời hay không.

http://www.codeproject.com/Articles/352583/Localization-in-ASP-NET-MVC-with-Griffin-MvcContri http://geekswithblogs.net/shaunxu/archive/2012/09/04/localization-in-asp.net-mvc-ndash-upgraded.aspx http://www.hanselman.com/blog/GlobalizationInternationalizationAndLocalizationInASPNETMVC3JavaScriptAndJQueryPart1.aspx http://www.chambaud.com/2013/02/27/localization-in-asp-net-mvc-4/ https://github.com/turquoiseowl/i18n

tôi thấy rằng họ là 2 cách để lưu trữ các dữ liệu ngôn ngữ, hoặc trong db hoặc trong các tập tin tài nguyên. Ưu điểm/khuyết điểm là gì? Có cách nào khác được ưa thích hơn không?

Đây là những gì tôi muốn:

1. dễ dàng để duy trì (Add/Change/Remove)
2. Hỗ trợ đầy đủ ngôn ngữ. (số lượt xem, đơn vị tiền tệ, thời gian/ngày, jquery, chú thích, v.v ..)
3. Bật để thay đổi ngôn ngữ.
4. Tự động phát hiện ngôn ngữ.
5. An toàn trong tương lai.

Cách ưa thích để làm điều này là gì? có bất kỳ hướng dẫn tốt nào là phương pháp hay nhất cho năm 2013?

Answer 1

Tôi có cách tiếp cận cho bản thân dựa trên db, tuy nhiên nó có thể không phù hợp với các ứng dụng quy mô lớn.

Tôi tạo một bảng/thực thể Translation để giữ tiêu đề và văn bản phải đa ngôn ngữ.

Vì vậy, bất cứ khi nào tôi muốn làm một cái nhìn, đầu tiên tôi lấy bản dịch thích hợp từ db và sau đó vượt qua nó để xem như mô hình:

var t = dbCtx.Translations.Find(langID); 
// ... 
return View(t); 

Và theo quan điểm, tôi làm cho nội dung như sau :

<tr> 
    <td>@Html.DisplayFor(m => m.WelcomeMessage)</td> 
    <td>@Url.Action(Model.EnterSite, "Index", "Home")</td> 
</tr> 

Và về cách nhận câu trả lời thích hợp, bạn có nhiều cách. Bạn có thể sử dụng phiên:

Session["Lang"] = "en"; 
// ... 
var lang = (string)Session["Lang"] ?? "en"; 

Hoặc bằng cách chuyển qua chuỗi truy vấn hoặc kết hợp chúng.

Đối với ngôn ngữ tự động phát hiện, bạn nên quyết định các nội dung sau:

a) Phát hiện từ trình duyệt

b) Phát hiện từ IP của người dùng và đoán vị trí địa lý của anh/cô ấy và thiết lập ngôn ngữ thích hợp cho anh/cô ấy

Answer 2

Tôi đã xem xét các nguồn giống như bạn cho cùng một nhu cầu nhưng khi bạn nói rất khó để tìm ra một giải pháp ưu tiên.

Nhưng tôi quyết định đi với giải pháp của Michael Chambaud mà bạn đã liên kết trong câu hỏi của bạn. Lý do cho điều này là nó rất dễ dàng để thực hiện, đã cho tôi url của tôi muốn và kể từ khi tôi vẫn không chắc chắn 100% ... dễ dàng để thay thế trong tương lai.

Ngoài ra, tôi sẽ sử dụng jquery toàn cầu hóa cho định dạng phía máy khách.

Sẽ rất thú vị nếu bạn nghe giải pháp nào bạn quyết định?

Answer 3

Tôi có cảm giác rằng câu hỏi này không có câu trả lời thẳng về phía trước. Để định dạng và không phải lúc nào bạn cũng nên sử dụng các số Culture và UICulture ví dụ như 'en-GB' cho tiếng Anh và tiếng Anh 'en-US' cho tiếng Anh Mỹ (và có, có sự khác biệt). Tất cả .Net được xây dựng xung quanh nó và theo cách đó bạn có thể sử dụng định dạng cục bộ mà không thực sự nghĩ về nó.

Bạn cũng nên kiểm tra không gian tên System.Globalization để biết thêm chi tiết: http://msdn.microsoft.com/en-us/library/system.globalization%28v=vs.110%29.aspx

Đối với những nền văn hóa phải xuất phát từ, sau đó ít nhất là trong công ty chúng tôi chính sách có luôn không có ngoại lệ từ chuỗi truy vấn. Lý do là nếu bạn sử dụng bản địa hóa IP, thì nếu người dùng Tây Ban Nha đang xem một trang tiếng Tây Ban Nha ở Nhật Bản và sau đó sẽ được chuyển sang phiên bản tiếng Nhật, thì không chính xác nhưng có thể gây khó chịu nếu bạn đã nói khách hàng rằng đó là một liên kết trực tiếp tiếng Tây Ban Nha hoặc một cái gì đó. Điều đó nói rằng nếu văn hóa là không xác định trong chuỗi truy vấn, sau đó sử dụng IP để đoán với ngôn ngữ người dùng muốn có, sẽ không phải là một ý tưởng tồi, nhưng thực sự phụ thuộc vào nhu cầu khách hàng của bạn.

Để nhận bản dịch, thì điều đó thực sự phụ thuộc, cả tài nguyên và DB đều có những thăng trầm. Vì vậy, những điểm chính cho DB là, dễ chia sẻ giữa các ứng dụng và nếu bạn cần cập nhật cụm từ vì bất kỳ lý do nào, bạn có thể cập nhật tất cả thông qua một mục nhập DB, nhưng điều này cũng có thể là lỗi, bởi vì một số cụm từ có ý nghĩa kép và có thể được dịch hoàn toàn khác nhau trong các ngôn ngữ khác mặc dù cùng một câu được sử dụng bằng tiếng Anh. Vấn đề lớn khác với DB là ở một mức độ (nhưng điều này phụ thuộc vào việc thực hiện) bạn mất trí thông minh trong VS cho các cụm từ.

Tài nguyên tất nhiên có thông minh phù hợp, nhưng chúng khá tĩnh đối với ứng dụng web bạn đang sử dụng, bạn không thể chia sẻ tài nguyên trên các ứng dụng ... cũng không chính xác, nhưng bạn càng không thể. Mặc dù tính chất tĩnh đó cũng là một điểm cộng, bởi vì tất cả các tài nguyên được chứa trong ứng dụng và bạn biết rằng không có tác động bên ngoài nào có thể ảnh hưởng đến nó.

Thực tế nó phụ thuộc vào dự án trong tay. bạn chỉ đơn giản là phải có những ưu và khuyết điểm của riêng mình và quyết định cho bản thân mình ... xin lỗi. Nhưng nếu nó giúp ích chút nào, tôi có thể cho bạn biết mọi thứ trong công ty của tôi. Chúng tôi thực hiện một số ứng dụng, chia sẻ cùng một cụm từ trên tất cả các ứng dụng web khác nhau. Chúng tôi từng có nó trong DB, nhưng những gì đã xảy ra là các bản dịch tiếp tục đi theo mảng, nghĩa là một khách hàng đã yêu cầu bản dịch tốt hơn bằng tiếng Tây Ban Nha cho một ứng dụng, nhưng điều đó không có ý nghĩa gì với người khác. Điều đó đã xảy ra nhiều hơn bạn nghĩ. Sau đó, chúng tôi chuyển sang tài nguyên, nhưng điều đã xảy ra khi bản dịch của một ứng dụng được cập nhật, sau đó không ai nhớ cập nhật các ứng dụng khác và thực tế đã xảy ra 3 ứng dụng khác nhau đã dịch cùng một cụm từ theo 3 cách khác nhau. Cuối cùng, chúng tôi quyết định quay trở lại DB, bởi vì khả năng thay đổi tất cả các bản dịch cùng một lúc có ý nghĩa hơn với chúng tôi, thì thực tế không có ảnh hưởng bên ngoài nào có thể ảnh hưởng đến nó.

Nói chung cũng có những ưu điểm và nhược điểm khác, nhưng tất cả điều đó là không liên quan so với ở trên. Bạn thực sự cần phải hỏi làm thế nào bạn đang sử dụng các bản dịch.Đối với việc chỉnh sửa chung (không bao gồm điểm trên), thì cách tiếp cận aider cũng hoạt động tốt, bạn có thể dễ dàng thay đổi và chỉnh sửa hoặc mở rộng bản dịch với cả hai cách tiếp cận.

Điều đó nói rằng, nếu cuộc gọi DB và DB được thiết kế kém, thì việc thêm ngôn ngữ mới có thể dễ dàng hơn với tài nguyên, chỉ cần sao chép tệp tài nguyên, thêm phần mở rộng văn bản vào tên và thêm bản dịch vào tài nguyên và bạn được thực hiện, nhưng một lần nữa, hoàn toàn xuống thiết kế DB, vì vậy đó là một cái gì đó để ghi nhớ khi thiết kế DB và nói khá không có gì về việc giữ các bản dịch trong DB. Bằng cách lớn tôi sẽ nói rằng các nguồn tài nguyên dễ sử dụng hơn và rất dễ bảo trì và mở rộng (và chúng đã được tích hợp sẵn vào .NET) mặc dù DB có lợi thế rõ ràng nếu bạn cần chia sẻ bản dịch. Vì vậy, nếu tôi sẽ phải nói rằng tôi sẽ nói cách được đề nghị là sử dụng Tài nguyên, nhưng DB không có vị trí của nó và nó thực sự phụ thuộc vào dự án.

Answer 4

Tôi đã written a blog post convering các khía cạnh sau đây của một ứng dụng MVC asp.net đa ngôn ngữ:

Cơ sở dữ liệu: tôi chia bảng thành hai phần, một chứa các lĩnh vực phi thể dịch khác chứa các lĩnh vực cần dịch .

Tuyến đường url: Tôi thường giữ văn hóa trong URL theo cách bạn nhận được trang web ML được lập chỉ mục tốt.

routes.MapRoute(
    name: "ML", 
    url: "{lang}/{controller}/{action}/{id}", 
    defaults: new { lang = "en-CA", controller = "Home", action = "Index", id = UrlParameter.Optional } 
); 

Từ lớp bộ điều khiển cơ sở, bạn có thể cung cấp thông số {lang} cho Bộ điều khiển của mình. Xem bài đăng trên blog để biết tất cả chi tiết.

Truy vấn dữ liệu của bạn: Bạn chỉ cần chuyển Văn hóa đến ngữ cảnh lưu trữ hoặc cơ sở dữ liệu của mình. Ý tưởng là tạo mô hình xem hợp nhất hai bảng mà bạn đã tách ra để dịch.

public ActionResult Index(string id) 
{ 
    var vm = pages.Get(id, Language); // Language is the {lang} from the route 
    return View(vm); 
} 

xem của bạn: nộp Sử dụng tài nguyên NET với mã ngôn ngữ hai chữ chung chung, ví dụ: HomePage.en.resx, HomePage.fr.resx. Nơi đặt en * -US *, en * -CA * là hữu ích để định dạng tiền tệ, ngày tháng, số vv tập tin tài nguyên của bạn sẽ chủ yếu là khả năng là như nhau cho tiếng Anh Mỹ, Canada, vv

Hình ảnh: Sử dụng định dạng như imagename-en.png, imagename-fr.png. Khỏi Chế độ xem của bạn làm cho {lang} tham số tuyến đường có sẵn thông qua một phương pháp mở rộng và hiển thị hình ảnh của bạn như thế này:

<img src="/content/logos/imagename-@this.CurrentLanguage()" /> 

Bạn cũng có thể hoàn toàn thư mục riêng cho ngôn ngữ của bạn hỗ trợ. Ví dụ: /content/en/imagename.png, /content/fr/imagename.png.

JavaScript:: Tôi thường tạo tên thư mục tệp LanguagePacks và JS có tên Lang-en.js, Lang-fr.js.Ý tưởng là để tạo ra lớp "tĩnh" mà bạn có thể sử dụng trên tất cả các file JS khác của bạn:

// lang-en.js 
var Lang = { 
    globalDateFormat = 'mm-dd-yy'; 
    greeting: 'Hello' 
}; 

On lần xem, bạn tải các ngôn ngữ tập tin chính xác

<script type="text/javascript" src="/content/js/languagepacks/lang-@(this.CurrentLanguage()).js"></script> 

Từ một module JavaScript

// UI Module 
var UI = function() { 

    function notify() { 
    alert(Lang.greeting); 
    } 
    return { 
    notify: notify 
    } 
}; 

Không có cách nào để thực hiện một ứng dụng web đa ngôn ngữ. Sử dụng Tài nguyên để dịch văn bản của bạn, chúng có thể nhanh chóng hoán đổi vào thời gian chạy. Bạn có nhiều trình chỉnh sửa có thể mở những trình chỉnh sửa mà bạn có thể chuyển cho người dịch, v.v.

Bạn có thể kiểm tra bài đăng trên blog và xem ví dụ chi tiết về cách tôi thực hiện việc này.