Translatable modules/Proposed solutions/tr

 Çevrilebilir modüller projesi, modül yerelleştirmesi için yeni bir çerçeve oluşturmaya çalışıyor.

Burada tartışma için önerilen birkaç depolama çözümü önerilmiştir.

Bu danışmanlığın ana hedeflerinden biri, bu çözümlerden hangisinin uygulanacağına ve tüm modül geliştiricilerine önerileceğine karar vermektir.

Açıklama
Meta'da Module:ModuleMsg benzer bir şey kullanın, ancak standartlaştırılmıştır:


 * Tüm mesajları, çeviri için işaretlenmiş normal bir vikimetin sayfasına koyun.
 * Bunları yüklemek için standart Lua işlevlerine sahip olun (her vikide Module:ModuleMsg gibi bir modül yerine).

Avantajlar

 * Çeviri hizmetlileri çevrilmesi gereken sayfaları işaretlemeye aşina.
 * Şablonlarda da işe yarayabilir.
 * Her çeviri bir viki sayfasıdır. Katkı, geçmiş, ayrı işleme vb. için iyidir.

Dezavantajlar

 * Varsayılan olarak, çeviri birimi işaretleri sayılardır. Numaraları mesaj anahtarı olarak kullanmak kodu okunamaz hâle getirir. Rakamları dizelerle değiştirmek mümkündür, ancak yukarıda belirtildiği gibi, Translate uzantısında bunu yapmanın yolu şu anda iyi belgelenmemiştir. Bu, muhtemelen bu Translate uzantısı özelliğinin uygun şekilde belgelenmesi ve standartlaştırılmasıyla çözülebilir.
 * Parametrelerin ($1 vb.) ve diğer viki sözdizimi i18n özelliklerinin (GENDER, PLURAL, vb.) nasıl çalışacağı açık değildir. Vikimetin içerik sayfalarıyla mutlaka uyumlu olmayabilirler.
 * Bu, bir viki içinde modül yerelleştirmesi için işe yarayabilir, ancak modüller küresel hâle geldiğinde mutlaka çalışmayacaktır.
 * Çeviri için sayfaları aramak için bir çözüm gerekli olacaktır. Şu anda mesaj grubu seçici, çevrilebilir tüm sayfaları gösteriyor.
 * Küresel modüller ve şablonlar çağında, vikilerde yerel olarak nasıl özelleştirileceği belirsizdir.
 * Her ileti çevirisi ayrı ayrı yüklenirse ve geri dönüşlerin işlenmesinde olası performans sorunları.  Eylem API'si vardır, ancak çevirileri yüklemek için muhtemelen Lua veya Vikimetin API'si yoktur.

Description
Use something similar to what Module:TNT is doing, but formalized:


 * Belgeler için qqq dahil olmak üzere tüm kaynak iletileri MediaWiki uzantılarında olduğu gibi Commons'daki Veri ad alanındaki bir JSON dosyasında "banana" biçiminde depolayın.
 * Aynı sözdizimi, çekirdek ve uzantı mesajları için kullanılabilir.
 * Kaynak mesajları yüklemek ve çevirileri dile göre JSON dosyalarına yazmak için Translate uzantısını geliştirin.
 * Mesajları yüklemek için standart Scribunto kitaplığına Lua işlevleri ekleyin.
 * Translate'in mesaj grubu seçicisinde uygun şekilde görüntülenmek üzere çevrilebilir dosyayı düzenlemek üzere başka bir JSON dosyası kullanın.

Avantajlar

 * Dosya biçimi, uzantılardakiyle aynıdır.
 * Bu sayfalara modüllerden küresel olarak erişilebilir.
 * Ham sayfalar, istenirse tüm çevirileri içeren JSON'u yerel nesneye dönüştürecek olan JavaScript küçük araçları için kolayca kullanılabilir. Tek bir dili veya yedeği almak için bir API gerekli olabilir, bu da ağ erişimini iyileştirir. JavaScript küçük araçları, tüm iletiler için istemci önbelleğinde depolanan tek bir sorguyu tercih eder.

Dezavantajlar

 * Translate uzantısında yeni bir dosya biçimi desteği (FFS) geliştirilmeli ve sürdürülmelidir. MessageLoading'in yanı sıra yeni bir MessageGroup türüne ihtiyacımız olacak.
 * Küresel modüller ve şablonlar çağında, vikilerde yerel olarak nasıl özelleştirileceği belirsizdir.

Açıklama
“Veri ad alanındaki JSON .tab dosyasına” benzer, ancak:


 * Belgeler için qqq dahil olmak üzere tüm kaynak iletileri MediaWiki uzantılarında olduğu gibi Commons'daki Veri ad alanındaki bir JSON dosyasında "banana" biçiminde depolayın.
 * (Tüm dilleri tek bir JSON yapısında mı yoksa dil başına bir yuvada mı depolayacağınıza karar vermeniz gerekir.)
 * JSON dosyası, modülün kodunu depolayan viki sayfasıyla birlikte bir MCR yuvası olarak depolanır.
 * Aynı sözdizimi, çekirdek ve uzantı mesajları için kullanılabilir.
 * Kaynak mesajları yüklemek ve çevirileri dile göre JSON dosyalarına yazmak için Translate uzantısını geliştirin.
 * Mesajları yüklemek için standart Scribunto kitaplığına Lua işlevleri ekleyin.
 * Translate'in mesaj grubu seçicisinde uygun şekilde görüntülenmek üzere çevrilebilir dosyayı düzenlemek üzere başka bir JSON dosyası kullanın.

Avantajlar

 * Modül ile zarif bir şekilde saklanır.
 * Modül küresel hâle gelirse, veriler de onunla birlikte küresel hâle gelir.
 * MCR yuvaları oluşturmak bazı ayrıcalıklar gerektirebilir, ancak bu muhtemelen sorun değil çünkü yeni mesaj dosyaları oluşturmak zaten tamamen yeni başlayanlar için değil, düzenlemeye hâlâ çoğu editör tarafından erişilebilir.

Dezavantajlar

 * Yuva desteği oluşturmak için biraz geliştirme gerektirecektir.
 * Translate'de yeni bir FFS'nin geliştirilmesi ve sürdürülmesi gerekecektir. MessageLoading'in yanı sıra yeni bir MessageGroup türüne ihtiyacımız olacak.
 * Küresel modüller ve şablonlar çağında, vikilerde yerel olarak nasıl özelleştirileceği belirsizdir.
 * MCR yuva yaklaşımının ortak dezavantajı: İzinler ve geçmiş tamamen karışık. Kod programlama, çevirilerle aynı koruma düzeyine sahiptir, her çevirmenin etkin kodu değiştirmesine izin verilir. Küresel programlamada etkili değişikliklerin tarihi yok, ancak çeviri düzenlemeleri arasında boğuluyor. Koruma ve geçmiş ayrılacaksa, bunlar ayrı sayfalardır ancak MCR değildir.

Açıklama
Yukarıdaki JSON tekliflerine benzer, ancak JSON TemplateData içinde depolanır:


 * Tüm kaynak mesajları, modülü kullanan bir şablonla ilişkili TemplateData'da bir JSON değeri olarak saklayın. Daha büyük bir JSON yapısının parçası olmaktan başka, format, MediaWiki uzantılarında olduğu gibi, dokümantasyon için qqq dahil olmak üzere “banana” formatı ile aynıdır.
 * Aynı sözdizimi, çekirdek ve uzantı mesajları için kullanılabilir.
 * Kaynak mesajları yüklemek ve çevirileri dile göre JSON dosyalarına yazmak için Translate uzantısını geliştirin.
 * TemplateData'yı ve mesajları yüklemek için Lua işlevlerini standart Scribunto kitaplığına ekleyin.
 * Translate'in mesaj grubu seçicisinde uygun şekilde görüntülenmek üzere çevrilebilir dosyayı düzenlemek üzere başka bir JSON dosyası kullanın.

Avantajlar

 * Mevcut TemplateData teknolojisi ile süreklilik.
 * Özellikle TemplateData'nın uluslararasılaştırma için zaten bir desteği vardır, ör. şablon açıklaması birkaç dilde olabilir.
 * Anahtarlar TemplateData düzenleyicisi aracılığıyla yönetilebilir (ancak bunun için düzenleyici kullanıcı arayüzünde güncellemeler gerekir).
 * Teknoloji daha sonrasında şablonlarla da paylaşılabilir.
 * TemplateData, MCR'ye taşınırsa, oraya da taşınır.

Dezavantajlar

 * There is a hard-coded limit of 64 KiB (gzipped) in the TemplateData extension’s code. While this is enough room for something like 700 messages, we have about 400 languages to manage. When using the rate at which MediaWiki core messages are localized, there is room for only 20 messages.
 * Scribunto'ya TemplateData desteği eklenmesini gerektirir.
 * Translate'de yeni bir dosya formatı desteğinin (FFS) geliştirilmesi ve sürdürülmesi gerekecektir.
 * Küresel modüller ve şablonlar çağında, vikilerde yerel olarak nasıl özelleştirileceği belirsizdir.

Açıklama

 * Çekirdek ve uzantı mesajları gibi çevrilebilir mesajları MediaWiki ad alanında saklayın.
 * Viki sayfası olarak depolanan bir JSON veya YAML dosyası kullanarak Translate için mesaj grupları oluşturun. Bu, boşlukla ayrılmış listeler olarak zaten desteklenmektedir (WikiMessageGroup), ancak vikinin içinde grupları tanımlamaya açık bir mekanizma yoktur.

Avantajlar

 * Translate işlemi için çoğunlukla doğaldır (ancak mesaj grubu düzenleyicisi için destek muhtemelen geliştirilmelidir).
 * Mostly natural for Scribunto to process—message loading parsing functions already exist.
 * Can be customized on local wikis when modules become global the same way that messages from core and extensions are customized.

Dezavantajlar

 * Double duty of listing messages as well as creating them separately.
 * Creating the messages will require sysop or edit-interface permissions, making comprehensive module development and bug fixing accessible to much fewer people.
 * Lack of packaging. Many distributed development teams will create and maintain packages of module, global template, accompanied by TemplateData, or JavaScript gadget, but should not conflict in naming between packages of similar targets. Should be bundled per package.

Description
Do it similarly to existing solutions in Module:I18n on Commons and Module:Wikidades/i18n on the Catalan Wikipedia, but:


 * Standardize the Lua table format: Decide whether it is one message key pointing to many translations indexed by language, or language codes pointing to many message keys, etc.
 * Add functions to the Scribunto standard library to load these messages.
 * Add support for reading and writing this file format to Translate.

Avantajlar

 * Lua için doğal.
 * Continuity with at least some existing solutions.

Dezavantajlar

 * This is actual code, which is error-prone and less safe. (We already used to have messages in PHP arrays, and moved away from it.)
 * It’s natural for Lua, but what if Scribunto acquires support for other programming languages? There are recurring requests to support JavaScript, Python, Rexx, etc.
 * Language codes that have hyphens have to be written with square brackets, which is non-obvious and error-prone.

= Proposed solutions comparison table =

Daha fazla bilgi

 * Discuss at Talk:Translatable modules.