[jira] Commented: (SHINDIG-532) Make message bundles inherit messages from "parent" locales

["Kevin Brown (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SHINDIG-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624438#action_12624438 ] 

Kevin Brown commented on SHINDIG-532:
-------------------------------------

I spoke with Nik offline about this and we came to a conclusion that it's MessageBundleFactory that needs to change, not the locale spec objects.

Instead of having the locale determination happen in GadgetServer, we'll move it to MessageBundleFactory and change the interface to be

MessageBundle getBundle(GadgetSpec, Locale)

This should be a relatively safe change as there hasn't been much reason so far to do custom MesageBundleFactories, other than for custom caches, but Ian's recent patch should eliminate that requirement as well.

> Make message bundles inherit messages from "parent" locales
> -----------------------------------------------------------
>
>                 Key: SHINDIG-532
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-532
>             Project: Shindig
>          Issue Type: Improvement
>          Components: Gadget Rendering Server (Java)
>            Reporter: Nik Haldimann
>            Priority: Minor
>         Attachments: message-bundles-hierarchical.patch
>
>
> It's useful to think of locales as hierarchical, e.g., the locale en-ALL would be the parent of locales en-US and en-GB, the locale all-All would be the parent of locales en-ALL, es-ALL etc.
> Message bundles can be organized in the same way, e.g., the message bundle for en-US inherits (and might override) messages from both parent en-ALL and grandparent all-ALL. This allows gadget developers to avoid some redundancy in message bundles for messages where translations are the same over multiple related locales.
> Attached patch implements this message bundle inheritance logic.
> Caveats:
> - The patch does not implement inheritance for inline message bundes.
> - The patch turns what was only 1 HTTP request for a message bundle into up to 3 HTTP requests. Those are executed sequentially (since this was way easier to implement). Since there is a maximum of 3 requests per message bundle and the bundles are cached in memory anyway (particularly the common parent bundles), this should be fine.
> - The main logic is in BasicMessageBundleFactory. Anybody using a different MessageBundleFactory implementation doesn't get the benefit of this patch.
> I'm open to modifying the patch if these caveats seem too much.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.