<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Changes to CacheTranslation</title>
    <description/>
    <link>http://www.motiro.org/en-us</link>
    <language>en-us</language>
    <generator>Motiro</generator>
    <pubDate>Thu, 04 Jan 2007 08:32:20 -0500</pubDate>
    <ttl>60</ttl>
<item><title>Cache translation</title><description>&lt;p&gt;&lt;a href="http://trac.globalize-rails.org/trac/globalize/wiki"&gt;Globalize&lt;/a&gt;, the plugin that
Motiro uses for internacionalization,  stores text on a database (with no
caching by default). Maybe this is making the responses slower that they need to
be.&lt;/p&gt; &lt;p&gt;One of the possible solutions (if this is really a problem, of course) is to put
a caching mechanism in place. Translations could be stored on faster memory once
they get loaded from the database. This can be done using memcached ou another
similar solution.&lt;/p&gt; &lt;p&gt;Another solution is to avoid using Globalize completely. It could be changed for
another pre-packaged Ruby/Rails solution or a home made one. Translation strings
can be stored in-memory when the application server is started (or on the first
request). After that all queries would hit memory directly. This solution has the
hidden bonus advantage of reducing the installation time.&lt;/p&gt; &lt;p&gt;There is a
&lt;a href="http://wiki.rubyonrails.org/rails/pages/InternationalizationComparison"&gt;comparison&lt;/a&gt;
of some other solutions for translation on the Rails' wiki.&lt;/p&gt;</description><pubDate>Thu, 04 Jan 2007 08:32:20 -0500</pubDate><dc:creator>thiagoarrais</dc:creator><guid>http://www.motiro.org/wiki/show/CacheTranslation?revision=2</guid></item><item><title>Cache translation</title><description>&lt;p&gt;&lt;a href="http://trac.globalize-rails.org/trac/globalize/wiki"&gt;Globalize&lt;/a&gt;, the plugin that
Motiro uses for internacionalization,  stores text on a database (with no
caching by default). Maybe this is making the responses slower that they need to
be.&lt;/p&gt;&lt;p&gt;One of the possible solutions (if this is really a problem, of course) is to put
a caching mechanism in place. Translations could be stored on faster memory once
they get loaded from the database. This can be done using memcached ou another
similar solution.&lt;/p&gt;&lt;p&gt;Another solution is to avoid using Globalize completely. It could be changed for
another pre-packaged Ruby/Rails solution or a home made one. Translation strings
can be stored in-memory when the application server is started (or on the first
request). After that all queries would hit memory directly. This solution has the
hidden bonus advantage of reducing the installation time.&lt;/p&gt;&lt;p&gt;There is a
&lt;a href="http://wiki.rubyonrails.org/rails/pages/InternationalizationComparison"&gt;comparison&lt;/a&gt;
of some other solutions for translation on the Rails' wiki.&lt;/p&gt;</description><pubDate>Wed, 01 Feb 2006 00:00:00 -0500</pubDate><dc:creator>thiagoarrais</dc:creator><guid>http://www.motiro.org/wiki/show/CacheTranslation?revision=1</guid></item>  </channel>
</rss>
