Re: Localized messages based on property value
Hey,
I'm now using my own implementation of AbstractMessages as I described
in my previous mail. I do exactly the same as in MessagesImpl. The only
difference is that I add something to the baseName argument used in
ResourceBundle.getBundle(baseName, ...).
The selecting of the correct resource bundle works as it should, only
now I'm experiencing something wrong with encoding. All my resource
bundles have UTF-8 set as encoding (languages like German and French use
characters that aren't supported by the default encoding). When using
the binding prefix that I created which uses my implementation of
AbstractMessages for some reason the special characters are not shown
correctly as opposed to the regular binding prefix (${message: ... }).
Anyone an idea what could be happening here that in my implementation
the files are not handled as UTF-8 encoded?
Nathan
On 12/08/15 16:37, Nathan Quirynen wrote:
Hi Thiago,
That's actually a clever solution, but seems a bit "hacky" and I'm not
sure how it will also use the usual Index(_en).properties files?
I solved it at the moment with adding a new binding prefix where i
pass the key and property value like following:
${messagebasedonpropertyvalue:messagekey=property}
Then in the binding implementation I get the resourcebundle based on
the property value and retrieve the message by given key.
This works as I hoped.
I am starting to doubt that having this many properties files for just
1 page/component is the way to go though. Maybe I'll have to move it
to the database or somewhere else.
Thanks for your insight!
Nathan
On 11/08/15 16:33, Thiago H de Paula Figueiredo wrote:
On Tue, 11 Aug 2015 03:29:13 -0300, Nathan Quirynen
wrote:
So I want to have the usual properties file for the page and besides
this for each possible value of a property an extra properties files in
which specific localized messages are located.
So for example an Index page it can have the following:
- Index.properties
- Index_en.properties
- Index_120.properties
- Index_120_en.properties
- Index_130.properties
- Index_130_en.properties
- ...
But when the page loads the value of the property is for example 120
then Index.properties and Index_120.properties wil have to be used.
I hope it is more clear now. So i need to load the messages catalogs
depending on the property value.
I'd try this: @Inject ThreadLocale threadLocale, then in your page's
onActivate() method call threadLocale(new Locale("[current language
code]", [property value]), then use ${message:xxx} or @Inject
Messages as usual. You'd need to revert the naming convention:
instead of Index_130_en.properties, Index_en_130.properties. The idea
is using locale country or even variant, as supported in
Locale(String language, String country) and Locale(String language,
String country, String variant) constructors of java.util.Locale.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Localized messages based on property value
Hi Thiago,
That's actually a clever solution, but seems a bit hacky and I'm not
sure how it will also use the usual Index(_en).properties files?
I solved it at the moment with adding a new binding prefix where i pass
the key and property value like following:
${messagebasedonpropertyvalue:messagekey=property}
Then in the binding implementation I get the resourcebundle based on the
property value and retrieve the message by given key.
This works as I hoped.
I am starting to doubt that having this many properties files for just 1
page/component is the way to go though. Maybe I'll have to move it to
the database or somewhere else.
Thanks for your insight!
Nathan
On 11/08/15 16:33, Thiago H de Paula Figueiredo wrote:
On Tue, 11 Aug 2015 03:29:13 -0300, Nathan Quirynen
nat...@pensionarchitects.be wrote:
So I want to have the usual properties file for the page and besides
this for each possible value of a property an extra properties files in
which specific localized messages are located.
So for example an Index page it can have the following:
- Index.properties
- Index_en.properties
- Index_120.properties
- Index_120_en.properties
- Index_130.properties
- Index_130_en.properties
- ...
But when the page loads the value of the property is for example 120
then Index.properties and Index_120.properties wil have to be used.
I hope it is more clear now. So i need to load the messages catalogs
depending on the property value.
I'd try this: @Inject ThreadLocale threadLocale, then in your page's
onActivate() method call threadLocale(new Locale([current language
code], [property value]), then use ${message:xxx} or @Inject Messages
as usual. You'd need to revert the naming convention: instead of
Index_130_en.properties, Index_en_130.properties. The idea is using
locale country or even variant, as supported in Locale(String
language, String country) and Locale(String language, String country,
String variant) constructors of java.util.Locale.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Localized messages based on property value
On Wed, 12 Aug 2015 11:37:29 -0300, Nathan Quirynen
nat...@pensionarchitects.be wrote:
Hi Thiago,
Hi!
That's actually a clever solution, but seems a bit hacky and I'm not
sure how it will also use the usual Index(_en).properties files?
If you create a Locale(en, 120) and a message isn't found in
Index_en_120.properties, Tapestry will try to find it in
Index_en.properties, and then in Index.properties if not found again, just
like Java resource bundles.
I solved it at the moment with adding a new binding prefix where i pass
the key and property value like following:
${messagebasedonpropertyvalue:messagekey=property}
Then in the binding implementation I get the resourcebundle based on the
property value and retrieve the message by given key.
This works as I hoped.
Yeah, adding your own bindings is a very nice feature of Tapestry. :)
I am starting to doubt that having this many properties files for just 1
page/component is the way to go though. Maybe I'll have to move it to
the database or somewhere else.
A database is good if your messages are dynamic. If they aren't, I'd just
put them inside Index.properties or Index_en.properties, for example, but
using the property value to define the key:
hello=Hi!
hello.120=Hi, 120!
hello.130=Hi, 130!
Then @Inject Messages and use messages.get(hello. + propertyValue) to
get the message, directly in the Java class or through a custom binding.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Localized messages based on property value
On 12/08/15 17:36, Thiago H de Paula Figueiredo wrote:
On Wed, 12 Aug 2015 11:37:29 -0300, Nathan Quirynen
nat...@pensionarchitects.be wrote:
Hi Thiago,
Hi!
That's actually a clever solution, but seems a bit hacky and I'm
not sure how it will also use the usual Index(_en).properties files?
If you create a Locale(en, 120) and a message isn't found in
Index_en_120.properties, Tapestry will try to find it in
Index_en.properties, and then in Index.properties if not found again,
just like Java resource bundles.
Oh, didn't know it worked like that! Thanks for explaining.
I solved it at the moment with adding a new binding prefix where i
pass the key and property value like following:
${messagebasedonpropertyvalue:messagekey=property}
Then in the binding implementation I get the resourcebundle based on
the property value and retrieve the message by given key.
This works as I hoped.
Yeah, adding your own bindings is a very nice feature of Tapestry. :)
I am starting to doubt that having this many properties files for
just 1 page/component is the way to go though. Maybe I'll have to
move it to the database or somewhere else.
A database is good if your messages are dynamic. If they aren't, I'd
just put them inside Index.properties or Index_en.properties, for
example, but using the property value to define the key:
hello=Hi!
hello.120=Hi, 120!
hello.130=Hi, 130!
Then @Inject Messages and use messages.get(hello. + propertyValue)
to get the message, directly in the Java class or through a custom
binding.
Yeah, they aren't really dynamic so that's why i thought they belonged
in properties files. But you are right, I can always use the property
value in the message keys if I want to keep the amount of properties
files low :)
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Localized messages based on property value
Hmm yeah kind of..
So I want to have the usual properties file for the page and besides
this for each possible value of a property an extra properties files in
which specific localized messages are located.
So for example an Index page it can have the following:
- Index.properties
- Index_en.properties
- Index_120.properties
- Index_120_en.properties
- Index_130.properties
- Index_130_en.properties
- ...
But when the page loads the value of the property is for example 120
then Index.properties and Index_120.properties wil have to be used.
I hope it is more clear now. So i need to load the messages catalogs
depending on the property value.
Nathan
On 10/08/15 19:11, mailingl...@j-b-s.de wrote:
Sorry Nathan I do not understand: do you want to spread properties belonging to
one particular page accross multiple property files?
Jens
Von meinem iPhone gesendet
Am 10.08.2015 um 09:08 schrieb Nathan Quirynen nat...@pensionarchitects.be:
Hi,
I have in some pages/components in my Tapestry (5.3.7) application the need to
have localized messages based on some property value.
Simplified example:
Class SomeClass {
String code;
}
In the page I have then a property of type SomeClass and based on this value I
need different localized messages. So I was wondering if message catalog files
like following would be possible:
[name-of-page-or-component]_[some_class_code]_[locale].properties --
Index_123_en.properties
Can I implement some kind of message provider or would it be possible by implementing a binding
prefix SomeClassBinding that i use instead of message: for these cases?
What is the way to go and some pointers on how to implement it are appreciated.
Nathan
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Localized messages based on property value
On Tue, 11 Aug 2015 03:29:13 -0300, Nathan Quirynen
nat...@pensionarchitects.be wrote:
So I want to have the usual properties file for the page and besides
this for each possible value of a property an extra properties files in
which specific localized messages are located.
So for example an Index page it can have the following:
- Index.properties
- Index_en.properties
- Index_120.properties
- Index_120_en.properties
- Index_130.properties
- Index_130_en.properties
- ...
But when the page loads the value of the property is for example 120
then Index.properties and Index_120.properties wil have to be used.
I hope it is more clear now. So i need to load the messages catalogs
depending on the property value.
I'd try this: @Inject ThreadLocale threadLocale, then in your page's
onActivate() method call threadLocale(new Locale([current language
code], [property value]), then use ${message:xxx} or @Inject Messages as
usual. You'd need to revert the naming convention: instead of
Index_130_en.properties, Index_en_130.properties. The idea is using locale
country or even variant, as supported in Locale(String language, String
country) and Locale(String language, String country, String variant)
constructors of java.util.Locale.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Localized messages based on property value
Sorry Nathan I do not understand: do you want to spread properties belonging to
one particular page accross multiple property files?
Jens
Von meinem iPhone gesendet
Am 10.08.2015 um 09:08 schrieb Nathan Quirynen nat...@pensionarchitects.be:
Hi,
I have in some pages/components in my Tapestry (5.3.7) application the need
to have localized messages based on some property value.
Simplified example:
Class SomeClass {
String code;
}
In the page I have then a property of type SomeClass and based on this value
I need different localized messages. So I was wondering if message catalog
files like following would be possible:
[name-of-page-or-component]_[some_class_code]_[locale].properties --
Index_123_en.properties
Can I implement some kind of message provider or would it be possible by
implementing a binding prefix SomeClassBinding that i use instead of
message: for these cases? What is the way to go and some pointers on how to
implement it are appreciated.
Nathan
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Localized messages based on property value
Hi,
I have in some pages/components in my Tapestry (5.3.7) application the
need to have localized messages based on some property value.
Simplified example:
Class SomeClass {
String code;
}
In the page I have then a property of type SomeClass and based on this
value I need different localized messages. So I was wondering if message
catalog files like following would be possible:
[name-of-page-or-component]_[some_class_code]_[locale].properties --
Index_123_en.properties
Can I implement some kind of message provider or would it be possible by
implementing a binding prefix SomeClassBinding that i use instead of
message: for these cases? What is the way to go and some pointers on
how to implement it are appreciated.
Nathan
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
