You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Random Tapestry User <ta...@comcast.net> on 2005/04/06 05:09:30 UTC
L10N Script Component
I ended up writing my own component to localize some key values in
javascript.
I have a persistent menu living in the Border component I created that
all my pages use.
The menu has localized selections on it.
The initialization of the menu (3rd party), sets up the text to go in
the menu entries in the javascript.
Wasn't sure if there was an easier way, but I wrote a component that,
given the following tag in a HEAD element (or anywhere on the page,
really) :
<script jwcid="@L10NScript" language="JavaScript1.2"
type="text/javascript"
keys="menu_SellerMain,
menu_SellerAdvertise,
menu_SellerManageBids,
menu_SellerFAQs,
menu_InvestorMain,
menu_InvestorRegister,
menu_InvestorUpdate,
menu_InvestorFAQs,
menu_FAQsMain,
menu_ContactUsMain"></script>
Takes the keys in the "keys" array, localizes them, and produces the
following JavaScript :
<script language="JavaScript1.2" type="text/javascript">
<!--
if(typeof jsL10N == 'undefined')
{
var jsL10N = new Array();
}
function getL10N(key)
{
var value = jsL10N[key];
if(typeof value=='undefined')
{
value = '[' + key + ']';
}
return unescape(value);
};
jsL10N['menu_SellerMain']='Sell Your House';
jsL10N['menu_SellerAdvertise']='Advertise Your House';
jsL10N['menu_SellerManageBids']='Manage Your Bids';
jsL10N['menu_SellerFAQs']='Home Seller FAQs';
jsL10N['menu_InvestorMain']='Home Investors';
jsL10N['menu_InvestorRegister']='Register With Us';
jsL10N['menu_InvestorUpdate']='Update Your Profile';
jsL10N['menu_InvestorFAQs']='Home Investor FAQs';
jsL10N['menu_FAQsMain']='FAQs';
jsL10N['menu_ContactUsMain']='Contact Us';
//-->
</script>
So script clients need only call getL10N('someKey') to get the
localization for that key.
The value itself is UTF-8 and html character entity encoded to eliminate
any problems with special characters, escape sequences, etc. that can
mess the javascript up.
Does anyone see any problems with this approach, or could suggest one
that's already been done that may be better ?
Thanks in advance,
tappapp
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: L10N Script Component
Posted by Kent Tong <ke...@cpttm.org.mo>.
Random Tapestry User <tappapp <at> comcast.net> writes:
> <![CDATA[...]]>
>
> Do you mean somewhere in my current code I posted ? If so, where ?
Nevermind. It's only useful when you write the javascript in
a .script file.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: L10N Script Component
Posted by Random Tapestry User <ta...@comcast.net>.
Thank Kent,
We're actually utilizing our own localization store backed by a database
and not using properties files at all.
We want our business owners to have immediate access to the localization
store via the application itself and change any and all localizations at
will without any need for deployment.
I know what you mean about using different properties files...but not
sure what you mean about using :
<![CDATA[...]]>
Do you mean somewhere in my current code I posted ? If so, where ?
Or are you referring to using CDATA with the properties files ?
Thanks Kent,
tappapp
Kent Tong wrote:
>Random Tapestry User <tappapp <at> comcast.net> writes:
>
>
>
>>So script clients need only call getL10N('someKey') to get the
>>localization for that key.
>>The value itself is UTF-8 and html character entity encoded to eliminate
>>any problems with special characters, escape sequences, etc. that can
>>mess the javascript up.
>>
>>
>
>it looks fine. But why not use <![CDATA[...]]>?
>
>If you're not using the Script component, then you should
>seriously consider using it.
>
>In fact, the Script component allows you to include a
>javascript file which can be localized. That is, you
>may have setMenuNames.js and setMenunames_jp.js (for
>Japanese) and the correct version will be loaded depending
>on the current locale.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: L10N Script Component
Posted by Kent Tong <ke...@cpttm.org.mo>.
Random Tapestry User <tappapp <at> comcast.net> writes:
> So script clients need only call getL10N('someKey') to get the
> localization for that key.
> The value itself is UTF-8 and html character entity encoded to eliminate
> any problems with special characters, escape sequences, etc. that can
> mess the javascript up.
it looks fine. But why not use <![CDATA[...]]>?
If you're not using the Script component, then you should
seriously consider using it.
In fact, the Script component allows you to include a
javascript file which can be localized. That is, you
may have setMenuNames.js and setMenunames_jp.js (for
Japanese) and the correct version will be loaded depending
on the current locale.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: UTF-8 and the Form component
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
I have done some work to ensure that accented characters are passed
back to my application by adding that ENCTYPE to forms. Adding that
attribute will allow it to pass through to the generated <form> element
just fine. I'm not sure if this should be the default though. What
are the cons to doing so?
Erik
On Apr 5, 2005, at 11:19 PM, Random Tapestry User wrote:
> I'm very new to Tapesty, but not so new to fully localized apps for
> display AND for posting back.
>
> I notice the default Form component creates a form of the following
> syntax :
>
> <form method="post" name="Form0" action="/some/app">
>
> I've worked on many applications that submit form data back in a
> variety of encodings, but using UTF-8 across the board has proven to
> be the most reliable and most all browsers
> seem to have no problem.
>
> However, I always had problems with some browsers if I did not use the
> ENCTYPE="multipart/form-data" on every form irrespective if there's a
> file upload or not to get all the UTF-8 back correctly.
>
> Anyone out there creating apps using double byte, etc, and having no
> problems with Tapestry's default form implementation ?
>
> Thanks,
> tappapp
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: UTF-8 and the Form component : Question for Howard inside
Posted by Random Tapestry User <ta...@comcast.net>.
Nick,
I've seen problems in the past, mainly with IE5, and some of those
issues are described in detail here.
These were of course without using Tapestry.
http://ppewww.ph.gla.ac.uk/~flavell/charset/form-i18n.html
http://nukecops.com/article1481.html
I guess I just adopted the multipart enctype rather than trying to
diagnose problems if they occured with browsers that aren't up to snuff.
So far I too have experienced no problems with request cycles to and
from my local server, pasting in Japanese, etc. with IE and Firefox.
I'm just a little concerned about older browser's implementations (IE5,
nothing older !) and their interaction with Tapestry and using the
default UTF-8 and the default url encoded form post. Also, I would not
be able to test every possible character with my machine.
If you read this Howard, do you have any insight if there's anything
special that needs to be done to accomodate the FULL unicode set in all
forms, or is that already accounted for in your code ?
I work for a group in a large 3 letter company that is considering
adopting Tapestry, in a worldwide project, and this issue would be a
showstopper as virtually every country and codeset are represented in
the application in question.
Regards,
tappapp
Nick Westgate wrote:
> Hi.
>
> I've been developing Tapestry apps involving Japanese content using
> default settings (UTF-8), and have experienced no problems.
> (Well, except OSX IE5 not displaying Japanese UTF-8 in drop downs!)
>
> The apps so far have been for intranets - a good proving ground for me,
> and restricted to just a few browsers for acceptance testing. But my
> next app will be wide open to the net. If you run into any issues,
> I'd sure like to hear about them. Likewise, I'll post if I see any.
>
> Summary: Win IE6 Firefox NN7, OSX Safari Firefox NN7 ok so far.
> OSX IE5 ok bar above.
>
> Do you recall the problems you've seen in the past?
>
> Cheers,
> Nick.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: UTF-8 and the Form component
Posted by Nick Westgate <ni...@key-planning.co.jp>.
Hi.
I've been developing Tapestry apps involving Japanese content using
default settings (UTF-8), and have experienced no problems.
(Well, except OSX IE5 not displaying Japanese UTF-8 in drop downs!)
The apps so far have been for intranets - a good proving ground for me,
and restricted to just a few browsers for acceptance testing. But my
next app will be wide open to the net. If you run into any issues,
I'd sure like to hear about them. Likewise, I'll post if I see any.
Summary: Win IE6 Firefox NN7, OSX Safari Firefox NN7 ok so far.
OSX IE5 ok bar above.
Do you recall the problems you've seen in the past?
Cheers,
Nick.
Random Tapestry User wrote:
> I'm very new to Tapesty, but not so new to fully localized apps for
> display AND for posting back.
>
> I notice the default Form component creates a form of the following
> syntax :
>
> <form method="post" name="Form0" action="/some/app">
>
> I've worked on many applications that submit form data back in a variety
> of encodings, but using UTF-8 across the board has proven to be the most
> reliable and most all browsers
> seem to have no problem.
>
> However, I always had problems with some browsers if I did not use the
> ENCTYPE="multipart/form-data" on every form irrespective if there's a
> file upload or not to get all the UTF-8 back correctly.
>
> Anyone out there creating apps using double byte, etc, and having no
> problems with Tapestry's default form implementation ?
>
> Thanks,
> tappapp
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
UTF-8 and the Form component
Posted by Random Tapestry User <ta...@comcast.net>.
I'm very new to Tapesty, but not so new to fully localized apps for
display AND for posting back.
I notice the default Form component creates a form of the following syntax :
<form method="post" name="Form0" action="/some/app">
I've worked on many applications that submit form data back in a variety of encodings,
but using UTF-8 across the board has proven to be the most reliable and most all browsers
seem to have no problem.
However, I always had problems with some browsers if I did not use the
ENCTYPE="multipart/form-data" on every form irrespective if there's a file
upload or not to get all the UTF-8 back correctly.
Anyone out there creating apps using double byte, etc, and having no problems with
Tapestry's default form implementation ?
Thanks,
tappapp
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org