You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Kevin Brown <et...@google.com> on 2008/05/14 10:49:12 UTC
Spec + Message bundle factories need to be united.
0.8 requires that we support nesting message bundles directly inside of
<Locale> tags. This will make for some fairly bizarre code paths.
To simplify the situation, I propose that the spec factory handle message
bundle retrieval as well, and simply inlines the message bundles directly
into the gadget spec. This would make code that looks like this:
MessageBundle bundle =
bundleFactory.getBundle(spec.getLocale(locale).getMessages())
look like this:
MessageBundle bundle = spec.getLocale(locale).getMessages()
With getMessages() returning the map of localizations, and a new method,
getMessagesUrl, returning the bundle location (in practice, it'll probably
almost never get used).
We'll be forced to fetch the bundles for every locale, but caching of the
spec xml, async bundle fetches using futures, or lazy loading can make the
performance impact negligible.
Does this make sense?
Re: Spec + Message bundle factories need to be united.
Posted by Kevin Brown <et...@google.com>.
On Wed, May 14, 2008 at 5:03 AM, Paul Lindner <pl...@hi5.com> wrote:
> This seems reasonable.
>
> I'd also like to be able to introduce some level of injection in this
> area.
This was the reason that Louis put factories for these things in the first
place. With what's in HEAD, you can do this by implementing your own
MesageBundleFactory. My only issue with MessageBundleFactory is the one I
mentioned with new requirements for 0.8.
>
>
> At hi5 we're developing a translation console to allow for
> crowdsourced translation of an app. For languages not explicitly
> supported by an app we want to inject attr/value pairs from an
> internal database. For this case we also want to rewrite the html
> output of each message with a specific <span> tag that contains the
> key. We'll then add javascript hooks for each of these matching
> <span> tags that calls out to our inline translation tool.
>
> Obviously we could hack the app xml fetch code and add specific
> locales pointing to our own servers. I think adding these hooks in
> this part of the system would be cleaner and more efficient.
>
> On Wed, May 14, 2008 at 01:49:12AM -0700, Kevin Brown wrote:
> > 0.8 requires that we support nesting message bundles directly inside of
> > <Locale> tags. This will make for some fairly bizarre code paths.
> >
> > To simplify the situation, I propose that the spec factory handle message
> > bundle retrieval as well, and simply inlines the message bundles directly
> > into the gadget spec. This would make code that looks like this:
> >
> > MessageBundle bundle =
> > bundleFactory.getBundle(spec.getLocale(locale).getMessages())
> >
> > look like this:
> >
> > MessageBundle bundle = spec.getLocale(locale).getMessages()
> >
> > With getMessages() returning the map of localizations, and a new method,
> > getMessagesUrl, returning the bundle location (in practice, it'll
> probably
> > almost never get used).
> >
> > We'll be forced to fetch the bundles for every locale, but caching of the
> > spec xml, async bundle fetches using futures, or lazy loading can make
> the
> > performance impact negligible.
> >
> > Does this make sense?
>
> --
> Paul Lindner
> hi5 Architect
> plindner@hi5.com
>
Re: Spec + Message bundle factories need to be united.
Posted by Paul Lindner <pl...@hi5.com>.
This seems reasonable.
I'd also like to be able to introduce some level of injection in this
area.
At hi5 we're developing a translation console to allow for
crowdsourced translation of an app. For languages not explicitly
supported by an app we want to inject attr/value pairs from an
internal database. For this case we also want to rewrite the html
output of each message with a specific <span> tag that contains the
key. We'll then add javascript hooks for each of these matching
<span> tags that calls out to our inline translation tool.
Obviously we could hack the app xml fetch code and add specific
locales pointing to our own servers. I think adding these hooks in
this part of the system would be cleaner and more efficient.
On Wed, May 14, 2008 at 01:49:12AM -0700, Kevin Brown wrote:
> 0.8 requires that we support nesting message bundles directly inside of
> <Locale> tags. This will make for some fairly bizarre code paths.
>
> To simplify the situation, I propose that the spec factory handle message
> bundle retrieval as well, and simply inlines the message bundles directly
> into the gadget spec. This would make code that looks like this:
>
> MessageBundle bundle =
> bundleFactory.getBundle(spec.getLocale(locale).getMessages())
>
> look like this:
>
> MessageBundle bundle = spec.getLocale(locale).getMessages()
>
> With getMessages() returning the map of localizations, and a new method,
> getMessagesUrl, returning the bundle location (in practice, it'll probably
> almost never get used).
>
> We'll be forced to fetch the bundles for every locale, but caching of the
> spec xml, async bundle fetches using futures, or lazy loading can make the
> performance impact negligible.
>
> Does this make sense?
--
Paul Lindner
hi5 Architect
plindner@hi5.com
Re: Spec + Message bundle factories need to be united.
Posted by Louis Ryan <lr...@google.com>.
Sounds reasonable. Could we push the provision of the locale information
higher in the call chain?
i.e
GadgetSpec spec = specFactory.getGadgetSpec(..., Locale)
spec.getMessageBundle()
This allows containers to perform any locale specific transformations on the
spec itself if it needs to prior to rendering
On Wed, May 14, 2008 at 1:49 AM, Kevin Brown <et...@google.com> wrote:
> 0.8 requires that we support nesting message bundles directly inside of
> <Locale> tags. This will make for some fairly bizarre code paths.
>
> To simplify the situation, I propose that the spec factory handle message
> bundle retrieval as well, and simply inlines the message bundles directly
> into the gadget spec. This would make code that looks like this:
>
> MessageBundle bundle =
> bundleFactory.getBundle(spec.getLocale(locale).getMessages())
>
> look like this:
>
> MessageBundle bundle = spec.getLocale(locale).getMessages()
>
> With getMessages() returning the map of localizations, and a new method,
> getMessagesUrl, returning the bundle location (in practice, it'll probably
> almost never get used).
>
> We'll be forced to fetch the bundles for every locale, but caching of the
> spec xml, async bundle fetches using futures, or lazy loading can make the
> performance impact negligible.
>
> Does this make sense?
>