Localizing for multiple languages in AF?

[Mike_King]

What have others done in the AF to extend the localization for multiple languages?  The base localize lookup fields are fine for one language but ultimately, the config should load in a language, then the AF localization VIs be used to lookup the appropriate language for translation.  I think a simple table of data to index appropriate language would be suitable, if each entry lookup gets indexed, that can then be indexed with the appropriate language column.  Anyone done this with AF or have other suggestions?  We usually do localization from a messaging framework with DVRs to allow the localization process to make the lookup and change for the language properties. Haven't thought much on that yet with the AF, as I'm just learning it, but am curious what has been done in multi-language with it.

Thanks,

Mike

[AristosQueue (NI) · Accepted solution]

The AF sample project was set up for localization at the installer level, rather than on-the-fly localization (similar to how LV itself is localized). But if you're going to do on-the-fly, I'd likely do something like:

• have the localization dictionary in a file
• have each Localization.vi read the dictionary entries relevant to itself.

In general, I would shy away from any strategy where you read the dictionary once and then try to send messages to all the other actors with, "Here's your localization info." That's going to lead to replicating the dictionary all over the place or thread friction on the dictionary DVR. It also means you're going to be sending localization messages to every actor since caller actors don't really know whether or not the nested actor has any need for localization or not. If you simply let every actor read the file when/if it decides to do so, you have better independence among the actors and fewer messages flying through your system during startup. Giving each actor its own separate file to read is also an option I would favor if parse speed of the general dictionary became an issue.

If you want to use a database as your backing for localiztion, I favor letting each actor open its own connection to the database. I have not been happy with the results of apps that have a single actor that controls a database which all other actors talk to -- even if you bypass the actor tree so that every actor talks with it directly, it's a poor interface, IMHO. There are lifetime issues for the database actor and there's more message contention than seems necessary. I'd rather open N connections to the database and let those DB systems -- which are highly optimized for simultaneous access -- handle the serving of data.

All of the above is my preference. I don't think we (the AF communiyt) have found a canonical "this is how you should do it" for that problem.

[Mike_King]

Thanks so much for the suggestions.  The strategy I've been using has been that each UI registers their UI (by reference in a message) off to an actor (not in the Actor Framework) that then looks up the dictionary translation and sets the properties directly via reference.  While this has worked VERY well for simply dictionary management, it gets very performance restrictive due to the thread and dictionary contention, as you stated.

We'll likely implement the database solution and I completely agree with you, each actor establishes its own connection, handles it own data only, less contention then.  I think without the database, I'd have each actor read from the dictionary file and handle its own localization then, same as the template AF but with the addition of mulitple languages supported in the dictionary file.

Any suggestions for on-the-fly language changes?  How would you handle a system wide config change to say, switch languages, since that then needs to inform every actor to re-init their localization?  If I had five UIs, and one of those UIs is where the user can choose a language change, would that have to have a message queue for the other 4 UIs and send a message to each to re-init localization?  Is there a better way to keep that decoupled?

Thanks for any suggestions.

Mike

[AristosQueue (NI)]

Mike_King wrote:

How would you handle a system wide config change to say, switch languages, since that then needs to inform every actor to re-init their localization?

My first instinct is to not cache anything in the actors -- have every actor hit the database every time it needs a string. Then you only have to tell the database to change language to return.

But you probably have to cache strings for performance. Or you simply have strings already on the screen when the language change comes through. In either of those cases, yes, you're going to have to get a message out through the tree that says, "Refresh your strings!" It's the kind of message that I would just have the root actor send out to its nested actors and have each layer pass down... probably by creating a root "Localizable Actor" class that all of your actors in your application inherit from so that it is easy to provide an override to handle the message. I'd probably also yell at National Instruments for not creating interfaces yet. (Requests that come in from users through the field sales engineers is one of the best levers I've found for getting staffing for new features.)

[Mike_King]

Thanks AristosQueue...  That is kinda what I figured but was unsure.  And yes,the only caching I have is because the UIs are already open, since they support on the fly language changes.  We have a system where a crew change during use of the system can result in a language change from English->Spanish or back again, so one config change needs to propagate off to all user interfaces to switch languages.  I'd definitely make each actor able to redo its own localization from db/dictionary, so it makes sense to make this a root class with over-rides to support each actors needed functions.  Thanks for the ideas and discussion...  Much appreciated.