Some components that require translations have extra complications in their blocks' parameters.
For example, I found it hard to translate Notifiers that offer choices, because the choice text values had to match across the issuance of the choice to the user and the event that received the choice and fed it to an if/then tree to check the user choice value against text constants in the appropriate language.
I have found trying to debug the code of people who spoke non-English languages the most frustrating when i encountered variable names and Label Texts out of the reach of my available translation tools.
I feel compact UI is much better and identical to that of Android Studio.
I've personally used Android Studio's translation feature and find it quite intuitive. The workflow is simple, you write text in your primary language and then handle i18n through strings.xml. But the best part is that Android Studio automatically suggests extracting string literals from your code so you don't have to manually create resource IDs yourself. Something like this in App Inventor would be really helpful.
I think auto-generated but editable is the way to go. Auto-generation reduces friction, but letting users rename them keeps things manageable.
A table layout works well for displaying translations. Keys should be fixed on the left while language columns are scrollable, similar to what @hridoyhb mentioned. There will often be keys with no translation for certain languages. The UI should handle this clearly.
Like keys should be fixed and then the languages or table header should be expandable and scrollable so that one can add languages easily. It might also be possible that there can be no translation for multiple keys in some languages. It is necessary to handle this.
Manually creating keys is the biggest pain point. If it can auto-detect text across components and suggest keys automatically, that would make the whole feature much more beginner-friendly.
Thanks for the earlier feedback on the Translation Management UI. I wanted to share a small update on the current prototype and ask for more UI/UX suggestions.
I now have a basic Translations tab inside the App Inventor Designer. The current setup shows translatable Designer properties in a table, including:
Screen
Component
Component type
Property
Internal translation key
Base text
Translation columns for added languages
For example, component text such as Button text, Label text, and Screen titles can be translated from this table.
I have also started experimenting with dynamic translation keys for runtime messages. These are user-defined keys like:
welcome_message
with base text such as:
Hello {name}
and placeholders like:
name
These dynamic keys also appear in the same translation table and can be translated per language. There are also basic controls for adding/deleting languages, saving JSON, and exporting translation JSON.
This is still an early UI prototype, so I would really appreciate feedback on the current direction.
Some specific questions:
Does this table layout feel understandable for App Inventor users, especially beginners?
Should static Designer translations and dynamic/runtime message translations be shown in the same table, or should they be separated?
Is the dynamic key form clear enough, or should it be moved into a popup/dialog instead of being shown at the top?
Should internal keys be visible by default, hidden, or editable?
How should missing translations be shown visually?
What would make adding and managing multiple languages easier?
Should there be import/export buttons for JSON, CSV, or both?
Are there any parts of the UI that feel too technical or confusing?
I’m especially interested in suggestions for improving the UI side before polishing the implementation further.
Screenshots of the current prototype are attached below.
Could this scheme allow for multiple choices of translatable text for the same component, like a Button whose text switches between Start and Stop depending on whether or not it is running something?
Yes, that is exactly one of the cases I’m trying to support through the dynamic/user-defined message keys.
For the current static Designer properties, the table mostly represents the default text of a component, so a Button’s Designer Text property would have one default translation entry.
But for runtime-changing text, like a Button switching between Start and Stop, the idea would be to allow multiple dynamic keys, for example:
start_button_text = Startstop_button_text = Stop
Then in the app logic, the Button text could be set using the translated value for the appropriate key depending on the current state.
So instead of treating the Button as having only one fixed text value, the translation system would also support extra message keys used by Blocks/runtime logic.
One possible UI improvement could be to make this more component-friendly, for example:
or provide an “Add alternate text” action next to a component/property row, so users do not have to manually think too much about key naming.
So yes, the current scheme can support it, but I think the UI needs to make this use case clearer. Your example is a very good one, and I’ll keep it in mind while improving the dynamic key workflow.
