Yakın gelecekte tüm içeriğin uluslararası olarak yerelleştirilmesini gerektiren bir .NET MVC uygulaması için kullanıcı arayüzü geliştiriyorum. Genel olarak .NET'e çok aşinayım, ancak uluslararası erişilebilirliğe bu kadar önemli bir odaklanma gerektiren bir projem olmadı.
Öngörülen başlangıçta İngilizce olarak yapılmaktadır. Gelecekte yerelleştirmenin uygulanmasını kolaylaştırmak için bu noktada hangi önlemleri almalıyım?
ASP.Net MVC uygulaması geliştiriyorsunuz, değil mi? Diğer yanıtlar masaüstü uygulamalarına özgü gibi görünüyor. Ortak şeyleri yakalayayım:
Yerel ayar tespiti
Uygulamanızın kullanıcının yerel ayarını doğru olarak algılaması oldukça önemlidir. Masaüstü uygulamasında, CultureInfo.CurrentCulture tercih edilen biçimlendirme yerel ayarını (sayıları, tarihleri, para birimlerini vb. Biçimlendirmek için kullanılması gereken), CultureInfo.CurrentUICulture tercih edilen Kullanıcı Arabirimi yerel ayarını (yerelleştirilmiş mesajları görüntülemek için kullanılması gereken) tutar . Web uygulamaları için, bazı süslü yerel ayar algılama iş akışı uygulamak istemediğiniz sürece (diğer bir deyişle isteğe bağlı olarak dil değiştirme özelliğini desteklemek istiyorsanız) her iki kültürü de otomatik olarak ayarlamanız gerekir (yerel ayarı AcceptLanguage başlığından otomatik olarak algılamak için).
Dizeleri dışa aktar
Tüm dizeler kaynaklardan, yani Resx dosyalarından gelmelidir. Winforms App form Localizable özelliği true olarak ayarlayarak kolayca elde edilebilir. Ayrıca, modellerinizden gelen dizeleri manuel olarak (maalesef) harici hale getirmeniz gerekir. Aynı zamanda nispeten basittir. Asp.Net'te her şeyi manuel olarak haricileştirmeniz gerekir ...
Düzenleri
Kesinlikle dize genişlemesine izin vermeniz gerekir. Winforms dünyasında, mizanpajın daha uzun metne uyum sağlamak için otomatik olarak ayarlanacağından emin olmak için kullanılması gereken TableLayoutPanel aracılığıyla erişilebilir. Web dünyasında biraz şansınız kalmadı. CSS tanımlarını değiştirmenin (geçersiz kılmanın) bir yolu olan CSS Yerelleştirme Mekanizmasını uygulamanız gerekebilir. Bu, Yerelleştirme milletlerinin talep üzerine stil sorunlarını değiştirmesine izin verecektir. Oluşturulan sayfadaki her bir HTML öğesinin benzersiz bir kimliği olduğundan emin olun; bu öğenin tam olarak hedeflenmesine izin verir.
Kültüre özgü sorunlar
Batı kültürüne özgü grafikler, renkler ve sesler kullanmaktan kaçının. Gerçekten ihtiyacınız varsa, lütfen Yerelleştirme araçları sağlayın. Yöne duyarlı grafiklerden kaçının (Arapça veya İbranice demeniz için yerelleştirmeye çalıştığınızda bu bir sorun olacaktır). Ayrıca, tüm dünyanın aynı sayıları kullandığını varsaymayın (yani Arapça için doğru değildir).
ToString () ve Ayrıştırma ()
Desteklenmediği sürece ToString () öğesini çağırırken always CultureInfo değerini geçtiğinizden emin olun. Bu şekilde niyetlerinizi yorumluyorsunuz. Örneğin: bir numarayı dahili olarak kullanıyorsanız ve herhangi bir nedenle dize kullanımına dönüştürmeniz gerekiyorsa:
int i = 42; var s = i.ToString(CultureInfo.InvariantCulture);
Kullanıcının kullanımına görüntülenecek sayılar için:
var s = i.ToString(CultureInfo.CurrentCulture); // formatting culture used
Aynısı Parse (), TryParse () ve hatta ParseExact () için de geçerlidir - CultureInfo'nun uygun kullanımı olmadan bazı kötü hatalar eklenebilir. Çünkü iyi niyetlerle dolu Microsoft'ta bazı zayıf ruhlar, CultureInfo.CurrentCulture'u varsayılan olarak (iyi bir şey geçirmezseniz) tedavi etmenin iyi bir fikir olduğuna karar verdiler - sonuçta birisi ToString ( ) kullanıcıya göstermek istiyor, değil mi? Her zaman böyle olmadığı anlaşılır - örneğin, uygulama sürüm numaranızı veritabanında depolamaya çalışın ve ardından Version sınıfının örneğine dönüştürün. İyi şanslar.
Tarihler ve saat dilimleri
always DateTime öğesini UTC'de sakladığınızdan ve başlattığınızdan emin olun (DateTime.Now yerine DateTime.UtcNow kullanın). Görüntülendikten sonra yerel biçimde yerel saate dönüştürün:
DateTime now = DateTime.UtcNow; var s = now.ToLocalTime().ToString(CultureInfo.CurrentCulture);
Gövde içinde zaman referansı olan e-postalar göndermeniz gerekiyorsa, saat dilimi bilgilerini eklediğinizden emin olun - hem UTC ofsetini hem de şehir listesini ekleyin:
DateTime someDate; // i.e. from database var formattedDate = String.Format("{0} {1}", someDate.ToLocaleTime().ToString(CultureInfo.CurrentCulture), TimeZoneInfo.Local.DisplayName);
Bileşik mesajlar
Dizeleri birleştirmemeniz konusunda zaten uyarıldınız. Bunun yerine muhtemelen yukarıda gösterildiği gibi String.Format () kullanırsınız. Ancak, bileşik iletilerin kullanımını en aza indirmeniz gerektiğini belirtmeliyim. Bunun nedeni, hedef dilbilgisi kurallarının oldukça farklı olmasıdır, bu nedenle çevirmenlerin yalnızca cümleyi yeniden sıralaması gerekmeyebilir (bu, yer tutucular ve String.Format () kullanılarak çözülür, ancak tüm cümleyi farklı şekilde çevirir) ne ikame edilecek. Sana bazı örnekler vereyim:
// Multiple plural forms English: 4 viruses found. Polish: Znaleziono 4 wirusy. **OR** Znaleziono 5 wirusów. // Conjugation English: Program encountered incorrect character | Application encountered incorrect character. Polish: Program napotkał nieznaną literę | Aplikacja napotkała nieznaną literę.
Diğer birleştirme sorunları
Birleştirme yalnızca dizelerle sınırlı değildir. Kontrolleri birlikte yapmaktan kaçının, deyin:
Bana [sayı içeren metin kutusu] günlerinde tekrar hatırlat.
Bu, şöyle bir şey için yeniden tasarlanmalıdır: Bu günlerde tekrar hatırlat: [metin kutusu].
Karakter kodlaması ve yazı tipleri
Unicode'a (UTF-8'e) her türlü metni her zaman kaydedin, aktarın. Yazı tiplerini sabit kodlamayın - Yerelleştirmenin bunları değiştirmeniz gerekebilir ve varsayılan yazı tipi geri dönüş mekanizmasını kapatır (Winformlar durumunda). Çoğu alanda "garip" karakterlere izin vermeyi unutmayın (ör. Kullanıcı adı).
test
Muhtemelen sözde çeviri uygulamanız, yani Alman kültürü için kaynak yaratmanız ve ön ek ve son ek ekleyerek İngilizce dizelerinizi kopyalamanız gerekecektir. Ayrıca, bileşik dizeleri kolayca algılamak için yer tutucuları sarabilirsiniz. Sözde çevirinin amacı, sabit kodlu dizeler, yerleşim sorunları ve bileşik mesajların aşırı kullanımı gibi Yerelleştirilebilirlik sorunlarını tespit etmektir.
Dikkate almanız gereken bazı temel şeyler:
Tüm dize kaynaklarını dışa aktar
Tüm kaynaklarınız, yerelleştirme için dağıtılabilecek harici dosyalarda bulunmalıdır. Bunların da yerelleştirilmesini istiyorsanız hata mesajlarını unutmayın.
Dize genişletmesi için yeterli alan bırakın
Örneğin, bazı dillerdeki dizeler% 30'a kadar daha uzun (Yunanca gibi) olma eğilimindedir, bu nedenle kullanıcı arayüzünüzü gerekirse dizelerin genişleyebileceği şekilde tasarladığınızdan emin olun. Fransızca için oldukça uç bir örnek:
Tamam -> Kabul Eden (Fransızca -% 400 genişleme)
Başlangıç noktası olarak bir çeşit sahte çeviri yapmanızı öneririm ( http://en.wikipedia.org/wiki/Pseudolocalization ). Veya kaynaklarınızı Google Çeviri veya Bing ile çevirebilirsiniz. Bu, gerçek çevirilerin nasıl görüneceğine dair iyi bir gösterge verecektir.
Resimlerdeki metne dikkat edin
Uygulamanızda herhangi bir resim kullanırsanız - herhangi bir metin içermediğinden emin olun - bu açıkça çevrilemez.
Hiçbir zaman Windows klasörlerine giden yolları sabit kodlamayın
Açık, ama geçmişte gördüm. Örneğin,
C:\Program Files, Windows'un bazı uluslararası sürümlerinde çevrilmiştir, ör. bu
C:\Programme bir Alman işletim sisteminde.
Yerel ayarlara özgü terimler kullanmaktan kaçının
Örneğin, birinden bir formda 'Lisesi'ni sorarsanız, bunun Batı Avrupa'da pek bir anlamı yoktur.
Dize birleştirme yoluyla dizeler oluşturmaktan kaçının
Örneğin, bu zararsız görünüyor:
strWelcome = ReadExternalString("Welcome"); strMessage = strWelcome + ", " + UserName;
Ancak, Japonca'daki Word sırası farklı olurdu, bu yüzden bu bir anlam ifade etmeyebilir.
Saat/Tarih Ayarları
Her zaman işletim sisteminden saat/tarih formatını aldığınızdan emin olun.
Buradaki tüm harika cevaplara ek olarak, Asya dilleri için bazı dikkat çekenler:
Çince ve Korece metin, eşdeğer İngilizce metinden çok daha kısa olma eğilimindedir (aynı şeyi yazmak için genellikle daha az bloklu karaktere ihtiyacınız olduğu için), bir sayfa aslında boş görünebilir Çince ama Almanca dolu ... İyi görünmek için burada dinamik boyutlandırma yapmanız gerekiyor.
Bununla birlikte, Japonca metin genellikle karakter sayısı bakımından eşdeğer İngilizce metinden çok daha uzun, hatta daha uzun olma eğilimindedir.
Asya dillerinde karakterler genellikle alt çizgi içermez, bunlar alt çizgiler içermez (yani y, g, q, j vb. Nin alt kısmı) bir ekran öğesini - genellikle düğmeler - içindeki metinle biçimlendirirseniz ve bu metin yalnızca Asya dilleri ise (yani Batı alfabesi yoksa), metin yukarı kaydırılmış gibi görünür.
Sayı biçimlendirmesini farklı işleyin. Farklı Asya ülkelerinin sayıları biçimlendirmenin farklı yolları vardır. Aynı para birimleri ile. Örneğin, Doğu Asya'da 10.000 (wan) ortak bir birimdir. Hindistan'da 100.000 (lakh) yaygındır.
Bazı ülkelerin para birimlerinin çok fazla sıfırları vardır ve ondalık noktası yoktur (örn. Japonya, Endonezya, İtalya), diğerleri ise ondalık noktadan sonra en fazla iki basamağa sahiptir.
Kelime sırası her zaman aynı olmayabilir. Dizeniz farklı veri parçalarının bir birleşiminden geliyorsa, kelime sırasını sabit kodlamak yerine dize biçimlendirmesinde {0}, {1} vb. Kullanmak en iyisidir.
Sıralama dil ve bölgeye göre farklıdır - her zaman O/S'nin yerel ayarlarına göre sıralamanız gerekir.
"Tam genişlikli" ve "yarım genişlikli" karakterler arasındaki farklara dikkat edin. Köşeli ayraçlar, noktalama işaretleri vb. Standart ASCII'den farklı "tam genişlikli" sürümlere sahip olabilir. Bu harflere göre arama veya dize bölme işlemi yaparsanız, önce tüm tam genişlikte sembolleri yarım genişlikteki eşdeğerlere dönüştürmeniz gerekir.
Veri girişi gotcha's sakının - örneğin, Çince, bir süre değil bir nokta ".". Virgül "," değil, tam genişliktedir. Veri girişini yapan kullanıcı yanlışlıkla Asya dilindeki IME'yi açabilirse, batı noktalama işaretlerini aramayı denemeyin.
Telefon numarası biçimlendirmesinde hiçbir şey olduğunu varsaymayın. Her zaman alan kodu vb. Yoktur ve farklı biçimlendirilebilir. Genellikle, ülke başına bir biçim dizesi kullanın.
İnsanların yalnızca bir cep telefonu numarası veya bir faks numarası vb. Asya'da bu şekilde değildir.
Adresler için hiçbir şey varsaymayın . Her zaman bir Posta kodu olmayabilir. Posta kodları her zaman rakam olmayabilir. Bir ülkenin eyaletleri/eyaletleri olmayabilir. Bir ülke sadece büyük bir şehir olabilir (örneğin Singapur). Bazı Asya ülkeleri için bir evin en küçük birimi "Oda X, Birim Y, Bölüm Z, Kat A, Blok B, Grup C, Emlak D" olabilir. Genel olarak, alan sayısı ve adreslerde izin verilen karakter sayısı bakımından çok liberal olun.
Selamlar sadece Bay, Bayan vb. İle sınırlı değildir. Seks için "M" ve "F" yi kullanmakta güvende olmanıza rağmen - henüz o tuhaf değiliz ...
Bazı temel adımlar, ekranda görüntülenen herhangi bir dizenin kodunuzda değişmez bir bilgi olmadığından emin olmaktır. Winforms yapıyorsanız her formun bir kullanıcı arayüzü kaynağı olacaktır. İletişim kutuları, raporlar vb. İçin proje kaynak dosyalarını kullandığınızdan emin olun.
Dolayısıyla, kodunuzdaki "Yükleme başarısız" yerine Kaynaklar gibi bir şeye sahip olabilirsiniz.
Bu şekilde, kullandığınız her dil için yeni bir kaynak dosyası oluşturabilirsiniz (ve .Net buna yardımcı olacaktır.) Ve her dosyada yerelleştirilmiş dize bulundurun.
EDIT Kullanıcı arayüzünüzü yaparken söz etmeyi unuttum, sadece orada bir şeyleri tıkamadığınızdan emin olun. Yerelleştirdiğiniz dillere bağlı olarak, gayrimenkul bir sorun olabilir. Almanca ve Portekizce dize büyümesi için en büyük 2 suçlu olan bir projede çalıştım. Biz İngilizce iyi dizeleri dikkatli olmasaydı, Fransızca ve İtalyanca Almanca patlar.
Bunun gibi, doğru kültüre yönelik aşırı yükleri kullanmayan .NET kodunu algılamada iyidir: CA1305: IFormatProvider belirtin .
Bu araçların da sinir bozucu olduğunu eklemeliyim çünkü kodunuzda genellikle zilyonlarca sorun tespit ediyorlar, ancak yine de her kurala uymasanız bile çok şey öğrenmelisiniz.
Kaynakların nasıl yükleneceğine ek olarak, başlangıç için sözde yerelleştirilmiş bir sürümle test ettiğinizden emin olun. Aksi takdirde, uluslararasılaşma hususlarının sonuna kadar ihmal edildiği yerleri fark edemezsiniz.
Diğer tüm yararlı ipuçlarına ek olarak, eksik olanlardan bazıları şunlardır:
Bazı ülkelerin birden fazla dil kullandığını dikkate alın. Örneğin, Kanada'da bir kullanıcı İngilizce ve Fransızca arasında kolayca geçiş yapmayı bekleyebilir.
Kullanıcıya tek harfli cevap bekleyen bir soru sorarsanız, kullanıcının Evet diyerek 'Y' tuşuna basmasını beklemeyin.
SQL DB'de tarihler ABD biçiminde olan Saklı işlemlerde çok dikkatli olun
Metin dizelerini DB'ye yerleştirmek, daha sonra yeniden konuşlandırmadan ek diller eklemenizi sağlar.
Çeviri için yazılı metin dosyaları gönderirken, çevirmenin doğru Word'ü seçmesini sağlamak için her zaman bir bağlam açıklaması ekleyin. Örneğin, bağlam olmadan, "pitch:" i sesle veya futbol oynadığınız bir yere çevirebilirsiniz
Adres etiketlerinin her zaman dönüştürülmesi gerekir. Kanada'da eyalet, Amerika'da eyalet, İngiltere'de ilçe
Dikkate almanız gerekenler:
Çok dilli yönlendirme
Tüm sabit kod dizesini kaynak dosyasına taşı
Bir mülke örnek:
Model:
[Display(Name = <Resource for display name>.<field for this property>)] [Required(ErrorMessage = <Resource for error message>.<field for this validate message>)] public string TestProperty { get; set; }
Görünüm:
@Html.LabelFor(m=>m.TestProperty) @Html.EditorFor(m => m.TestProperty) @Html.ValidationMessageFor(m => m.TestProperty)
İşte cevapların geri kalanında bahsedilmeyen bir şey.
Uygulamanızın karmaşıklığına ve yerelleştirilmesine bağlı olarak, alternatif bir kaynak sağlayıcısının uygulanmasını ve yerelleştirilmiş kaynakların bir veritabanında tutulmasını şiddetle tavsiye ederim. Varsayılan ASP.NET yerelleştirme şemasıyla, tüm kaynaklar RESX dosyalarında tutulur, bu dosyalar:
Olası bir kullanım örneği olarak, uygulamanız için dil paketleri sağlamayı ve arayüz üzerinden dilleri içe ve dışa aktarma yeteneğini düşünün. RESX dosyaları burada yardımcı olmaz.
Bu gibi senaryolarda alternatif bir kaynak sağlayıcısı çok yardımcı olur. Nasıl uygulanacağı hakkında daha fazla bilgi bulunabilir burada . Elbette bu, kurumsal uygulamalarda daha sık görülen, ancak yine de geçerli olan nadir bir durumdur.
En önemli şey, içeriği çeşitli dillerde yönetmek. Birkaç web sitesi geliştirdim ve içeriği çeşitli dilde yönetmek en büyük zorluktur.
Kaynakları/içeriği depolamak için Veritabanı kullanıyorum. Bana istediğim dil desteğini ekleme esnekliği sağlıyor. Belirli bir dilde bir kaynak bulunamazsa, ingilizceye geri dönme mantığını uyguladım.
Daha sonra ingilizce değerini herhangi bir dile çevirmek için bir çevirmen kullanabilirsiniz.
Uluslararasılaşmada dikkat edilmesi gerekenler:
Tüm bilgiler uluslararasılaştırılmalıdır. Grafiklerin uluslararasılaştırmak istediğimiz bilgilere sahip olabileceğini göz önünde bulundurun.
Dile bağlı olarak alanların veya dizelerin boyutu bize sorun yaratabileceğinden.
Kelimelerin sırası, bulunduğumuz dile bağlıdır, bu nedenle bir dildeki bir düzen başka bir dilde aynı olacaktır.
Tarih biçiminin bir dilden diğerine değişeceğini dikkate almalıyız
Yazılım uluslararasılaşması en iyi koşullar altında zor , ancak uluslararasılaşma sorunlarının tartışılmasında belirli bir ülkenin ne sıklıkta ortaya çıktığı beni hep şaşırttı: Türkiye ...
Yerelleştirme veya uluslararasılaştırma hakkında bir fikriniz varsa, kodunuzu mümkün olan en kısa sürede Türk yerel ayarlarında çalışmaya zorlayın . Kodunuzun çoğunda çalışan güçlü bir bellewether - ancak hiçbir şekilde kültürler ve yerel ayarlar ...
Siteniz/programınız bir Türk müşteriyle iyi çalışıyorsa, diğer birçok platformda çalışacağından emin olabilirsiniz.