[FalconJx] Compiling i18n properties / ResourceBundles

[Frank Wienberg <fr...@jangaroo.net>]

Besides ActionScript and MXML, there is a third source file format for
which mxmlc can produce code: properties files.
Thus, for FalconJx, like for MXML, we have to decide which way to go: either

   1. let Falcon generate the temporary ActionScript class and compile that
   to JavaScript, or
   2. produce JavaScript code or maybe even data (JSON?) directly from the
   properties file.

But first, let me summarize how mxmlc handle properties files for i18n.
Most of this is from the documentation on
ResourceBundles<http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7fcf.html>,
some facts I reverse-engineered by playing with Flex 4.6. As I don't really
have practical experience with Flex and ResourceBundles, can someone please
confirm or correct what I found out so far?

As I understand, mxmlc takes a Foo.properties file from source path
locale/{locale} (or any other pattern specified as part of the source path)
and generates a class {locale}$Foo_properties for each given locale. Each
of these classes is a subclass of mx.resources.ResourceBundle and calls
super("{locale}", "Foo"). It overrides getContent() and returns an Object
literal defining all the key/value pairs from
locale/{locale}/Foo.properties.
The ResourceBundle superclass registers with the singleton
mx.resources.ResourceManager (interface IResourceManager implemented by
ResourceManagerImpl), which, given some key, returns the right value
according to its current localeChain.

The annotation [ResourceBundle("Foo")] at some class Bar establishes
dependencies of Bar on all ResourceBundle classes {locale}$Foo in the
current locale chain. That means when mxmlc is run with locale=en_US,de_DE,
both en_US$Foo and de_DE$Foo will be linked into the generated SWF, and Bar
will instantiate both ...$Foo classes, so that they register with the
ResourceManager and Bar can access the key/value pairs they define through
ResourceManager.getInstance().getString("Foo", "text") or, in MXML,
@Resource(bundle="Foo", key="text"), where the latter automatically adds
the [ResourceBundle("Foo")] annotation to the class generated from the MXML
file.

You have two ways of deploying different locales: either compile all
different locales into one SWF, or produce a separate SWF for each locale
and load the one(s) needed on demand.

What I did not figure out is whether it is possible / makes sense to put
such generated ResourceBundle subclasses into a package. I put a properties
files into a locale/{locale} subdirectory, say
locale/en_US/acme/Foo.properties, and as expected, mxmlc (I used Flex 4.6)
generated a class acme.en_US$Foo_properties. However, the class still
registered with the ResourceManager under the name "Foo", not "acme.Foo",
so my attempt to avoid name clashes (after all, that's what packages are
for) was rendered void.
Is there any way to put properties in a package, or is it simply not
possible with mxmlc? If the latter, should we change this behavior for
Apache Flex / Falcon?

For FalconJx, the question is whether we want to

   1. accurately mimic how mxmlc handles properties files and generate
   ResourceBundle subclasses that register with the ResourceManager, or
   whether we'd rather
   2. find a more straight-forward, efficient way to get the key/values for
   the requested locales to the client and feed them directly into the
   ResourceManager.

For the first approach, does Falcon already generate the temporary
ResourceBundle subclass? Then we could just fetch it and compile it to
JavaScript as usual. I'm sure the [ResourceBundle(...)] annotation can be
implemented in Falcon to add the required dependencies on the
ResourceBundle subclasses.

For the second approach, we'd generate JSON files from properties files and
the [ResourceBundle(...)] annotation would have to take care of loading
these into the ResourceManager directly. Following the AMD approach I
proposed, we could take advantage of the RequireJS i18n
plugin<http://requirejs.org/docs/api.html#i18n>.
However, it seems to me that Flex has a different fall-back / default
semantics than RequireJS---we'll have to investigate on this.

What do you think would be the better approach? Or should we try both?

In both cases, we have to think about which kinds of optimized deployment
we want to support. For applications that come in many different locales,
linking all locales into one big JS would be quite a waste, so it should be
possible to create locale bundles that are loaded depending on the user
locale.

Greetings,
-Frank- J8)

Re: [FalconJx] Compiling i18n properties / ResourceBundles

[Frank Wienberg <fr...@jangaroo.net>]

Isn't that similar to the "maybe even data (JSON?)" part of option 2?
Then the "data" would simply be the original properties file. I just
thought as we have a compile/build step anyway, JSON would be much easier
to parse in JavaScript (built-in!) than a properties file.

On Mon, Jan 21, 2013 at 3:52 PM, Alex Harui <ah...@adobe.com> wrote:

>
>
>
> On 1/21/13 12:01 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>
> > Besides ActionScript and MXML, there is a third source file format for
> > which mxmlc can produce code: properties files.
> > Thus, for FalconJx, like for MXML, we have to decide which way to go:
> either
> >
> >    1. let Falcon generate the temporary ActionScript class and compile
> that
> >    to JavaScript, or
> >    2. produce JavaScript code or maybe even data (JSON?) directly from
> the
> >    properties file.
> Sorry, I didn't read the whole email, but I believe there is a 3rd option
> (and more)
> 3. Don't reduce string-only properties files to the current class
> structure,
> just take them in as a string and parse them in the framework.  How often
> do
> folks actually use binary resources?
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>

Re: [FalconJx] Compiling i18n properties / ResourceBundles

[Alex Harui <ah...@adobe.com>]

On 1/21/13 12:01 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:

> Besides ActionScript and MXML, there is a third source file format for
> which mxmlc can produce code: properties files.
> Thus, for FalconJx, like for MXML, we have to decide which way to go: either
> 
>    1. let Falcon generate the temporary ActionScript class and compile that
>    to JavaScript, or
>    2. produce JavaScript code or maybe even data (JSON?) directly from the
>    properties file.
Sorry, I didn't read the whole email, but I believe there is a 3rd option
(and more)
3. Don't reduce string-only properties files to the current class structure,
just take them in as a string and parse them in the framework.  How often do
folks actually use binary resources?

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui