From coutu at snowy-owl.com Mon May 4 14:42:14 2009 From: coutu at snowy-owl.com (Dan Coutu) Date: Mon, 04 May 2009 14:42:14 -0400 Subject: [Locale-dev-en] Localized views are not working correctly. In-Reply-To: <49FA439C.9010706@snowy-owl.com> References: <49FA439C.9010706@snowy-owl.com> Message-ID: <49FF3706.4070005@snowy-owl.com> Well, looks like I solved my own problem. Here's how. The example of how to configure the I18n.supported_locales in the HOWTO doesn't do what I expected, or needed, it to do. That's why I was getting odd results. I had thought that the original code was heading in the direction of setting things up so that the list of supported locales would key off the results of the makemo rake task (whose procedure for creating is really helpful, thanks Masao) that creates directories in the locale directory underneath the RAILS_ROOT. The name of the directories inside the locale directory would be the language/locale values for the supported locales. So here's some code that does what I had expected in the first place: # Tell the supported locales. This is one of the additional settings by Ruby-Locale for Ruby on Rails. # If supported_locales is not set, the locale information which is given by WWW browser is used. # This setting is required if your application wants to restrict the locales. # This technique keys off the subdirectory names of the locale directory to establish the list of # currently supported locales. Specify a plain language name for those cases where the country # specific locale is not needed. Specify a full locale value, such as zh-Hant, for those cases # where it is significant. locale_list = Dir.entries(File.join(RAILS_ROOT, 'locale')) locale_list.delete('.') # Remove current directory notation locale_list.delete('..') # Remove parent directory notation I18n.supported_locales = locale_list It is still necessary to restart the web server after adding new locales. Dan * *Dan Coutu wrote: > I'm using locale-rails-2.0.1 (along with the rest of the 2.0.1 gettext > family of gems) and have the po/mo files working fine with gettext. > The locale code seems to be detecting my web browser locale okay. > > The problem is that my view files are not being properly handled. > Here's an example. > > Set the web browser to a locale of de_DE for German. > > I'm using an initializer like this: > > # This file contains configurable setting for Internationalization > (i18n) support. > # > # Tell the I18n library where to find your translations > I18n.load_path += Dir[ File.join(RAILS_ROOT, 'locale', '*.{rb,yml}') ] > > # Tell the supported locales. This is the one of additional setting by > Ruby-Locale for Ruby on Rails. > # If supported_locales is not set, the locale information which is > given by WWW browser is used. > # This setting is required if your application wants to restrict the > locales. > I18n.supported_locales = Dir[ File.join(RAILS_ROOT, 'locale', > '*.{rb,yml}') ].collect{|v| File.basename(v, ".*")}.uniq > > # Tell the default locale. If this value is not set, "en" is set. > # With this library, this value is used as the lowest priority locale > # (If other locale candidates are not found, this value is used). > I18n.default_locale = "en" > > In my locale directory underneath RAILS_ROOT I have subdirectories > named en, de, and ja. > > My understanding of the above initializer code is that it will set the > I18n.supported_locales to be en, de, and ja. This is what I want. > > It is also my understanding that if I set my browser locale to be > de_DE then after checking the values for supported_locales the current > locale would be 'de' rather than 'de_DE'. My observations of actual > behavior of the code show me that I'm wrong and that the > Locale.current value is actually 'de_DE'. > > So this is all background information so far. > > Here's what is really strange. > > I have view files named: > > index.html.erb > index_de.html.erb > index_ja.html.erb > > When my browser is set to a language other than English, either German > or Japanese, then I continue to see the Enligsh views. > > By experimentation I have discovered that if I change the file name > from index_de.html.erb to index.de.html.erb I then actually get the > German view delivered to my web browser. > > BUT, the MIME type of the view is unknown rather than being > 'text/html' and as a result my web browser will not display the view. > Depending on the browser it either downloads it or has no idea what to > do with the data. > > Something is broken here. The rails locale howto page on yotabanana > clearly specifies the file naming convention as index_de.html.erb but > that doesn't actually work. index_de_DE.html.erb doesn't work either, > I tested that too. > > I either need to have the proper filenames work correctly or else need > to figure out how to get the proper MIME type associated with files > using the index.de.html.erb naming convention. > > Thanks for any help or insight that can be offered! > > Dan > > _______________________________________________ > Locale-dev-en mailing list > Locale-dev-en at rubyforge.org > http://rubyforge.org/mailman/listinfo/locale-dev-en > > From coutu at snowy-owl.com Thu May 14 16:02:04 2009 From: coutu at snowy-owl.com (Dan Coutu) Date: Thu, 14 May 2009 16:02:04 -0400 Subject: [Locale-dev-en] Localized views are not working correctly. In-Reply-To: <49FF3706.4070005@snowy-owl.com> References: <49FA439C.9010706@snowy-owl.com> <49FF3706.4070005@snowy-owl.com> Message-ID: <4A0C78BC.60606@snowy-owl.com> I have updated my gettext, gettext_rails, locale, and locale_rails gems to version 2.0.3. I'm now having a problem with display of view files. This is different from the previous problem. I have views in English, German, and Japanese. The default language is English. I also have PO/MO files for each language. I'm using the locale gem capability to set the locale from the web browser's http_accepted_language value. I am not using any other method to set the locale. If my web browser is configured with only English as an accepted language then I see English PO translations and English views. If my web browser is configured with the languages preference order as English and then German then I see English PO translations and German views. If my web browser is configured with language preferences of German, then English, then I see German PO translations and German views. If my web browser is configured with language preferences of only Japanese then I see Japanese PO translations and English views. If my web browser is configured with language preferences of only German then I see German PO translations and German views. It seems to me that what I'm seeing is that the view being selected is based on the alphabetic order of the language codes where de < en < ja. I believe that I see the English views even when Japanease is the only web browser language selected because English is the default locale. (This is a guess.) The big question is, how do I fix this? I'm trying to figure out if this is a bug in the Rails template selection code or the locale gem's template configuration code. I have included the following in my application layout so that I can inspect the values of what I believe are the key variables: What I see is that the order of locales for the first three is consistently correct with what I would expect. Nothing there is showing 'de' as the first choice when it is not the preferred language. The value for available_locales seems to always be only 'en'. Dan Dan Coutu wrote: > Well, looks like I solved my own problem. Here's how. > > The example of how to configure the I18n.supported_locales in the > HOWTO doesn't do what I expected, or needed, it to do. That's why I > was getting odd results. > > I had thought that the original code was heading in the direction of > setting things up so that the list of supported locales would key off > the results of the makemo rake task (whose procedure for creating is > really helpful, thanks Masao) that creates directories in the locale > directory underneath the RAILS_ROOT. The name of the directories > inside the locale directory would be the language/locale values for > the supported locales. > > So here's some code that does what I had expected in the first place: > > # Tell the supported locales. This is one of the additional settings > by Ruby-Locale for Ruby on Rails. > # If supported_locales is not set, the locale information which is > given by WWW browser is used. > # This setting is required if your application wants to restrict the > locales. > # This technique keys off the subdirectory names of the locale > directory to establish the list of > # currently supported locales. Specify a plain language name for those > cases where the country > # specific locale is not needed. Specify a full locale value, such as > zh-Hant, for those cases > # where it is significant. > locale_list = Dir.entries(File.join(RAILS_ROOT, 'locale')) > locale_list.delete('.') # Remove current directory notation > locale_list.delete('..') # Remove parent directory notation > I18n.supported_locales = locale_list > > It is still necessary to restart the web server after adding new locales. > > Dan > * > *Dan Coutu wrote: >> I'm using locale-rails-2.0.1 (along with the rest of the 2.0.1 >> gettext family of gems) and have the po/mo files working fine with >> gettext. The locale code seems to be detecting my web browser locale >> okay. >> >> The problem is that my view files are not being properly handled. >> Here's an example. >> >> Set the web browser to a locale of de_DE for German. >> >> I'm using an initializer like this: >> >> # This file contains configurable setting for Internationalization >> (i18n) support. >> # >> # Tell the I18n library where to find your translations >> I18n.load_path += Dir[ File.join(RAILS_ROOT, 'locale', '*.{rb,yml}') ] >> >> # Tell the supported locales. This is the one of additional setting >> by Ruby-Locale for Ruby on Rails. >> # If supported_locales is not set, the locale information which is >> given by WWW browser is used. >> # This setting is required if your application wants to restrict the >> locales. >> I18n.supported_locales = Dir[ File.join(RAILS_ROOT, 'locale', >> '*.{rb,yml}') ].collect{|v| File.basename(v, ".*")}.uniq >> >> # Tell the default locale. If this value is not set, "en" is set. >> # With this library, this value is used as the lowest priority locale >> # (If other locale candidates are not found, this value is used). >> I18n.default_locale = "en" >> >> In my locale directory underneath RAILS_ROOT I have subdirectories >> named en, de, and ja. >> >> My understanding of the above initializer code is that it will set >> the I18n.supported_locales to be en, de, and ja. This is what I want. >> >> It is also my understanding that if I set my browser locale to be >> de_DE then after checking the values for supported_locales the >> current locale would be 'de' rather than 'de_DE'. My observations of >> actual behavior of the code show me that I'm wrong and that the >> Locale.current value is actually 'de_DE'. >> >> So this is all background information so far. >> >> Here's what is really strange. >> >> I have view files named: >> >> index.html.erb >> index_de.html.erb >> index_ja.html.erb >> >> When my browser is set to a language other than English, either >> German or Japanese, then I continue to see the Enligsh views. >> >> By experimentation I have discovered that if I change the file name >> from index_de.html.erb to index.de.html.erb I then actually get the >> German view delivered to my web browser. >> >> BUT, the MIME type of the view is unknown rather than being >> 'text/html' and as a result my web browser will not display the view. >> Depending on the browser it either downloads it or has no idea what >> to do with the data. >> >> Something is broken here. The rails locale howto page on yotabanana >> clearly specifies the file naming convention as index_de.html.erb but >> that doesn't actually work. index_de_DE.html.erb doesn't work either, >> I tested that too. >> >> I either need to have the proper filenames work correctly or else >> need to figure out how to get the proper MIME type associated with >> files using the index.de.html.erb naming convention. >> >> Thanks for any help or insight that can be offered! >> >> Dan >> >> _______________________________________________ >> Locale-dev-en mailing list >> Locale-dev-en at rubyforge.org >> http://rubyforge.org/mailman/listinfo/locale-dev-en >> >> > > _______________________________________________ > Locale-dev-en mailing list > Locale-dev-en at rubyforge.org > http://rubyforge.org/mailman/listinfo/locale-dev-en > > From coutu at snowy-owl.com Thu May 14 19:01:07 2009 From: coutu at snowy-owl.com (Dan Coutu) Date: Thu, 14 May 2009 19:01:07 -0400 Subject: [Locale-dev-en] Localized views are not working correctly. In-Reply-To: <4A0C78BC.60606@snowy-owl.com> References: <49FA439C.9010706@snowy-owl.com> <49FF3706.4070005@snowy-owl.com> <4A0C78BC.60606@snowy-owl.com> Message-ID: <4A0CA2B3.5060903@snowy-owl.com> The problem has been found. It is in the locale_rails gem in the file lib/locale_rails/action_view.rb The problem is that it does not account for the case where the view files for the default language have no locale encoding as part of the file name. So I had views named: index.html.erb index_de.html.erb index_ja_JP.html.erb The values of Locale.candidates are: ['en','de'] The logic in action_view.rb does this: Test for the existence of index_en.html.erb, this fails so check the next file. Test for the existence of index_de.herml.erb, this succeeds so return. It never checks for the existence of index.html.erb that corresponds to the default locale. I changed the code logic like this: Locale.candidates.each do |v| file_name = "#{template_file_name}_#{v}" break if I18n.locale.to_common == v begin return find_template_without_locale_rails(file_name, format, false) rescue MissingTemplate => e end end find_template_without_locale_rails(original_template_path, format, html_fallback) Note the break action. I was surprised to see that I had to use to_common rather than to_rfc in order to get a true result from the comparison to v. This change results in the view selection doing what the Rails documentation says should happen for selection of views with I18N. Dan Dan Coutu wrote: > I have updated my gettext, gettext_rails, locale, and locale_rails > gems to version 2.0.3. > > I'm now having a problem with display of view files. This is different > from the previous problem. > > I have views in English, German, and Japanese. The default language is > English. I also have PO/MO files for each language. > > I'm using the locale gem capability to set the locale from the web > browser's http_accepted_language value. I am not using any other > method to set the locale. > > If my web browser is configured with only English as an accepted > language then I see English PO translations and English views. > > If my web browser is configured with the languages preference order as > English and then German then I see English PO translations and German > views. > > If my web browser is configured with language preferences of German, > then English, then I see German PO translations and German views. > > If my web browser is configured with language preferences of only > Japanese then I see Japanese PO translations and English views. > > If my web browser is configured with language preferences of only > German then I see German PO translations and German views. > > It seems to me that what I'm seeing is that the view being selected is > based on the alphabetic order of the language codes where de < en < > ja. I believe that I see the English views even when Japanease is the > only web browser language selected because English is the default > locale. (This is a guess.) > > The big question is, how do I fix this? I'm trying to figure out if > this is a bug in the Rails template selection code or the locale gem's > template configuration code. > > I have included the following in my application layout so that I can > inspect the values of > what I believe are the key variables: > > > > > > > What I see is that the order of locales for the first three is > consistently correct with what I would expect. Nothing there is > showing 'de' as the first choice when it is not the preferred language. > > The value for available_locales seems to always be only 'en'. > > Dan >