Yerelleştirmeyi düşünerek mi gelişiyorsunuz?

Bir yazılım projesi veya bir web sitesi üzerinde çalışırken, yerelleştirme dikkate alınarak gelişiyor musunuz?

Bununla demek istediğim;

• Hata mesajları dahil tüm dizeleri dışa aktarma.
• Metin içeren görüntüler kullanılmıyor.
• Metin genişlemeyi göz önünde bulundurarak kullanıcı arayüzünüzü tasarlama.
• UI'lerinizi işlemin başlarında test etmek için sözde çeviri kullanma.
• vb.

Üzerinde çalıştığınız projelerde, bunlar 'sahip olmak güzel' kategorisinde mi ve yerelleştirme ekibinin geri kalanı için endişelenmesine mi izin veriyorsunuz yoksa geliştirme sürecinizde yerleşik yerelleştirme hazırlığınız var mı? Geliştiricilerin yerelleştirmeyi genel olarak nasıl gördüğünü duymak istiyorum.

Büyük bir Fortune 500 şirketi için çalışıyorum ve her zaman yerelleştirme düşünülerek başlıyoruz. Projelerimiz genellikle sadece ABD için, ancak yıllar boyunca pek çok kez, bir müşteri için bir uygulama yazacağız ve daha sonra başka biri görecek ve "hey, bu X ülkesi için harika bir seçim olacaktır" diyecektir. Sonra bildiğiniz bir sonraki şey kod ekleme yerelleştirme geçiyor. Uygulamayı baştan beri oluşturmak gerçekten daha fazla zaman almıyor, bu yüzden sadece yapıyoruz. Buna ek olarak, bir müşteri bize geldiğinde ve uygulamalarının içinde olmasını istediğinde (dilinizi seçin), onlara bir dosya veririz ve tercüme edilmesini (dilinizi seçmesini) söyleriz ve işimiz bitti .

Bunun 10 yıl önce önemli olduğunu düşünüyorum. Son teknoloji sorunu çözdü .

3 ulusal dilin olduğu bir ülkede yaşıyorum ve bunlardan sadece bir tanesi azınlık.

Bu nedenle oluşabilecek sorunları anlamak , ABD'nin batı kısmının doğu kısmından (çok) farklı bir dil konuşması gibidir. Ülkenin merkezinde nüfusun bir şekilde birleştiğini ve bu nedenle her iki dili de her yerde kullanmanız gerektiğini düşünün.

Masaüstü uygulamalarında ve web sitelerinde 4 dil olması çok yaygındı (3 ulusal dil + İngilizce). Bazen bir zorunluluktur.

Yerelleşmenin farkındaydım çünkü çevrem tarafından koşullandırıldım. Evet, birkaç yıl önce endişeliydim.

En son IDE araçları, herhangi bir statik uygulamayı tamamen yerelleştirilmiş bir uygulamaya kolayca dönüştürmenize izin verdiğinden, artık yerelleştirme hakkında pek umurumda değil.

Visual Studio .NET ile kullandığım araçlar:

• CodeRush , sabit kodlanmış metinleri kaynak dosyalarına taşımanıza izin veren bir Visual Studio eklentisidir.
• Kolay Yerelleştirici , tüm ek dili eklediğiniz bir Excel dosyasındaki etiketleri çıkarın, ardından kaynak dosyalarınızda birleştirin.

Müşterilerimin çoğu sadece bir dile ihtiyaç duyar ve aslında bu dili belirtir. Bu nedenle, uygulamayı yerelleştirmek için zaman harcamıyoruz. Ancak bu, diğer dilleri tamamen görmezden gelebileceğimiz anlamına gelmez. Bu yüzden temel ilkelere bağlı kalıyoruz:

• Her yerde Unicode kullanın. Bu 2k10, bunun için bir mazeret yok.
• İçin Tasarım bazı düzende elastikiyet. Tüm İngilizce ile bile, farklı yazı tiplerinin aynı nokta boyutunda çok farklı ekran ayak izleri vardır.
• Uygulama işlevlerini / veri modellemeyi görünüm katmanından uzak tutun

Kişisel olarak, potansiyel bir yerelleştirme dili temel olarak uygulama dilinden farklı olduğunda, uygulamanın basit metin seçiminden çok daha fazlası vardır. Metin değiştirme, bir şirketin nispeten daha yeni bir konumda "hızlı ve kirli" bir uygulama elde etmesine yardımcı olur ve izin verirken, diğer dildeki kullanıcıların düşünme biçimindeki temel farklılıkları çözmez.

Japonca okudum ve kendimi bu dilde sadece yeni bir başlangıç ​​olarak görünsem de, doğrudan çevirinin olmadığı bazı kavramlar olduğunu yeterince biliyorum. Bir şeyin kullanılabilir olmasını sağlayan şeyin farklı fikirleri vardır. Büyük ana kavramlar benzer olsa da, kullanıcılarla gerçekten fark yaratan ayrıntılardır.

Çok farklı bir kültürün ihtiyaçlarını gerçekten ele almak için, uygulamanız için tamamen yeni bir yüze ihtiyacınız var. Bu nedenle Model / Görünüm / Denetleyici ayrımı daha da önemli hale gelir. Uygulama aynı şekilde çalıştığı sürece, görünüm kısmı tamamen değiştirilebilir. Bu olduğunda, birisi sorunu düzgün bir şekilde çözmek için gerçek para ödemeyi planlıyor.

Gerektiği gibi yaptık: müşteriye dönük şeyler artık i18n göz önünde bulundurularak yapıldı, çünkü pazarlarımızı genişlettik ve bazı dahili şeyler artık i18n özellikli, bu yüzden bunu kullanan çalışanların İngilizce konuşmasına gerek yok.

Bu yüzden bunu başlangıç ​​olarak gerektiği şekilde yaptık.

İnsanların l10n çabalarını oldukça hafifçe aldığı sesler. Özellikle İngilizceyi orijinal dil olarak kullanırken, diğer dillerin normalde metin için% 30-40 daha fazla yer gerektirdiğini görmezden gelmek kolaydır. Bu, çevirmenlerin anlaşılması kolay olmayan ve elbette kullanıcı deneyimi için kötü olan kısaltmaları kullanmasını gerektirir.

Genellikle, daha sonra ihtiyaç duyduğumu bilsem bile, uluslararasılaşmayı daha sonra ihtiyacım olduğunda eklerim. Kullandığım dillerle, ayrı bir aşamada yapmak çok zor değil ve hantal bir yönü erken yapıcı aşamaların dışında tutabilirim.

Android uygulamaları yazıyorum ve yerelleştirme java tarzı dize dosyaları kullanarak oldukça basit. Tüm Android dillerinde tam uluslararasılaşma için neredeyse sıfır çaba.

Cevap: Evet. Çalıştığım ortamda (Python / Zope / Plone) daha sonra dizeleri yerelleştirmek çok kolay olsa da, başlangıçtan itibaren bir gereklilik değilse bunu atlıyorum.

Ama metni unicode nesnelerde saklıyorum vb.

Yani evet. Başvurularımın yerelleştirilmesinin oldukça kolay olduğundan ve yerelleştirilmese bile uluslararası bir ortamda çalışacağından eminim. Bunu yapmamak bir hatadır, çünkü gerekli çaba küçüktür ve fayda büyüktür.