Once again, sorry for the delay. We didn't drop the ball and are still
working on a proposal. We have one more meeting scheduled for
tomorrow. Things look quite good and since we came to a consensus, I
believe we should be done soon.
We'll keep you posted.
- Matt
On Oct 24, 1:12 pm, "Matt Aimo
Sorry, we got together few times, but I'm in the middle of the San Diego
fires so we had to postpone our meetings. We are really close to a proposal,
just working on the details.
-Matt
--
http://railsontherun.com
On 10/24/07, Mislav Marohnić <[EMAIL PROTECTED]> wrote:
>
> O
On 10/5/07, Matt Aimonetti <[EMAIL PROTECTED]> wrote:
>
>
> FYI people a bunch of us got together today to discuss the proposed
> API.
>
> Globalize, Simple Localization and GlobaLite plugins were represented.
> We had a good discussion and tried to come to an agreement and a
> suggestion for the c
FYI people a bunch of us got together today to discuss the proposed
API.
Globalize, Simple Localization and GlobaLite plugins were represented.
We had a good discussion and tried to come to an agreement and a
suggestion for the core team. We will meet one more time next week to
finish the discuss
On 10/4/07, Matt Aimonetti <[EMAIL PROTECTED]> wrote:
>
> Thanks Jeremy but I'm not sure understand your point. Are you
> suggesting to use symbolized strings?
I'm not really suggesting anything. I'm just demonstrating that
string keys are no more expressive than symbol keys, assuming you use
ap
Thanks Jeremy but I'm not sure understand your point. Are you
suggesting to use symbolized strings?
-Matt
On Oct 4, 12:40 pm, "Jeremy Evans" <[EMAIL PROTECTED]> wrote:
> On 10/4/07, Chris Cruft <[EMAIL PROTECTED]> wrote:
>
> > Once you solve the problem of changing keys, string keys have some
>
On 10/4/07, Chris Cruft <[EMAIL PROTECTED]> wrote:
> Once you solve the problem of changing keys, string keys have some
> nice properties -they are expressive and tend to convey enough meaning
> that a translator doesn't need to search around a lot to translate
> it. Of course you could do the sa
Julian has noted disatisfaction with string keys, but I suspect he
didn't use a dummy language...
I'm a big believer that the "dummy language" approach is very
effective. While the concept's name leaves a bit of a sour taste in
your mouth ('dummy'), the concept provides a great ability to
segreg
> But that's not special to Strings-as-keys and Symbols-as-keys do not solve
> this.
Sven, I think you missed the point. The issue with Strings-as-keys is
that most of the time you use real sentences as keys, usually in your
'base' language. That's where the problem is.
It's not really a technic
Guys,
Strings-as-keys are really just keys, like Symbols-as-keys are. (I.e.
they are used to lookup your translation.) You get into trouble when
you change your keys (something we know from elsewhere). But that's
not special to Strings-as-keys and Symbols-as-keys do not solve this.
Am 04.
I fully agree Julian.
We are going to have an IRC meeting on Thursday 4 at 17:00 UTC / 19:00
UTC+2 (Barcelona) / 1pm EST at #globalize over on freenode.net to
discuss the API. (at least 3 l10n rails plugin teams will try to find
a compromise to provide Rails with an awesome localization API)
Fee
On 3-okt-2007, at 4:13, Matt Aimonetti wrote:
> Let's say we use English strings as base for localization and out
> string looks like: 'There were problems with the following fields:'.
> The string itself becomes the translation key or translation reference
> if you will. Each language will use
Hey Saimon,
I hope you feel better. Thanks for clarifying few details and thanks
for generating this healthy discussion.
Since we are talking about the core localization, we obviously have to
talk about it's internationalization.
I have a problem when we use real language strings as translati
Hi all,
Sorry for my delayed response (I was feeling a bit under the weather).
I'm very happy that our patch is receiving this kind of attention as
it shows that a lot of people are seriously interested in i18n hooks
appearing in rails core.
Also the main reason we decided to add the patch (in
> This view is shared by all of us, and as you can see, the patch by no
> means forces you to do anything,
> since you can override the method completely.
That's exactly my point, I should not have override anything, that's
exactly what we are doing with Rails atm and the whole purpose of this
pa
>
>
> To sum up mu thoughts, I'm 200% for a localization API/hook so we
> wouldn't have to monkey patch the core every time you guys change
> something. But honestly, having a diversity of localization solutions
> is awesome and I would hate to see this new API/hook forcing people to
> do things a
I guess we should keep on the discussion here instead of on Track.
My points were:
- I'm ok with a translation hook that could be used by all translation/
l10n plugins.
- String#t isn't clear enough and should be named String#translate or
something more obvious (you can always use alias in your
> I just added a ticket (http://dev.rubyonrails.org/ticket/9726) with a
> very rough proposal of how a i18n plugin-agnostic api for rails may
> look like. I've added details in the ticket so all those interested
> please read that and provide as much feedback as possible.
There are a few comments
On 28-sep-2007, at 22:02, Mislav Marohnić wrote:
> This is great! Kudos to you and Corp.
Oh my. I so heart that.
--
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl
--~--~-~--~~~---~--~~
You received this message because you are subscri
On 9/28/07, saimon <[EMAIL PROTECTED]> wrote:
>
>
> I just added a ticket (http://dev.rubyonrails.org/ticket/9726) with a
> very rough proposal of how a i18n plugin-agnostic api for rails may
> look like. I've added details in the ticket so all those interested
> please read that and provide as muc
20 matches
Mail list logo
