RE: [Bodington-developers] i18n res updated : fixed

[Alistair Y. <ali...@sm...>]

> I thought that when I first saw the design, but have since moved to the
> opposite point of view.
you got the cheque then ;)

We had a debate ages ago where either the language specific template
classes had the strings from the Localiser hard coded in them, or they ha=
d
calls to the Localiser instead.

It was decided that the dynamic method would be best as you could then
update the translations without having to recompile the templates. It als=
o
meant I didn't have to do more code to tie properties files into the
timestamp checking process of the template compiler.

I really can't see what the problem is. XmlTemplate is asked to return a
template instance, which is what it's always done. If the template class
doesn't exist or it's out of date, XmlTemplate compiles it. Again, it's
always done that. All that happens now is it adds a language variable int=
o
the process.

So if you're a user with their language preference as "English" you get
template_thingy_en.class. If you're a user with "Russian" you get
template_thingy_ru.class

What Alexis would prefer is English and Russian users get
template_thingy.class which contains logic to query the User object, get
their language preference and load the appropriate strings.

I can't see how that improves on the current design. Every page access
would then have the extra overhead of all that User centric logic.

Alistair



--=20
Alistair Young
Senior Software Engineer
UHI@Sabhal M=F2r Ostaig
Isle of Skye
Scotland

>> From: bod...@li...
>> I think the fact that templates for different languages get
>> compiled is
>> inherently duff. Conceptually, there should be one single
>> generic set of
>> templates that dynamically pull in the resource bundles at run-time.
>
> I thought that when I first saw the design, but have since moved to the
> opposite point of view.  One of the reasons for compiling templates in
> the first place is efficiency, and we have a *lot* of templaces given
> the number of frames and framesets in Bod.  I've come round to the view
> that it probably makes sense* to remove the calls to the property
> retrieval functions from the execution path of each page display.
>
> 		- Peter
>
> * This year.  Moore's Law continues its apparently inexorable
> progress...
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dclick
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>