in reply to Multilingual Mason

One way I see is to extend Mason syntax using the preprocess option of HTML::Mason::Compiler. Mason authors suggest instead to extend the compiler; there is an example of such method in chapter 6 of Embedding Perl in HTML with Mason.

On the other hand, I don't understand why you don't have separate pages for every language you need to display. Isn't it better to use Mason components and override portions of your pages locally? Or you can extend HTML::Mason::Resolver and make it search components in different paths for every language (refer to the aforementioned chapter 6 of the Mason book).

HTH, Valerio

Replies are listed 'Best First'.
Re: Re: Multilingual Mason
by crenz (Priest) on May 03, 2003 at 12:23 UTC

    Thanks for the suggestions! I will check them out.

    I don't understand why you don't have separate pages for every language you need to display.

    Different component paths for different languages make lots of sense -- it's a good idea that I will use for headers, footers etc.

    However, I previously (years ago) used a system that used different files for different languages, and it's a maintenance nightmare. It's easy to do the initial translation: Just copy en/some.html over to de/some.html and replace all English text with the German translation. However, to make changes, you first change it in one version, then you open the other file, search all the way down to the place where you want to change something, insert the new translation, forget half of the new stuff that you wrote, forget the other change that you made etc.

    I'm much happier with the current approach -- it saves me a lot of time and helps me prevent stupid mistakes.

        As I said, I like the idea of using components for small blocks of text: Headers, footers, menu items etc. I don't like the idea of doing that for large chunks of text (e.g. paragraphs in a lengthy article). And the problem is -- my webpage is composed mostly of larger chunks of text... I could use a component to retrieve the article, but then I end up with n component files for n languages again.

        With the help of your links, I found Locale::Maketext, which looks very interesting (even more than gettext). Class::Phrasebook might also be useful, but is less versatile. I also found two interesting articles: Localizing your perl programs and Localizing open source software. Especially the first one demonstrates the dilemma of internationalization rather well (and we haven't even talked about localization yet!). I'm glad I only have to handle two languages (maybe three later).

      most of the multi-lingual sites that i've seen (not many :) use some kind of macro/make pre-formatter that adjusts the "code" only of the other language versions after you edit the code of say English. this makes for very boring code, as fancy code is kept well away from (language) string assigment, but it does keep things in order. btw use posix character class translations for any s/// m// tr/// etc. a-z --> A-Z doesn't fare that well on Chinese characters. Chris