Ruby Forum Radiant CMS > Japanese and i18n in Radiant

Posted by Oli Studholme (Guest)
on 02.08.2008 03:47
(Received via mailing list)
Hi All,

[sorry if this ends up being a double-post]
I’ve been having lots of fun with making a bilingual site in
Radiant. Here are some current problems that I hope someone can
suggest fixes for:

# Pages in Shift-JIS charset

Most Japanese cellphones require Shift-JIS for mobile sites, but the
content-type field in Layout ignores charsets. Can anyone suggest how
I’d add support for charsets to this, or another way to work
around it?

# Mailer extension and sending ISO-2022-JP emails

Despite ActiveMailer docs[1] containing this:
“default_charset - The default charset used for the body and to
encode the subject. Defaults to UTF-8. You can also pick a different
charset from inside a method with charset.”

Setting this in environment.rb:

    config.action_mailer.default_charset = "iso-2022-jp"

still results in my email header and body being UTF-8 encoded, with
body settings of:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: Quoted-printable

If I add this to environment.rb:

      config.action_mailer.default_content_type = "text/
plain;charset=iso-2022-jp"

I get the bizarre combo of utf-8 encoded subject and body settings of:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: Iso-2022-jp

which is even worse. A Japanese article[2] suggests wrapping
ActionMailer in TMail then iso-2022-jp and base64 the email, but I
guess that requires a hack or an extension, right? here’s their
code:

module ActionMailer #:nodoc:
   class Base
     require 'nkf'
     class << self
       def base64(text, charset="iso-2022-jp", convert=true)
         if convert
           if charset == "iso-2022-jp"
             text = NKF.nkf('-j -m0', text)
           end
         end
         text = [text].pack('m').delete("¥r¥n")
         "=?#{charset}?B?#{text}?="
       end
     end
   end
end

class Notifications < ActionMailer::Base
   @@default_charset = "iso-2022-jp"
   @@encode_subject = false
   #...
end
Then in test:

class NotificationsTest < Test::Unit::TestCase
   CHARSET = "iso-2022-jp"
   #...
   private
     def encode(subject)
       ActionMailer::Base.base64(subject, CHARSET)
     end
end

Anyone ever managed to get emails in non-UTF8 working

Finally, what’s up with i18n and how can I help? I can’t
even get the Jargon branch (with the partially baked gibberish
support) to run anymore…

peace - oli

[1] http://api.rubyonrails.org/classes/ActionMailer/Base.html
[2] http://wiki.fdiary.net/rails/?ActionMailer
Posted by Casper Fabricius (Guest)
on 02.08.2008 20:19
(Received via mailing list)
Hi Oli,

I'm also faced with a Radiant that needs to run two multiple
languages, however, non of them Japanese, so can't help you there.

But I'm eager to hear if you have found a fitting extension for
handling multiple languages. I'm considering using Loren Johnson's
language switch 
(http://github.com/lorenjohnson/radiant-language-switch/tree/master
), but maybe there is something better or different or more advanced
out there?

Cheers,
Casper Fabricius
Posted by Jim Gay (Guest)
on 02.08.2008 21:28
(Received via mailing list)
Oli and Casper,

I would love some assistance getting Radiant on Rails 2.1
Rails edge has some localization and translation features built in, so
moving to 2.1 would get us there faster (I hope).

If you'd like to help, please fork my rails_2_1_0 branch and contribute:
http://github.com/saturnflyer/radiant/tree/rails_2_1_0

I've only had the time to get so far with it, so assistance would be
greatly appreciated.
So this isn't a fast solution for the problems you're trying to solve,
but I hope it'll be good for the long term of Radiant development.

-Jim
Posted by Mohit Sindhwani (Guest)
on 03.08.2008 16:19
(Received via mailing list)
Casper Fabricius wrote:
> there?
I do handle multiple languages on my site using a rather simple
extension that I wrote to create a language bar based on some naming
conventions that I follow.  That said, I think all the content is in
UTF-8.  So, I may not be able to help here.

What exactly is it that you're looking for?

Cheers,
Mohit.
8/3/2008 | 10:17 PM.
Posted by Oli Studholme (Guest)
on 04.08.2008 04:42
(Received via mailing list)
Hey Casper,

On Aug 3, 2008, at 3:19 AM, Casper Fabricius wrote:

> I'm eager to hear if you have found a fitting extension for handling  
> multiple languages. I'm considering using Loren Johnson's language  
> switch (http://github.com/lorenjohnson/radiant-language-switch/tree/master 
> ), but maybe there is something better or different or more advanced  
> out there?

I’m using the Language Redirect extension:
https://svn1.hosted-projects.com/medlar/language_redirect_extension/

You create language code root articles (/en, /ja etc) and build your
localised site under there. When a user visits the domain root,
they’re automatically redirected to one of the localised roots
based on browser’s accept language. This doesn’t work
well with the automatic breadcrumb tag though (you get the site root
and the locale root, which end up pointing to the same thing).

Another option is the translator extension:
http://dev.philburrows.com/svn/radiant-extensions/translator/trunk/README

It seems you create a page part for each language, then the extension
displays the relevant part based on browser’s accept language or
session variable.

There might be some more info in the mailing list archives

peace - oli
Posted by Casper Fabricius (Guest)
on 06.08.2008 09:52
(Received via mailing list)
Hi Jim,

Definitely a great initiative to get Radiant on 2.1. If you could add
some kind of status and list of bugs and stuff to do perhaps on the
Github wiki, I'd like to contribute.

However, I don't think the i18n stuff in edge will be of much help
when it comes to translating Radiant pages. There will still need to
be an extension that allow users of Radiant to translate inside the
Radiant admin one way or another. That extension could, and should,
use the standardized i18n interface, but the approach and an
appropriate backend will still be up to the extension developer to
select.

Cheers,
Casper
Posted by Jim Gay (Guest)
on 06.08.2008 13:34
(Received via mailing list)
Casper,

I'll definitely do that and post back when I do. Probably by next week.
Rails Edge I18n bits won't solve the problem, but it'll be a step in
the right direction.
Posted by Casper Fabricius (Guest)
on 06.08.2008 14:02
(Received via mailing list)
Hi Oli,

Three extensions, three different approaches to translation:

Language Redirect: Separate site trees for each language.
Translator: Separate page parts for each language, but a single site
tree.
Language Switch: All translations in the same page and part, separated
by tags that indicates the language.

Language Redirect seems to be the most widely used, and the way to go
if you want different site trees for different languages, i.e. only
translate a subset of pages. I also like that it is very compact and
has clean code. On the other hand, it seems quite messy to have to
keep several different site trees in sync.

Language Switch gives you the "clean" site tree and "clean" use of
page parts, but on the other hand you need to use the tags indicating
language all over. Also, this extension completely disables all
caching at the moment.

I think I'm gonna go with Translator for now. Since I only need to run
the site in two languages, and I only have two page parts per page, it
won't be too cluttered when editing a page. This extension also seems
to handle caching quite well, although it happens through some pretty
hackish code that might break Radiant at some point.

This is yet another example of the fact that when it comes to i18n and
l10n, one solution never seems to fit all.

Cheers,
Casper
Posted by Keith Bingman (kbingman)
on 06.08.2008 14:08
(Received via mailing list)
I just went with Translator and really liked it. I had built several
pages with Language Redirect, which was one of the first Radiant
behaviours.

I think that the page part solution is the best, both for building the
site and maintaining it. It also makes switching the language, but
keeping the same content trivial. Two page trees is a bit hard to
maintain, but is of course the most robust system.

But I agree, once again, not a one size fits all situation.

Keith