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

Comments

[Matthew Ryan]

I just posted a comment on the previous entry about the previous attempt at this, which I thought was cool already.

Your new entry is just proof that refactoring and a belief that code can get even better is valid.

[brian.joseph31]

@ryan, thanks. I've been neglecting it because i've been busy on some other cool projects but will be revisiting it soon. My latest working examples takes it a few steps forward and allows for better db support and / or developer control. if you want the code let me know, cos i haven't released it yet.

[Matthew Ryan]

Hey,

Very keen to have a look when you're ready for others to take a peek.

Your presentation MXML is like you say, it is very clean, and impressive. :-)

Regards,

Matt

[Xavier Hanin]

Your solution to i18n seems really interesting, any chance to see the source code of LingoManager?

[Brian Holmes]

@Xavier Hanin,
Yes, I will be making source code available at http://code.google.com/p/flexlingo/. I've checked code in, but it's not a solution I'd say is anywhere close to being done. The actual code that I am going to be releasing for flexlingo is pretty close, tho.