Hi Sven,
I am happy to hear, that we totally agree on the important items.
We should tackle the problems, as you are describing:
1. use string interpolation instead of concatenation everywhere
> Great, thanks for pointing that out. This is a known issue and I agree
> that we should get that
Hi Vladimir,
On 30.04.2009, at 10:27, geekQ wrote:
> The problem is best visible in the following line:
>
> http://github.com/rails/rails/blob/09a976ac58d2d7637003b92d51637f59f647b53a/activerecord/lib/active_record/validations.rb#L207
>
> full_messages << attr_name +
> I18n.t('activerecord.errors
On Thu, Apr 30, 2009 at 8:27 PM, geekQ wrote:
>
> Hi,
>
> Sven Fuchs wrote:
>> Hi Vladimir,
>>
>> On 27.04.2009, at 18:02, geekQ wrote:
>>> the most important question is, whether the core team would sacrifice
>>> *some* parts of humanize, pluralize and other string concatenation
>>> voodoo, espe
Hi,
Sven Fuchs wrote:
> Hi Vladimir,
>
> On 27.04.2009, at 18:02, geekQ wrote:
>> the most important question is, whether the core team would sacrifice
>> *some* parts of humanize, pluralize and other string concatenation
>> voodoo, especially in ActiveRecord to allow for 100% linguistically
>> c
I've continued playing with this stuff and added an experimental
Gettext backend:
http://github.com/svenfuchs/i18n/commit/fb7fcfff5e94510dbc1cb0b9b12a374c6828fb6f
It extends from the Simple backend, reads PO files using Masao Mutoh's
poparser [1] and simply loads the translations to the stan
Hi Lawrence,
On 28.04.2009, at 08:06, Lawrence Pit wrote:
> I'd use this even without having gettext as the backend.
heh :)
> With helpers you refer to the ability to accept named arguments? Would
> you add that to the _ method or would you do it ruby-gettext style by
> extending String with a
Hi Sven
Nice.
I'd use this even without having gettext as the backend.
With helpers you refer to the ability to accept named arguments? Would
you add that to the _ method or would you do it ruby-gettext style by
extending String with a % method?
(I'd prefer _ to accept the arguments directly
>> For pluralization there could be a similar helper. This should
>> work for all messages that do not contain a dot. I wonder if we
>> can get rid of this limitation. Approaches that come to my mind:
>>
>> 1. Make the scope separator (dot) configurable. That might mean
>> that Rails core
Hi Vladimir,
On 27.04.2009, at 18:02, geekQ wrote:
> the most important question is, whether the core team would sacrifice
> *some* parts of humanize, pluralize and other string concatenation
> voodoo, especially in ActiveRecord to allow for 100% linguistically
> correct translations and smooth,
Hi,
= Executive summary ;-)
the most important question is, whether the core team would sacrifice
*some* parts of humanize, pluralize and other string concatenation
voodoo, especially in ActiveRecord to allow for 100% linguistically
correct translations and smooth, enterprise-ready localization
I forgot to add the "default argument" against "default as keys" as
another pro/contra pair: keys can easily get out of sync. If it's hard
for a developer to come up with a good key for a translation (while
focussing on development) then it's even harder to come up with the
final English m
Hi Hongli,
On 26.04.2009, at 23:35, Hongli Lai wrote:
> The remaining issues are *really* subjective.
> - Putting default translations in the code is clutter in your opinion.
I didn't say it's my opinion :) My role in the Rails I18n group was
more the one of being a moderator.
> - You view th
On Apr 26, 11:13 pm, Sven Fuchs wrote:
> Hi Hongli,
>
> cool, that's a great writeup! Thanks for turning this discussion
> towards more practical points :)
>
> Perhaps it helps when I also add some disclaimer about myself. I'm not
> biased towards or against Gettext in any way, too. I've used
Hi Hongli,
cool, that's a great writeup! Thanks for turning this discussion
towards more practical points :)
Perhaps it helps when I also add some disclaimer about myself. I'm not
biased towards or against Gettext in any way, too. I've used it a lot
a quite some years ago. In fact it was m
(Note: I'm biased towards the Gettext approach, after having used it
to translate desktop applications)
After reading all the replies I think the issue boils down to "default
translations as key" vs "symbols as keys".
"default transactions as key":
1. Pro: lots of existing, mature Gettext tools
Greetings, Folks!
having implemented a few "internationalized" applications with
increasing complexity in the past, I have to agree with some valid
points Vladimir names in his post that do not (yet?) seem to have been
solved in Rails. But let's take a look first at what we as web
developers most
Get this man hooked up to the wagon! It's great to see this level of
thought going into Rails I18n, and equally wonderful to know that his
efforts could positively impact the framework.
On Apr 21, 5:08 am, geekQ wrote:
> We have been working on a Rails application for a big company, that
> will
I noticed that the formatting somehow got screwed up.
You may find the html version easier to read
http://github.com/geekq/rails/blob/854140d9401ee25fae5b5e0f8c1436818507e796/rfc-internationalization.markdown
Regards,
Vladimir
--~--~-~--~~~---~--~~
You received t
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 resultin
19 matches
Mail list logo
