Best way to translate our apps, using arrays, etc.

Hi David,

I am currently working on a multilingual app and the cleaner way to translate it would be including name of all the buttons and alerts in a array and read the relevant array member at the proper position. However in AB it requires a few more steps. So I handle this scenario like below right now: SetVar "[names]" "X,Y,Z" "String" SplitStr "[names]" "," "[namesArr]" ArrayGetItem "[namesArr]" "0" "[Button1.Text]" To simplify the process I was wondering is there any direct way to access an array member and to define it. Something like below: NewArray "[names]" "X,Y,Z" And then use the proper element at each control name, something like [names][0]

Thanks for your help as always

Hello Amin,

Before enter in the Array question, can I ask if you already try the Languages sample app? Certainly, in order to translate apps, probably one of the best possible ways is to use the LoadVariables and/or the ParseVariables action. Please, take a look at the Languages sample, made your own test. That sample uses LoadVariables, but, is perfectly possible to use an HTTP Client and the ParseVariables with their response. We can directly set languages/variables for the controls, and, also, these actions support Arrays too.

---

Hi David,

Very very helpful as always, thanks, it will help a lot for the translation part indeed (I will go with your method). However, two questions still stand regardless. Is there a way to define arrays straight in the app builder? something similar to how LoadVariables work, to write an array of items separated by pipes for instance? I have tested pipes in app builder and it does not work, have tested comma before with no luck. For applications like mine that processes alot of data, being able to define many variable in an array comes very handy.

I use arraygetitem and arraysetitem already to access array items and a direct access (array[4]) would be very nice if available? or even something like this, to be able to use an action within the other: AlertBox "ArrayGetItem "ABC" "4" "XX" Thanks for your fantastic support!

Hello Amin,

Certainlty, there is no way to use an action like you wanted above. :-( On the other hand, "LoadVariables" and "ParseVariables" support Arrays. So we can define an Array variable inside an INI file like, and then use it with LoadVariables or ParseVariables. Something that may you also can consider is to use Javascript. As you already know, we can use Javascript code anytime, for example, to set certain Array variable: that variable is then accesible from both Javascript and AB code. Please, go ahead if you have any further question, Amin.

---

Thanks alot David for your swift response and assistance as always. I will transfer my variables to a text file. I believe as you suggested that is the best way. My applications often grow to become very large so I need to investigate all the options along the way to keep them sleek and fast.

Just one last question David, is there anyway to leave a comment in the LoadVariable text file? I will need to record 200 to 300 variables there, having some note will help me keep track of the views they are used in.

Thanks a million.

Hello Amin,

Remember that we can place in the INI like files not only "entire variables", but, also control's variables, so we can perfectly define variables in this way:

MyVar=Here a normal var MyArray=|Here|Is|An|Array|var MyButton1.Text=Here is the text of a button MyButton1.Placeholder=Here is the place holder of a button

When you load and parse that file (depending if you use LoadVariables or ParseVariables), and once loaded or parsed, we get the variable, the Array, but also the "MyButton1" text, placehoder, etc.

And yes; it's possible to place comments in that files, Amin: just start the commented line by a semicolon, for example:

MyVar=Here a normal var MyArray=|Here|Is|An|Array|var MyButton1.Text=Here is the text of a button MyButton1.Placeholder=Here is the place holder of a button ;This is a commented line, which is ignore when load and parse it

Probably can be a good idea to divide the files at least in app's views, so, we can look for the appropriate "translate view file" automagically using some variable like "[App.CurrentView]". Anyway, as here if you have any further question, Amin.

---

Hi David,
Thanks for the detailed answer, commenting in the txt/ini file will do the trick for me I think. Using a few text files and using [App.CurrentView] to switch between them actually crossed my mind. It is a great idea, since it only loads the variables needed to be loaded and you know every millisecond counts when there are alot to be handled! however I am a bit cautious on that since it means each time it is switched between views it reloads some variables versus taking a second at the start and forget about it as long as app is running. Also handling one text file for each language could be easier. All being said, I have put the content of some Html controls into variables, I think I record them separately and load them using [App.CurrentView].

Thanks a lot David, for the assistance and brilliant ideas as always :-)

Hello Amin,

We can control that. We can control if the current app's view has been already translated, so, we no need to do it again. We can use variables like "flag" to do that. We can control, for example, if the app's view no need to be translated... because the app's language is already the default one, for example.

Place all the strings in one sole file can be attractive... depend on the app, may this can be enough. However, the ability to divide the strings in various files appear to be more easy later, to deal with every specific file/view. On the other hand, probably we are talking about more stuff...

My idea (and I already try it in one specific app) is to prepare a "languages" directory, which is included enterely from the app's Files Manager (we can refer to entire directories, instead to specify files one by one). Then that "languages" directories can have subdirectories.

The first level can be a subdirectory per app's view. Or may we want to have a "views" as the first subdirectory of "languages", and, inside "views", place more subdirectories: one per app's view. Then every app's view directory can have the INI like files that we need, and maybe other stuff, like possible images (that need to be translated too, etc.).

Maybe the "languages" directory, and the "es", "en", subdirectories, then the "views" subdirectory, then the "main", "options", app's views directories, etc., may appear difficult or complex... but in fact we can follow certain rules in order to maintain all of these stuff controlled.

Anyway, as always, depend on the app... maybe one sole file (like you are thinking) can be perfectly enough.

In fact the "Languages" app sample is very simple... may I have a bit of free time in order to prepare another "Languages2" app sample, which try to put in the practice all that I try to explain above.

---

Hi David,

You are right a flag would solve the unnecessary reloading, it was a dumb issue lol.
Keeping the files separated could save time as the app expands, sure! Will think more on how it suits this application, may define a few files instead!

Always enjoy discussing ideas with you David :-) thanks

Hello Amin,

I am right now working in certain app, and, this forum's thread come to my mind. Certainly, we are talking here about Arrays, and the ability to load and parse variables. But we can't forget the ability to deal with JSON. Deal with JSON can be very useful. Supose the below JSON code inside a "config.json" file:

{ "app_header_fg_color": "#ffffff", "app_header_bg_color": "#88a542" }

We can load that file with an HttpClient control, and, in their Success event, do something like the below:

CopyVar "[AppConfig]" "[ConfigHttpClient.Response]"

After we that, we can access the JSON variables, directly, in this way:

Alert "" "[AppConfig.app_header_fg_color]"

In fact, the usage of the "CopyVar" action is only for our convenience, that is, it's also perfectly possible refer to the above variable, directly, using the HttpClient control's response:

Alert "" "[ConfigHttpClient.Response.app_header_fg_color]"

As you can see, we no need (even when it's possible) to use actions like "ObjectGetProp" here, but we can directly use the JSON object's properties/variables. I hope this can be also useful for you and others too, Amin. :-)

---

Hi David,

That is a very good example indeed. I am using this in report controls (like record.field) alot when dealing with JSON. Did not know that data can be read directly from HTTP Response like this. Great tip, thanks ;-)