Performance and strftime patches for i18n
Yaroslav Markin
--
Yaroslav Markin
Sven Fuchs
Awesome. It's great to see people already contributing that actively :)
On 01.07.2008, at 20:25, Yaroslav Markin wrote:
> 1. Lookup caching
>
> http://github.com/yaroslav/i18n/commit/f635498819018176b320abe5e2840bfd78881d5c
>
> Does lookup result caching to avoid calling normalize_keys on each
> single lookup.
>
> Benchmarks (500_000 times run, with a simple #translate call):
>
> before
> user system total real
> 35.720000 0.120000 35.840000 ( 36.008942)
>
> after
> user system total real
> 21.360000 0.090000 21.450000 ( 21.675136)
I'm not totally sure about this one. Seems a bit like premature
optimization to me. Of course the #normalize_keys method seems like a
reasonable candidate for optimization. Otoh we don't really know what
needs to be changed until September (when Rails 2.2 is planned).
Any other opinions on this?
> 2. Month names inflection
>
> http://github.com/yaroslav/i18n/commit/c973b0149f0bfb4a77ae5f9e88de97c87162a64e
>
> While I do understand that SimpleBackend must be as simple and "less
> code" as possible, I think this little feature can make it to
> SimpleBackend (instead of creating a new backend for russian language)
>
> Case: (we do it in RuTils gem)
>
> en-US "July 2008" ru-RU "Июль 2008"
> -but-
> en-US "01 July 2008" ru-RU "01 Июля 2008", "Июль" !=
> "Июля"
>
> of course this looks for existence of a corresponding key in
> translation hash.
Wow, yeah. I didn't even remember that Russian has this kind of
special behaviour.
Well, I guess there are lot's of similar exceptions in many languages.
Our goal must be to iteratively come up with flexibility and
abstraction that can cope with all of these. (E.g. Polish
pluralization rules come to mind or Dutch capitalization rules, which
I've just learned about myself: ijsbeer is capitalized to IJsbeer, not
Ijsbeer etc.)
For that reason I'm not positive on including this part of the patch.
Instead I think we need to come up with a good way to collect this
kind of stuff so that we can iteratively come up with solutions for
such customizations per locale that do not interfer with each other.
(For example we might find that including a callback hook into
#localize could solve a lot of issues with customizing the format
string to different languages. But I'd really want to try these things
out in plugins or places that do not go into Rails for now ... because
that could nail us to keep it when people start to rely on it.)
What do you think?
--
sven fuchs sven...@artweb-design.de
artweb design http://www.artweb-design.de
grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone)
d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile)