Sweet Flex Translations

So, imho, the flex Resource Manager is cool, I mean that with all do respect, that is if you’re down with doing a lot more work than is necessary. Who besides Java purists save thier language translations in a  (.) properties file? And why would I want to even do that? I then have to make sure I keep a common naming convention with underscores and names and also not to mention the @Resource tag. It seems like twice as much work as is needed to be done.

I think there is a need for the ResoureManager, but it’s responsibilites should only include resources such as images and sound clips. Languages should be split up. At the very least there should be an option in the flex compiler to output .properties files.

So I took the liberty of creating my components that support rutime language translation. They are not complete but if I can work them out I’ll release them along with examples and translation forms that allow translators to do thier thang. At least as a good starting point for other developers who are facing the same problem.  In fact, if anybody out there wants to start a business up that caters to translating flex applications shoot me an email and let me know.

 So here is a link to my example.

http://www.mxmvc.com/translations/SweetTranslations.html#

(right click to view source)

The logic is that there are a certain number of components such as Button, Label, Panel (as in the title) that need translations done on thier labels or titles or other fields. The components themselves know this and add thier respective property fields to a LangManager that removes all special characters and creates a key with underscores (_). Phrases without translations default to whatever was put in the property so the label=”submit” would still be a “submit” if there wasn’t a “Someta” and the language was Spanish. Translations can then be done on these phrases. This can happen at runtime, the translations should be able to be stored in a properties file, or an xml file or where it seems just about everyone stores everything: a database. There also should be a caching mechanism on the client that stores common translations so that they are readily available.

There are alot of questions to answer about this however, like what if you don’t want it managed for translations. And how much overhead will this cause when dealing with very large applications?

 

Yes I know that that the grid headers don’t translate, but they should and if anybody can help me understand why it’d greatly be apprecated. I also had to turn the creationPolicy=”all” on the tabnavigator to get them to translate. I purposedly left out the components that are doing all the work because they aren’t finished and also because I wanted you to focus on what might be: and by that I mean that if you look at the source which can be found here youll notice that the mxml implemenation of the components are in no way modified or decorated with @Resource tags. They shouldn’t have to be.

 I’m lagoing to blog more on this latter when I have more to show and maybe a better understanding of what needs to be done to make runtime dynamic translations as dynamic and feasible as possible.

Tags: flex+tranlations, ResourceManager

Comments

[Matthew Ryan]

This is very cool.
I have been going around in circles trying to figure out how I am going to do this.
Before working in IT I used to be a interpreter/translator of Chinese and English.
Now that I do small Flex projects on the side I wish I could do Chinese and English in the interface. You seem to have cracked it.

Congrats.