[Helma-dev] internationalization

Hannes Wallnoefer hannesw at gmail.com
Wed Feb 16 10:07:51 CET 2005


On Tue, 15 Feb 2005 22:47:14 +0100, Christian Langreiter
<chris at langreiter.com> wrote:
> Hannes Wallnoefer wrote:
> >>[1] Passing the string to be substituted to some (user-definable) function?
> >
> > Right.
> 
> http://helma.org/pipermail/helma-dev/2005-February/001678.html
> 
> "The translation function simply gets the string that follows the
> translation marker and has to handle replacements itself;"

I'm sorry, I didn't see that, thought you'd expect Helma to do the
parsing. Could have prevented a minor flame war :-)

> Whether that function interprets the string as a message key or as a
> string containing specially marked-up keys would be of course up to the
> function.
> 
> I absolutely see your point wrt/ proposal 1 (skinning framework performs
> replacements in p/s/d) - that would be nothing but a hack to a fix a
> problem in one particular domain, and a very narrow one at that; I'm not
> 100% fond of option 2 even (specifically the special marker character -
> simply adding an additional parameter à la postprocess="true" or
> translate="true" somehow seems more elegant).
> 
> Wrt/ the inline skins proposed by Tobi [1], I'm in favour of being able
> to pass multiple named skins to a macro (as second parameter, a
> dictionary of skins keyed by name).
> 
> <% handler.foo bar="baz" rab="zab"
>    <skin name="prefix"><ul></skin>
>    <skin name="suffix"></ul></skin>
>    <skin name="default">nothing to see here, move on</skin>
>    <skin name="optionalMessage">
>         Weather's really <% this.weather %> today!
>    </skin>
>    <skin name="itemSkin">
>      <li><% this.name %> is <% this.color %></li>
>    </skin>
> %>
> 
> handler.foo_macro = function( param, skins ) {
>    for ( var i = 0; i < this.size(); i++ )
>      this.get( i ).renderSkin( skins.itemSkin || "defaultItemSkin" );
>    if ( this.weather == "sunny" || this.weather == "foggy" )
>      this.renderSkin( skins.optionalMessage );
> }
> 
> Skins named prefix, suffix and default should be automagically handled
> by the skinning framework (just like p/s/d currently are), with skins
> taking precedence over params.
> 
> Multiple named skin passing would not only solve our I18N problem, being
> able to specify optional skin parts and child skins in that way indeed
> seems very useful too (as Hannes mentioned on Bugzilla).
> 
> I haven't thought much about fully nestable skins yet; I'm not sure
> they're really necessary, the current skin/macro system is sweet, simple
> and sufficient for basically every skinning task I've encountered so far.

I'm thinking along these lines, too. But I tend to pass all the nested
content of the macro as just one skin parameter, and rather provide a
method in the skin class to look up sub-skins by name. I also worked
in Robert's and Matthias' proposal for i18n of skin text without
macros, and what I currently came up with is this: We use plain
HTML/XML syntax and don't introduce any Helma-specific tags, just
three attributes:

* h:macro is used to mark a tag as macro. Any tag containing a h:macro
attribute will be replaced by the output of that macro, with the
contents of the tag passed to the macro function as second argument.

* h:name is used as identifier of subskins within a skin. Any names
can be used, but "prefix", "suffix" and "default" are handled in the
way Helma currently does.

* h:msg is used for automatic translation as proposed by Robert and
Matthias. Everything within those tags would be replaced by a
localized message (details to be determined).

Put into practice, a simple macro that loops through stories in a site
object could look like this:

<div h:macro="site.loop">
   <h3 h:name="prefix" h:msg="storylistHeader">Story Listing</h3>
   <ul>
     <li h:name="listitem" h:macro="story.title">Story Title</li>
   </ul>
   <p h:name="default" h:msg="storylistEmpty">No stories</p>
</ul>

All the macro had to do here is get the "listitem" subskin and call it
on each story it wants to render. prefix and default are handled by
Helma. The only unsolved piece here is how to render the <ul></ul>,
but I think Helma could do automatic parent element rendering by using
a "skin stack" to know when it enters/leaves a skin fragment.

So far this looks pretty good to me, but I haven't had coffee yet
today. What do you think?

Hannes

> -- Chris
> 
> [1] http://helma.org/bugs/show_bug.cgi?id=408
> 
> _______________________________________________
> Helma-dev mailing list
> Helma-dev at helma.org
> http://helma.org/mailman/listinfo/helma-dev
>


More information about the Helma-dev mailing list