Yeah, I was also thinking that translation arguments would be needed -
and I was thinking exactly the same thing re: the lookup.
I'll try to come back around to implement some of this stuff, perhaps
next week, unless you guys get to it first. I'll make sure to ping you
guys before I start anything.
-Eric
On 04/09/2013 07:30 PM, Christian Sadilek wrote:
I like the idea of enriching the bundles in this way for
programmatic
lookup. It's simpler than the alternative of doing something like GWTs
built-in message support using interfaces:
http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gw...
Yes, our IDE won't help us detecting invalid keys but we can still fail
at compile time and add tooling support for it later. We'd probably need
to implement some of GWTs message features though like message arguments.
So, that a translation value (e.g. "inbox-messages") could be:
"You have {0} unread messages in your inbox"
"Sie haben {0} ungelesene Nachrichten in Ihrer Inbox"
and we can then look up the value using:
translationService.getTranslation("inbox-messages", 47);
Cheers,
Christian
On 2013-04-09, at 2:59 PM, Eric Wittmann <eric.wittmann(a)redhat.com
<mailto:eric.wittmann@redhat.com>> wrote:
> I was working on the s-ramp browser UI some more today, and encountered
> a case where I need non-template translations.
>
> I have a client-side only notification service (basically an
> @ApplicationScoped service that can be used to growl at the user). When
> various application events occur, I will use the notification service to
> pop up a growl. The title and message is different based on the
> context. It's basically stuff like "Hey, I just did this for you." or
> "Oh no, something you did caused an error." or "Please wait while I
do
> this thing for you...".
>
> In these cases the growl widget is templated, but the title and body
> will be replaced with data passed in. That data originates on the
> client-side but *not* from a template.
>
> Some thoughts on possible ways to address this issue:
>
> 1) @Inject the TranslationService and simply call "translate" directly.
> a) ok great, but what key do I use, and how does that key get
> included in the bundle(s)?
> b) Create a new annotation to somehow indicate additional keys that
> should be translated, along with default values?
>
> Something like this perhaps:
>
> @ApplicationScoped
> class MyService {
> @Inject @Translations({
> @Translation(key="growl-title", defaultValue="Hey Dude!"),
> @Translation(key="growl-message", defaultValue="This thing you
care
> about just happened..."),
> })
> private TranslationService translationService;
>
> public void someMethod() {
> String translatedValue =
> translationService.getTranslation("growl-title");
> // Do something with it
> }
> }
>
> Verbose but effective. The bundle would then be generated to include
> MyService.growl-title and MyService.growl-message.
>
> Thoughts? Is there another way to solve this use case?
>
> -Eric
>
>
> _______________________________________________
> errai-dev mailing list
> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/errai-dev
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev