<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Internationalisation in edge Rails</title>
	<atom:link href="http://cameronyule.com/2008/07/internationalisation-in-edge-rails/feed" rel="self" type="application/rss+xml" />
	<link>http://cameronyule.com/2008/07/internationalisation-in-edge-rails</link>
	<description>Glasgow based new media developer Cameron Yule.</description>
	<pubDate>Fri, 21 Nov 2008 14:05:20 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Cameron</title>
		<link>http://cameronyule.com/2008/07/internationalisation-in-edge-rails#comment-99</link>
		<dc:creator>Cameron</dc:creator>
		<pubDate>Wed, 23 Jul 2008 19:03:05 +0000</pubDate>
		<guid isPermaLink="false">http://cameronyule.com/?p=82#comment-99</guid>
		<description>Hi Thomas. Yeah, you might be right about the way Globalite stores it's translation files in YAML not changing - I guess from an existing-user point of view that'd make sense. 

The reason I mentioned using ruby files (aside from the benefits I mentioned in the post) was that the new 'simple' back-end that Rails uses to localise to en-US is using ruby files also.

Probably some as-yet unreleased plugin which functions similar to Globalite will appear and I'll move to that.

As you say - good news indeed. :)</description>
		<content:encoded><![CDATA[<p>Hi Thomas. Yeah, you might be right about the way Globalite stores it&#8217;s translation files in YAML not changing - I guess from an existing-user point of view that&#8217;d make sense. </p>
<p>The reason I mentioned using ruby files (aside from the benefits I mentioned in the post) was that the new &#8217;simple&#8217; back-end that Rails uses to localise to en-US is using ruby files also.</p>
<p>Probably some as-yet unreleased plugin which functions similar to Globalite will appear and I&#8217;ll move to that.</p>
<p>As you say - good news indeed. :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thomas Nichols</title>
		<link>http://cameronyule.com/2008/07/internationalisation-in-edge-rails#comment-98</link>
		<dc:creator>Thomas Nichols</dc:creator>
		<pubDate>Wed, 23 Jul 2008 18:06:21 +0000</pubDate>
		<guid isPermaLink="false">http://cameronyule.com/?p=82#comment-98</guid>
		<description>We're using Globalite too, and loving it (apart from occasional weird __localization_missing__ errors). IIUC, though, the rails i18n support isn't going to change the way the backend works; I'm guessing our existing :hello.l calls will need to change to :hello.t and similar API changes, but that the backend will stay the same. 

It seems "Hello {name}" becomes "Hello {{name}}", but otherwise it looks as though our existing translated yamls won't need much tweaking. And if you don't like yaml, you'll be able to switch to GeText po/mo files or use Globalize and shove it all in the db. Looks like good news to me.

-- Thomas.</description>
		<content:encoded><![CDATA[<p>We&#8217;re using Globalite too, and loving it (apart from occasional weird __localization_missing__ errors). IIUC, though, the rails i18n support isn&#8217;t going to change the way the backend works; I&#8217;m guessing our existing :hello.l calls will need to change to :hello.t and similar API changes, but that the backend will stay the same. </p>
<p>It seems &#8220;Hello {name}&#8221; becomes &#8220;Hello {{name}}&#8221;, but otherwise it looks as though our existing translated yamls won&#8217;t need much tweaking. And if you don&#8217;t like yaml, you&#8217;ll be able to switch to GeText po/mo files or use Globalize and shove it all in the db. Looks like good news to me.</p>
<p>&#8211; Thomas.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.204 seconds -->
<!-- Cached page served by WP-Cache -->
