Yes, I have considered and ruled out Flex 2's localization features.  I find
it a ludicrous idea to have to compile resource strings directly into a SWF
or SWC.  Maybe I am still missing something about how Flex implements it and
please tell me if I am.  I find two serious issues with this method
1. You have to compile your application for EACH language you want to
support.  So if I want to support 30 languages I have to compile my
application 30 times, storing the output in different directories, etc.,
etc..  Add to this that in order to support skinning I have to again compile
the application for each skin.  So if I have 30 languages and I want to give
the option of 30 skins for each language that = 30 * 30 = 900 compiled
instances of the same application.  Some may say why would have that many
skins.  I say why not?  This is EASILY accomplished with HTML.  And you
can't ask me 'why support 30 languages'.  Anybody who has done any kind of
enterprise development knows the answer to that question.
2. Related to #1 but still I don't understand why you would want to compile
the i18n strings *directly* into the SWF.  This means any time I want to
make a single update to any string in any language I have to recompile
EVERYTHING.  Wow, that is insanity.

Now as for my solution it is really quite simple. It is simply a singleton
class that loads an XML file containing the text strings.  The loading of
this file is part of my bootstrap process which also loads the application
configuration, inits remoting, etc..  The XML file looks like:
<?xml version="1.0" encoding="UTF-8"?>
<language translation="en_US">
   <key id="$I18N_PROGRAM">Program</key>
   <key id="$I18N_POINTS">Points</key>
....

To get a I18N string you simple call Locale.getKey("$I18N_PROGRAM") which
does some other error checking but basically the only brains is:
          var value:String = _langXML.key.(@id == key);
E4X makes this *incredibly* easy and even as I mentioned could even allow
you to change every piece of text in your entire running application
instantly by simply loading another xml file.  The original question of this
thread though is 'is having that many bindings feasible'.  If it isn't I
don't really mind as all it means is telling the user to restart the
application.  Since users don't exactly switch languages often this isn't an
unreasonable thing to ask.  The other argument is that since (I assume) a
SWF is compressed somewhat the download time for this may be more.  This is
true but not by much.  I have also added a feature to modularize the strings
so that each languge will be broken up into many files and they will be only
loaded as each module in the app is loaded (this is a multi-module,
multi-swf app)

If there are any better methods I would love to hear them.  By all means
lets start a discussion on it.  But I don't see a single advantage to using
Flex's built in methods.

Regards,
Collin Peters


On 12/25/06, greg h <[EMAIL PROTECTED]> wrote:

  Collin,

But a side question Collin, had you considered and ruled out Flex 2's
localization 
features<http://livedocs.macromedia.com/flex/2/docs/00000898.html>which are 
implemented at compile time, rather than using run time bindings?
If so, and if you are willing to share, I am interested to hear what your
considerations were.




g


On 12/24/06, Collin Peters <[EMAIL PROTECTED]> wrote:
>
> Merry Christmas all!
>
> I am wondering how heavyweight databinding is.  What I have is a class
> which handles all the I18N in my application.  It is a simple class
> which loads an XML containing all the I18N strings and then provides a
> getKey() function to grab strings out.
>
> What I have discovered is that I can directly bind labels and such in
> MXML directly to the XML i18n string.  I am wondering though if this
> is a smart idea.  The completed app could have a thousand or more i18n
> strings.  Would it unnecessarily stress the application to have each
> one of these thousand strings setup with data binding?
>
> I'm wondering about increased memory and CPU usage.  Not much is
> gained from the binding except slightly less code and I guess the
> possibility of changing all strings in the application to another
> language by simply loading another XML file.  But again, I wonder how
> fast this would be.
>
> --
> Collin Peters
> Lead Software Developer
>




--
Collin Peters
Lead Software Developer

Reply via email to