# Internationalization examples

**URL:** <https://www.ruby-forum.com/t/internationalization-examples/105308>\
**Category:** Radiant CMS\
**Created:** [May 28, 2007, 6:33pm UTC](https://www.ruby-forum.com/t/internationalization-examples/105308 "2007-05-28T18:33:44Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![lorenjohnson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/b5a626/32.png) [@lorenjohnson](https://www.ruby-forum.com/u/lorenjohnson)\
**Post date:** [May 28, 2007, 6:33pm UTC](https://www.ruby-forum.com/t/internationalization-examples/105308/1 "2007-05-28T18:33:44Z")

</div>

I’m being hired to write a new Extension for handling some basic site  
internationalization needs (admin text won’t be addressed).

We’ve went over a couple of options and for managability we’ve  
decided on creating separate default page parts for each language and  
then overriding find\_page\_by\_url in our extension to select the right  
content to render based upon the browser language type.

I talked with John and Sean both about this approach while at  
RailsConf and they concurred that it would work fine, but it’s not  
going to deliver the right pages with caching on. For the site I’m  
helping on having caching off won’t be detrimental, but I probably  
could also override some of the Radiant caching stuff within the  
extension and have it also working.

John implemented Ruby Language site with internationalization using  
multiple roots under the root (home/english, home/spanish, etc.) This  
approach is cleaner in a couple of ways but is less manageable  
(depending on your use case–if you have different editors for each  
language it would be more manageable).

Has anybody already done a similar thing? Any other approaches worth  
considering?

Does anybody wish to pitch-in on the effort? We will be releasing an  
open sourced version of the resulting extension when I’m done with it  
later this week.

Thanks,

Loren

> **[Resume - Loren Johnson](https://docs.google.com/document/d/1WfJomBItrSA281MMFbYpavEKLMkQAfG9pz0or0X5lBU/edit?usp=sharing)**
>
> LOREN JOHNSON 575-779-9996 | lorenjohnson@gmail.com | github.com/lorenjohnson | linkedin.com/in/johnsonloren EXPERIENCE Senior Software Engineer	April 2020 - Current Hylo.com – Terrans Collective Working full stack in Node, GraphQL, React, and...

---

<div class="post-metadata">

**Author:** ![lorenjohnson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/b5a626/32.png) [@lorenjohnson](https://www.ruby-forum.com/u/lorenjohnson)\
**Post date:** [May 30, 2007, 8:50am UTC](https://www.ruby-forum.com/t/internationalization-examples/105308/2 "2007-05-30T08:50:31Z")

</div>

> approach is cleaner in a couple of ways but is less manageable  
> (depending on your use case–if you have different editors for each  
> language it would be more manageable).
> 
> Has anybody already done a similar thing? Any other approaches worth  
> considering?

I would suggest a combination of the two approaches.

Have a parent page that (virtually) partitions the site into sub-pages  
based on langauges, and then grab out page parts based on language  
extensions:

class LanguagePartitionPage \< Page

def find\_by\_url(url, live = true, clean = true)  
#set a language variable from the url here  
end

def child\_url(page)  
clean\_url(url + ‘/’ + @language + ‘/’ + child.slug)  
end

end

class Page  
def part(name)  
parts.find\_by\_name(name + ‘\_’ + language) ||  
parts.find\_by\_name(name.to\_s)  
end  
end

Deciding how and where to store the langauge var is left as an exercise  
for the reader, but there’s a host of options (stick it in  
the request params, a global var, probably other cleaner methods too).

Dan.