> introducing this is to write a plugin that will monkey patch rails
> core and provide the no-op api for l10n plugins. Once we do that we
> can sell it to all the l10n plugin devs and try to standardize around
> it. If we've got that going, it will look a lot more attractive to
> rails core dev
This is essentially the idea I was promoting. I think a good way of
introducing this is to write a plugin that will monkey patch rails
core and provide the no-op api for l10n plugins. Once we do that we
can sell it to all the l10n plugin devs and try to standardize around
it. If we've got that goi
Why not have RoR define a reference set of modules and class (call it
i18n for now) whose API implements the most basic i18n methods with no
real functionality? Then the plugins could flesh out the
functionality. I know this is pretty simplistic, but we need to start
somewhere. As RoR evolves,
> Nothing fancy, nothing specially designed to help l10n/i18n plugins
> but just to avoid patching the core methods. (extending is fine)
Provided there are no adverse performance or understandability
impacts, I think we could apply a patch which refactored the core code
a little. If a little bit
Alright, that's exactly what I wanted to avoid... a long thread about
how the core should deal with localization :(
I don't think the core team should adopt a .t method or another way of
dealing with translation. That's really up to the plugin developers to
decide.
What I would like to see is sim
Alright, that's exactly what I wanted to avoid... a long thread about
how the core should deal with localization :(
I don't think the core team should adopt a .t method or another way of
dealing with translation. That's really up to the plugin developers to
decide.
What I would like to see is sim
I understand that many people won't get use out of 't', but I think
the extra work involved (we're talking about an extra charcter, and
letting the people who care submit patches to clean up what's already
there) is trivial in comparison to what is gained here. It means that
i18n efforts can hook
Is it possible to auto-extract strings like Heckle?
Doing so it would be very easy to lookup for translatable strings and
no change to core would be needed.
Marcello
On May 23, 12:36 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> +1
>
> I don't want to get into details yet, but I agree tha
Is it possible to auto-extract strings like Heckle?
Doing so it would be very easy to lookup for translatable strings and
no change to core would be needed.
Marcello
On May 23, 12:50 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> On 5/23/07, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
>
>
Is it possible to auto-extract strings like Heckle?
Doing so it would be very easy to lookup for translatable strings and
no change to core would be needed.
Marcello
On May 23, 12:50 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> On 5/23/07, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
>
>
Is it possible to auto-extract strings like Heckle?
Doing so it would be very easy to lookup for translatable strings and
no change to core would be needed.
Marcello
On May 23, 12:50 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> On 5/23/07, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
>
>
On 5/23/07, Joshua Sierles <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > It seems the best bet is to leave the concern entirely outside rails
> > itself, until the current disparate efforts can be folded into a
> > single 'best practise'. Failing that, perhaps it's something where
> > there isn't a
Michael Koziarski wrote:
>> Well, each i18n plugin would override String#t to actually translate
>> the validation message. Anybody who doesn't want i18n just uses Rails
>> as usual. But anyone who does want to translate, just adds their
>> localization plugin of choice, which now can automaticall
>
>
> It seems the best bet is to leave the concern entirely outside rails
> itself, until the current disparate efforts can be folded into a
> single 'best practise'. Failing that, perhaps it's something where
> there isn't a solution which suits 'most of the people most of the
> time'.
>
>
On 5/23/07, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
>
> But String#t, or anything else, would be entirely redundant without
> localisation code in rails right? Adding a bunch of method
> invocations for no new functionality doesn't seem like a good trade :)
Is this the opinion of the whol
> Well, each i18n plugin would override String#t to actually translate
> the validation message. Anybody who doesn't want i18n just uses Rails
> as usual. But anyone who does want to translate, just adds their
> localization plugin of choice, which now can automatically translate
> all of the Rail
On 5/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> Well, each i18n plugin would override String#t to actually translate
> the validation message. Anybody who doesn't want i18n just uses Rails
> as usual.
That made sense to me right from the start. It's crude, but would lift (some
of)
Well, each i18n plugin would override String#t to actually translate
the validation message. Anybody who doesn't want i18n just uses Rails
as usual. But anyone who does want to translate, just adds their
localization plugin of choice, which now can automatically translate
all of the Rails validati
> I personally think that localization should be included in the core
> and maintained by the core team. Obviously they wouldn't be able to
> translate the core themselves.
This has come up repeatedly, and it is unlikely that rails' core will
be localised. We only want something there which f
> I personally think that localization should be included in the core
> and maintained by the core team. Obviously they wouldn't be able to
> translate the core themselves.
This has come up repeatedly, and it is unlikely that rails' core will
be localised. We only want something there which f
> The end user could then choose to use any i18n
> plugin he wants, and everything would be available for translation
> with no monkey-patching needed. This in itself would be a huge step,
> and I don't see a lot of downside. Localizing dates and countries
> could also be done much the same way.
On May 22, 2007, at 3:36 PM, [EMAIL PROTECTED] wrote:
> The idea would be for Rails core
> to overload String#t with a method that simply returns the original
> string, i.e. a no-op.
Most sentences can't be localized with just a word by word
translation. I don't think this will solve the probl
+1
I don't want to get into details yet, but I agree that the main issue
is agreeing on a standard for view translation that all plugins will
have to support. In Globalize, this would be: 'Validation Error'.t,
instead of simply 'Validation Error'. The idea would be for Rails core
to overload Stri
23 matches
Mail list logo
