Smashed Apples by Brian Holmes

FlexLingo is checked in

I blogged about FlexLingo the other day and I just wanted to mention that I checked in all the code to google code.

The demo is here with source code enabled. You’ll have to check out the google code project  to get to the flexlingo.swc source code. I haven't documented much of the code, or any of it, and there are a few issues with doing translations this way. As a developer you still need to tie in how you want to store the translations once they are done because you obviously don’t want to hit the google language api every time one of your users needs a translations. I’m also not happy with the bindings that display the strings. It’s too much work, and if you check the code out you’ll see what I mean. I was having trouble with binding through a function. If you have any questions feel free to comment here or email me.

 

Brian..

Tags: locale, localizations, translations

Sweet Flex Translations 2 ( or meet flexlingo)

After having spent alot of time over the course of the last month working within the confines of the flex ResourceManager I decided to throw my hat into the language localization ring, toss out my never ending supply of property files and @ResourceManager(bundle=’hacked’, key=’up’) looking mxml code and try to come up with something more practical for application translation.

I know I blogged earlier on this, but I might’ve jumped the gun a bit with that post so this is an attempt to steer a bit back onto course with what I’m looking for. First, I want to point out that I’m not looking to replace the Resource Manager. I’m much more interested in just managing the language and formatting without having to actually do anything and so to define my practical implmentation I came up with the following ordered list:

1. Components should know what properties they show that can be translated.

2. Developers shouldn’t have to worry about implementing anything to actually perform the translation. ie. knowing what bundle and key they need for a label field. Nor should they have to compile different swf’s to implement different languages.

3. There needs to be a common way to collect, display, translate and save phrases that are a part of the interface. Which includes auto generating a key for the phrase. If you’ve ever dealt with localization you know that there’s just no good way to do this and that translations are usually done somewhere between dev and test.

4. Translation’s should be able to be saved within a database, xml, text, property files or whatever throws your hair back and floats your boat.

 

Now, this all sounds very simple. And indeed it should be, ultimately with language and formatting we’re just talking about strings. A compile time option to output these into a file that could be then imported into a database would be sweet. But doing the translation at runtime will work just as well. And I was slightly amazed at what I was able to get working.

So, meet flexlingo , ( srcview ). There’s no ResourceManager to deal with. You don’t have to know what key outputs what string. Look at the source code and you’ll see only clean looking mxml. I’ve identifed strings that host phrases that can be translateable and have my flexlingo manager collecting them. Anyways, I have more to work on before I release the code. I need to build some admin screens that developers can give translators acces to allow to translate the phrases within the app and allow devs to send it back to the db for storage. I also need to incorporate more components into it as well to make sure everything’s getting picked up properly.

 

p.s. And I apologize if my demo translations doesn’t actually make sense when translated. I used an online translator to get those phrases so I don’t actually know what the actual translations are.

 

 

Tags: localization, ResourceManager

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