RubyOnRails framework’ünün yakın zamanda 2.2 versiyonu çıkmış olacak. Bu versiyonla birlikte Rails, enterprise seviyede iş yapmak isteyenlerin daha önce eksiklik olarak görebileceği bazı problemlerini giderecek. Kapsamlı bir framework olma iddiası taşıyan her proje gibi Rails de olgunlaşma dönemine ancak bir kaç yıl sonra girebiliyor. Vaktimiz ölçüsünde 2.2 ile birlikte gelecek yenilikleri incelemeye devam edeceğiz ancak bu yazımızda, şimdiye kadar Rails’in belirli bir yöntem sunmadığı ve halihazırda çeşitli plugin’ler üzerinden çözüm üretilen, çoklu dil desteği - I18N problemine getirilen yeni yaklaşımları incelemeye çalışacağız.
I18N
Asıl yazımıza girmeden önce, I18N ve L10N tanımlarını biraz açmak istiyorum. Internationalization ve Localization kelimeleri oldukça uzun olduğundan, başlangıç ve son harflerini yazıp, arada kalan harf sayısını da başlangıç ve son harfin arasına yerleştirdiğimizde bu kısaltmalara ulaşıyoruz:
Internationalization: I18N Localization: L10N
IBM ve Microsoft bu iki konsepti birleştirip, Globalization G11N terimini kullanıyor olsa da,
I18N ve L10N’in daha kabul gördüğünü söylemek yanlış olmaz.
I18N, yazılım dilinde bir uygulamaya farklı bir dil desteği eklenmesini işaret ederken, L10N uygulamanın yerelleştirilmesi, belirli bir bölgede (locale) kullanıma uyarlanmasına verilen addır. Örnek olarak, bir uygulamanın İngilizce ve İspanyolca konuşabiliyor olması I18N olarak ifade edilirken, Amerikan İngilizcesi mi yoksa İngiliz İngilizcesi mi ya da İspanya’da konuşulan İspanyolca mı yoksa Meksika’da konuşulan İspanyolca mı olduğuna dair farklar L10N kapsamında adreslenir. Bu bağlamda es_ES İspanya’da konuşulan İspanyolca için bir yerel kodunu temsil ederken, es_MX ise Meksika’da konuşulan İspanyolca’yı işaret etmektedir.
Rails ve I18N/L10N
Bundan tam bir yıl önce, 2007 Eylül’ünde, Rails için I18N/L10N plugin’leri yazmış olan belirli geliştiriciler bir araya gelip, birbiriyle fazla alakası olmayan ve hedefleri/yetenekleri bakımından da pek çok farklılık taşıyan plugin’ler yerine, çoklu dil desteği için temel Rails kütüphanelerine bir takım destekler eklenmesi üzerinde konuşmaya başladılar. Hedef, bu konuda çözüm üretmek isteyen geliştiriciler için, minimalistik bir temelin Rails tarafından sağlanmasıydı.
Mayıs 2008 tarihine kadar yapılan tartışmalardan sonra, ilk kodlar ortaya çıkmaya başladı. I18N/L10N bütün diller için düşünüldüğünde oldukça kapsamlı bir konu olduğundan, tek bir çözüme zorlamak yerine temel desteğin bir Ruby Gem olarak sunulması yöntemi benimsendi. Daha önceki Rails versiyonlarından farklı olarak, 2.2 ile birlikte Rails’in her tarafında I18N desteğinin etkilerini hissedebiliyor olacağız. Örneğin ActiveRecord hata mesajlarını Türkçe’leştirmek için daha önce yapılan ek işlemlere gerek kalmayacak, bu işlemi çok daha sistemli bir şekilde dil dosyaları üzerinden gerçekleştiriyor olacağız.
Rails 2.2 ve yeni I18N desteği
RubyOnRails framework’ünün yakın zamanda 2.2 versiyonu çıkmış olacak. Bu versiyonla birlikte Rails, enterprise seviyede iş yapmak isteyenlerin daha önce eksiklik olarak görebileceği bazı problemlerini giderecek. Kapsamlı bir framework olma iddiası taşıyan her proje gibi Rails de olgunlaşma dönemine ancak bir kaç yıl sonra girebiliyor. Vaktimiz ölçüsünde 2.2 ile birlikte gelecek yenilikleri incelemeye devam edeceğiz ancak bu yazımızda, şimdiye kadar Rails’in belirli bir yöntem sunmadığı ve halihazırda çeşitli plugin’ler üzerinden çözüm üretilen, çoklu dil desteği - I18N problemine getirilen yeni yaklaşımları incelemeye çalışacağız.
I18N
Asıl yazımıza girmeden önce, I18N ve L10N tanımlarını biraz açmak istiyorum. Internationalization ve Localization kelimeleri oldukça uzun olduğundan, başlangıç ve son harflerini yazıp, arada kalan harf sayısını da başlangıç ve son harfin arasına yerleştirdiğimizde bu kısaltmalara ulaşıyoruz:
Internationalization: I18N
Localization: L10N
IBM ve Microsoft bu iki konsepti birleştirip, Globalization G11N terimini kullanıyor olsa da,
I18N ve L10N’in daha kabul gördüğünü söylemek yanlış olmaz.
I18N, yazılım dilinde bir uygulamaya farklı bir dil desteği eklenmesini işaret ederken, L10N uygulamanın yerelleştirilmesi, belirli bir bölgede (locale) kullanıma uyarlanmasına verilen addır. Örnek olarak, bir uygulamanın İngilizce ve İspanyolca konuşabiliyor olması I18N olarak ifade edilirken, Amerikan İngilizcesi mi yoksa İngiliz İngilizcesi mi ya da İspanya’da konuşulan İspanyolca mı yoksa Meksika’da konuşulan İspanyolca mı olduğuna dair farklar L10N kapsamında adreslenir. Bu bağlamda es_ES İspanya’da konuşulan İspanyolca için bir yerel kodunu temsil ederken, es_MX ise Meksika’da konuşulan İspanyolca’yı işaret etmektedir.
Rails ve I18N/L10N
Bundan tam bir yıl önce, 2007 Eylül’ünde, Rails için I18N/L10N plugin’leri yazmış olan belirli geliştiriciler bir araya gelip, birbiriyle fazla alakası olmayan ve hedefleri/yetenekleri bakımından da pek çok farklılık taşıyan plugin’ler yerine, çoklu dil desteği için temel Rails kütüphanelerine bir takım destekler eklenmesi üzerinde konuşmaya başladılar. Hedef, bu konuda çözüm üretmek isteyen geliştiriciler için, minimalistik bir temelin Rails tarafından sağlanmasıydı.
Mayıs 2008 tarihine kadar yapılan tartışmalardan sonra, ilk kodlar ortaya çıkmaya başladı. I18N/L10N bütün diller için düşünüldüğünde oldukça kapsamlı bir konu olduğundan, tek bir çözüme zorlamak yerine temel desteğin bir Ruby Gem olarak sunulması yöntemi benimsendi. Daha önceki Rails versiyonlarından farklı olarak, 2.2 ile birlikte Rails’in her tarafında I18N desteğinin etkilerini hissedebiliyor olacağız. Örneğin ActiveRecord hata mesajlarını Türkçe’leştirmek için daha önce yapılan ek işlemlere gerek kalmayacak, bu işlemi çok daha sistemli bir şekilde dil dosyaları üzerinden gerçekleştiriyor olacağız.