[stringtemplate-interest] Re: ST & I18N

[polina orechko]

Sorry, I did not enable mail delivery, so my response probably won't show up 
in the right thread.

I would like to add my 0.02c to this topic since I was about to ask 
questions similar to Frank's ones.

I was thinking about suggesting
1) adding a special option/flag to StringTemplate (or a special attribute) - 
Locale, which would make ST do some i18n-aware things, more specifically
2) use the standard Java approach for loading locale-specific resources (in 
our case templates) - try first the most specific localized template (again, 
several options are possible, one of them would be to use a naming 
convention, such as myTemplate_en_US.st and the naming convention would be 
activated only by presence of Locale), if not found, try to load 
myTemplate_en.st, and if not found, then use myTemplate.st.

The reasons for this suggestion as opposed to using locale-specific groups 
with messages as Ter has suggested are:
1) in a web app we sometimes would want to localize entire templates, not 
just messages (sometimes we may need layout changes, etc. and it would be 
simpler to do that on "template" level, as opposed to factoring out all 
messages and other locale-dependent things into another level of templates 
and setting a "locale" attribute to switch on it)
2) sometimes we would want to translate only some templates, and some 
templates would be locale independent (such as "a" tag generation)

As far as I understand, this approach would impact only template resolution 
(i.e loading) mechanism.

Just an idea, do you think something along this lines would make sense?

Thanks,
Polina


------------------------------------------------------------------------

On Nov 1, 2005, at 11:30 AM, FrankHarper.10118606 at bloglines.com wrote:

>Hi STers,
>
>I haven't been able to find support in ST for I18N.

Do you mean that the templates cannot contain unicode or that the
error messages from the tool are english only and hardcoded?

>My web app generates URLs on the fly based on user
>input, which can contain non ascii characters. Sometimes I display  the 
>user
>input in a page, and sometimes the same information is used to  create 
>links.
>In this case the the user input has to be url encoded.
>
>The only solution
>I've come up with so far is to create two ST attributes with the  same 
>information,
>one url encoded and one not.

Can you add a renderer mapping from a special URL object so that any
object that is plain string just displays and then any URL gets encoded?

>Then of course there's another whole can of
>worms that will appear when I actually want to translate the web  page 
>contents.
>I guess this will require creating an attribute for each string  that needs
>I18Ning.

I use a StringTemplateGroup to good effect for this.  All error
messages in new ANTLR v3 are in a group for english, one for french,
etc...  I have a switch based upon the locale that loads the
appropriate group and then I use a key like GRAMMAR_NONDETERMINISM
which is or could be mapped to the template name to load.  The tool
knows nothing of the contents...can be unicode or whatever.

>I would like to hear from anyone who has ideas or experience on
>using ST in an I18Ned app, especially if you've come up with more  elegant
>solutions than the ones I've mentioned.

We should come up with a standard recommendation for this...I can add
stuff to the tool to make it work better if need be.

Ter

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/