What do you want to translate in the textboxes? The text set by you? User input? Hint? Or do you mean labels?
How many items in each of the pickers? What type of pickers, list picker, list iew, spinner, other?
I would like to translate the text in the text box. I have instructions in the text box that I want the user to be able to follow.
I would like for the label on the picker to be translated.
What are index 1 and 2? I get an error message that states operation select list cannot accept the arguments.
Show your blocks and the exact error message.
Have you studied How To Use Lists yet from
I use a two column table in my sample, to keep track of the next component to be updated with the translation results after the translation comes back. Two items are needed to update the next component:
- a code to tell me what type of component it is (B = button, L = Label, etc), and
- the component block
If you don't know how to build a two column table, read the introductory articles in the FAQ.
If your text, no matter in a textbox or a label, is fixed, why you need a translator real-time? Just hard code the text in different languages.
1 Like
You have an empty socket in your translate next procedure.
Thank you! That was the fix needed.
Would I be able to process the translations to other pages in my app without having to select another translate button?
What do you mean by pages?
- Arrangements, yes.
- Screens, no.
You could deal with this with some TinyDB record keeping, to cache all those expensive translations between runs and across screens.
Assume you code your base app with English (en) text in the components.
Keep a TinyDB tag LANGUAGE with value en/fr/ru/es/... for the last requested target language in any screen, default en.
Use a separate TinyDB NameSpace to hold every translation result you get back from the translator in that NameSpace's language.
So namespace es (for Spanish) would have (among other tag/values)
tag / value
OK / Si
Good / Bueno
(that's all my Spanish)
and namespace ru could have
slow / medleno
...
Before requesting any translation of a piece of text, look in that namespace to see if there is a translation on file.
After getting a translation back from the translator, stash the original and translated text under the appropriate language NameSpace.
When switching Screens, run a copy of the translate everything code (customized for that screen) in Screen.Initialize, taking advantage of the TinyDB caches if available.
What is implied by the translate everything code?
That's the code I supplied in Translating Multiple Texts - #5 by ABG
supplements by another global table with components for the current screen.
Do I have to initialize all of the global variables each time I use the translate everything code?
What would happen if you didn't?
I did not try. What is interesting is that I am not able to get any of variables to display in the definition of the setText and getText procedures. It just does not seem as though I can initiate a call of the translation functions with screen initialization. I created a list picker to just see if it would replicate what was done on the first screen but nothing. This one really has me scratching my head. I've attached my blocks for the start. I have not finished all of them.
For a new screen, you must copy all the parts I supplied, and replace the component references in the global init.
Arrangements are less work.
Understand that I need to supply everything and replace the components. When I am constructing the procedure to getText and setText I don't get the variables of type and component.
You need to learn about procedure parameters .
See http://www.appinventor.org/bookChapters/chapter21.pdf
in the free book at
FAQ Section: Books, Tips, Tutorials for AI2
Do you know any tutorial on how to do this?
1 Like