Hey guys, thanks a lot for you proposal. I think we all agree that rails-i18n can be improved and input on that is highly appreciated.
This is a very long mail, so I'll cut some of it. On 21.04.2009, at 11:08, geekQ wrote: > All our approaches still required extensive monkey patching resulting > in high, unexpected efforts. Could you please list the bits you had to monkey patch, maybe providing some code we can look at? Or does this only refer to AR messages? > The solutions work in 95% of all cases, which is > probably sufficient for most Rails applications, but in our case it > is not. Yes. The initial goal of the rails-i18n project was to a) provide a common API all I18n solutions could build on while b) providing an implementation (simple backend) that works for English. It turned out that this implementation seems to work for (as you say) 95% of all usecases which is much more than we expected. We are currently seeing concurring implementations (backends) which IMO is a good thing but doesn't necessarily mean we need to integrate all of them into Rails core right now. > Often software developers are not able to or are not allowed to create > translations of their applications' texts for several reasons: Agreed. > Important note: non-developers need [tools][poedit] for editing > language files! I agree that currently a solid tool for managing large collections of translations is missing. There are efforts to build such tools though. (E.g. see http://github.com/newsdesk/translate) > Identifying messages by a symbol in a YAML file (like in Rails 2.3) is > problematic, because it breaks the developer's flow: you have to stop > coding, come up with a good identifier (symbol) name for your > message, go to a > YAML file, and type in the message. This is certainly a highly debated topic. We are refering to this as "default translations as keys" vs "symbols as keys". Gettext also embeds "contexts" (scopes) to the default translation. There are several variations of these concepts and there are pros and cons to all of them. You name one of the problems with "defaults as keys": > * For commercial-grade applications the exact wording usually is > controlled by the marketing department. "You don't want to those guys mess with your code." seems like a good reason to use Symbols as keys. Afaik another reason is that the initially picked default translation might need to be changed during the process so there's a risk for keys getting out of sync. Also, with "defaults as keys" there's no way to compute defaults (fallbacks) (which of course affects another highly debated topic: reusing keys). E.g. you can not fallback to :"errors.model.invalid" when :"errors.article.invalid" is missing. In the end we agreed to go with Symbols as keys because we felt that they a) are a better fit for framework needs and b) provides even better means for separating roles (i.e. devs mess with Symbols, translators mess with translations). There's no reason though why you could not add a helper method _() to your application and then use the same syntax as in your examples: > _('Archive is invalid') > _('%{attribute} must not be empty') % attr In Rails I18n Strings can be used as keys. The only drawback here is that you'd need to escape/unescape dots to something else in your _() implementation because they'd be interpreted as scope (context) separators. (This might be an opportunity to improve the API. We've never discussed this further.) > With command line tools such as [msgfmt -cv][msgfmt] you can also > check the > well-formnedess and completeness of your transaltions as part of the > *continuous build process*. This again concerns the tools layer and isn't necessarily related to the API and/or backend implementation. Afaik these Gettext tools rely on the keys not being computed though. E.g. devs must stick to using _('Archive is invalid') instead of _(foo.msg), right? This obviously is a limitation that we might not want to rely on for Rails itself. It might be a perfect fit for userland apps though so I can't see what's holding anybody back from using Rails I18n like this. > ActiveRecord validations support the concept of error messages and > full error messages. From a linguistical point of view this does not > work: there > is no way to infer a correct full message from its short message > counterpart > and vice versa. The string concatenation approach used by Rails > (almost) > works for English but rarely for other languages. I'm actually not sure about the current status of this issue, but it's been a known issue when we implemented Rails I18n. AR error messages were subject to an ongoing discussion at that time so we simply ported the existing functionality even though it's suboptimal. > A message can only be translated as a whole. Hence, it should be > possible to provide custom ActiveRecord validation messages at any > time. For us it > was only possible with [a dirty hack][custom-validation-messages]. Allowing Procs for AR messages seems like a good idea to me. It's not the only place where Rails translates stuff though so it's probably not sufficient for replacing Rails I18n with "something else" (i.e. Gettext in your case). I feel the more appropriate way would be to use the API and use a Gettext enabled backend instead. > *String concatenation should never be used to create human-readable > messages. Use string interpolation instead (as it has been used in > other > frameworks and platforms for decades).* I think we all agree on this. > Of course, a robust pluralization implementation, as provided by > gettext, is important, too. What's wrong or not robust with the current pluralization API derived from CLDR? > All the different localization libraries try to select an appropriate > locale corresponding to their own rules and in a transparent way. The > corresponding logic is often buried deep in the library's > implementation and cannot > be fixed using monkey patching. Rails I18n does not ship locale detection/selection, so there's nothing to monkey patch? But yeah, you're laying out why we decided to leave features like these to plugin land for now. > If the handling of text messages needs to be refactored anyway, it > would be advantageous to switch to the less invasive, proven, and > familiar > gettext syntax: > > _("The billing system is not available. Please, try again later.") > > instead of > > I18n.t(:billing_not_available) > > Providing context for translation: > > "Gadget|Title" => (German) "Bezeichnung" Tbh I don't fully understand how this is less invasive than t('gadget.title', :default => 'Title') It's a bit shorter, sure, but that comes to a price, too. And you can always add your own accessor layer/helper on top of I18n#t, no? > The word "Title" is translated differently depending on its context. > Hierarchical contexts are not needed, that is YAML files with deeper > nesting as in Rails 2.3 do not make sense. You don't need to nest your keys/scopes/contexts if you don't want to. Even the GNU gettext manual though seems to suggest that there are situations where this makes sense: http://www.gnu.org/software/hello/manual/gettext/Contexts.html Am I missing your point here? > The current interface for plugging in different localization storage > backends is a nice intention, but in this case flexibility is not > needed. A > perfectly designed and working backend would be sufficient. That's a strong statement as it suggests that there's a silver-bullet solution for all needs. Our experience with several concurrent I18n solutions in Rails' history rather seemed to suggest the opposite. I believe the way forward can't be to force everbody to use Gettext but instead make sure Rails I18n supports a full stack Gettext solution through the API as seemlessly as possible. That might mean: implement a Gettext backend, provide some helper syntax, maybe make the scope separator configurable. All that said, thanks again for bringing this up! Sven --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
