[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Web generation + localization.

From: Elf
Subject: Re: [Chicken-users] Web generation + localization.
Date: Thu, 6 Mar 2008 01:30:18 -0800 (PST)

On Thu, 6 Mar 2008, Peter Bex wrote:

On Wed, Mar 05, 2008 at 06:17:05PM -0800, Robin Lee Powell wrote:

So I gots me a web app to write.

I also want to be prepped for other (spoken) languages, for similar
reasons, and because I'm nerdy that way. There are libraries that
will allow insertion of arbitrary Scheme into otherwise normal HTML
files (i.e. spiffy's ssp stuff). There are other libraries that
allow writing a web page as Scheme (i.e. hart).

Does any one have any other suggestions, or preferences amongst
those options, or anything?

I've spent a bit of time thinking about this (unfortunately, no time
to code it up yet).  At work we use Drupal, which simply requires
you to wrap translatable strings with a function call to t(...).
This is a solution that absolutely does not scale well because everytime
it sees a t() call, it hits the database to retrieve the string.
It caches pages, but still we see a lot of overhead in the roundtrips
to the database for uncached pages.

So I've been thinking, if you use sxslt translations (or similar
s-expression based templates), you can first extract all translatable
strings by folding over the template _just_ before you rewrite the
s-expressions to HTML/XML strings, then you do one big query to request
them all at once, and then you insert the strings as needed.


  (head (title (trans "this is a test")))
    (h1 (trans "My first test"))
    (p (trans "we have some testing stuff here"))))

Then, you have one translation step that extracts all the (trans ..)
things, resulting in the list ("this is a test", "My first test",
"we have some testing stuff here") which then can be used in one query
that returns the translations.
After that, you go through the sxml again and replace all (trans "..")
by their translation.

Sorry for the hand-waving - I wouldn't have put this out without code to
back it, but it would be a shame if you would go about it the Drupal way
and then would have to reimplement something.

you can go one further ... apply the list to the proc instead, and you wont
even have repeated list lookups, youll have the final string.

#\space ... the final string

reply via email to

[Prev in Thread] Current Thread [Next in Thread]