I am not particularly fond of view.controller.string, because it
scatters the translations around. Nor do I use textmate to help me
with this stuff. I might add __common.view.key as fallback to Mr. T. I
like Mr. T's and Mike's approach very much, because it so nicely
senses where it is. This helps being DRY.
I like my keys to be just that: keys. Not strings to be translated,
but an indication of it's value. Mr. T does support strings as keys
though, but it strips all special characters.
To do attributes I usually include such a t()-method in activerecord:
def t(key, options = {})
self.class.human_attribute_name(key.to_s, options)
end
This way I can do stuff like: @post.t(:title), which is considerably
shorter then human_attribute_name, and translate stuff easily from
within my model.
Doing the i18n stuff effectively is incredibly difficult.
Iain
On Sun, Feb 8, 2009 at 16:55, Hans Marmolin <[email protected]> wrote:
>
> I have solved the problems with keys in somewhat another way. !!!
>
> My solution is based on rake tasks for generating keys for common and
> often used strings as models, attributes, controllers and actions etc
> For other strings I have a textmate bundle that generate the key as
> view.controller.string and in addition adds a string method (my
> extension of the String class) to selected text e.g.
> 'Hans'.to_local_view, 'User'.to_local_model,
> 'Name'.to_local_attribute etc
>
> In this way one do not have to think of keys when coding and the code
> is rather readable as the strings are there together with an
> indication of what kind of strings they are
>
> However, in order to further develop this approach I hade to find out
> the drawback with having
>
> generic keys and many strings in each key. For example one could just
> have the key test.string and then put all strings under that key
> or
> specific keys and few strings in each key. For example I have now the
> key views.controller.action.string and put all view specific strings
> that are not generated by my rake tasks under that key combination
>
> Which solution is to be preferred ?
> The first one may be less effective from a system performance point
> of view ?
> but the second is not DRY as the same words and translations may be
> repeated in many views
>
> What are the differences and similarited between my approach and e.g.
> Ian's approaoch ?
> Could the be combined in some way ?
>
> Any other comments or drawbacks with this approach ?
>
> ____________________________________________
> Hans Marmolin
>
>
>
>
>
>
>
> 6 feb 2009 kl. 00.02 skrev Iain Hecker:
>
>>
>> Hi,
>>
>> I've taken a stab at it, but I'm not really sure if it's the way to
>> go.
>>
>> You can find it at http://github.com/iain/mr.-t
>>
>> I need to refactor it and test it still, but it seems to be not too
>> bad.
>>
>>
>> Iain
>>
>> On Thu, Feb 5, 2009 at 11:16, Coren <[email protected]>
>> wrote:
>>>
>>> On 2 fév, 20:14, Mike Champion <[email protected]> wrote:
>>>> I've been working on i18n'ing our Rails application and have found
>>>> that we started to have lots of similar looking calls to "t
>>>> ('controller.action.name')" sprinkled everywhere in a very un-DRY
>>>> way.
>>>>
>>>> Have others come up with a good convention for a namespace for
>>>> keys to
>>>> be translated?
>>>
>>> Just to say that we came up with the same approach. It's easier to
>>> find its children, but it's very un-DRY. Every similar string on
>>> different views have to be either :
>>> 1) duplicated
>>> 2) transgress the rule and put on a more generic way
>>>
>>> It's a real PITA. And maintaining a flat file without an automatic
>>> tool like rgettext is also a real PITA. We are trying the
>>> i18n::generator, currently, but without success.
>>>
>>>
>>>>
>>>
>>
>> >
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"rails-i18n" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rails-i18n?hl=en
-~----------~----~----~----~------~----~------~--~---
