GSoC 2026 – Exploring Internationalization Support in App Inventor

Open Source Development Google Summer of Code
1

Hi everyone :wave:

My name is Akash. I’m a recent Computer Science graduate and I’m interested in contributing to MIT App Inventor and applying for GSoC 2026.

I’ve started going through the documentation and am currently setting up the App Inventor build locally to better understand the codebase. I’m particularly interested in exploring internationalization support and improving how multilingual apps are handled across the Designer and Companion.

My plan is to begin with code exploration and small contributions to build familiarity with the system. If there are any recommendations on areas related to internationalization or suitable “help wanted” issues to start with, I’d appreciate the guidance.

Looking forward to learning and contributing. Thanks!

1 Like
2

Welcome.

If you haven't already, please review Google Summer of Code (GSoC) 2026 - #5 for general GSOC advice. We are continuing to refine the entries in the help wanted label for intro issues to App Inventor on our Github repository.

Cheers,
Evan

3

Thanks Evan! I’ve reviewed the GSoC 2026 guidance and will keep an eye on the help-wanted issues as they’re refined. I’m currently exploring the codebase and working through a few of the intro issues to get more familiar with App Inventor. Appreciate the pointers!

4

GSoC 2026 Inquiry: Internationalization Feature – Architecture Proposal & Maintainer Feedback

Hi MIT App Inventor team,
@ewpatton @Susan_Lane

I am Akash, a recent Computer Science graduate currently contributing to App Inventor and preparing a proposal for GSoC 2026. I have been actively working on the repository to better understand the architecture and contribution workflow.

Recent Contributions

Some of my recent pull requests include:

  • #3795 – Treat disabled blocks as empty setter sockets (merged)
  • #3758 – Fix Road map tiles not rendering due to OSM redirects (merged)
  • #3731 – Improve contrast for Download APK dialog link text (open)
  • #3741 – Add CopyToClipboard block to Sharing component (Android & iOS implementation)
  • #3774 – Add configurable AndroidMinSdk project property with UI dropdown and build integration (open)

Working on these issues helped me understand several important parts of the codebase including:

  • the Blocks editor logic
  • component metadata and versioning
  • the YoungAndroid project structure
  • the build pipeline and manifest generation

Internationalization Feature Exploration

I am currently investigating the “Internationalization features for applications” project idea and wanted to share my current approach to see if it aligns with the project architecture.

From my investigation:

  • UI component properties are stored in .scm files
  • Blocks logic is stored in .bky files
  • Component metadata is provided through SimpleComponentDatabase
  • Apps are compiled via the buildserver, which generates the Android project structure before building the APK.

Currently, text values such as Button.Text or Label.Text are stored directly in component properties rather than in a localization system.

Proposed Architecture

:one: Translation Editor

Introduce a Translations editor where developers can define language-specific values.

Example structure:

Key            English        Spanish        Hindi
--------------------------------------------------
button1_text   Login          Iniciar        लॉगिन
label1_text    Welcome        Bienvenido     स्वागत

The translation table would manage key-value pairs across languages.

:two: Automatic Sync Layer

A synchronization layer would observe the Designer and Blocks editors.

When developers add or modify UI components:

  • The system checks component metadata via SimpleComponentDatabase
  • If the property is user-visible text, a translation key is created automatically
  • Keys are updated when components are added/removed

This avoids manual key creation and ensures the translation table stays synchronized with UI components.

:three: Translation Resource File

Translations would be stored in a project-level file such as:

translations.json

Example:

{
  "button1_text": {
    "en": "Login",
    "es": "Iniciar sesión",
    "hi": "लॉगिन"
  }
}

:four: Build Integration

During the build process:

  1. The project export includes translations.json
  2. A build step reads this file
  3. Platform localization resources are generated automatically

For Android:

res/values/strings.xml
res/values-es/strings.xml
res/values-hi/strings.xml

This allows Android to automatically load the correct language at runtime.

If translations.json does not exist, the build pipeline behaves exactly as it does today, ensuring full backward compatibility.

Questions for Maintainers

I would appreciate guidance on a few design decisions before continuing deeper implementation work:

  1. Does introducing a project-level translation resource file align with the intended architecture for localization?

  2. Would the buildserver stage be the correct place to generate Android/iOS localization resources?

  3. Is using component metadata from SimpleComponentDatabase the appropriate way to determine which properties should appear in the translation table?

  4. Would it be preferable to implement the translation UI as:

    • a new editor tab, or
    • an extension of the Designer / Properties panel?

Any suggestions or architectural guidance would be extremely helpful as I refine the design and prepare my GSoC proposal.

Thank you for your time and for maintaining such an impactful open source project.

Best regards,
Akash

5

I think this would be okay, but I'm unsure about how we will want to visualize it. Depending on the number of languages supported by the developer, a table will all strings might get quite wide. Both Android and iOS break out languages into a file per language (plus there may be assets with text that also need to have translated versions, but I would say that is outside the scope of this project).

Yes, although they have different ways of representing this data so we will have to take that into account.

I need to think about this a bit. There might be strings in common used in multiple places across multiple screens in the app and we don't want to force translating "Cancel" or "Save" multiple times across the app when they really only need one entry in the table.

On the flip side, there are conflicting synsets to worry about. An example of this in App Inventor is the Pitch property on OrientationSensor and TextToSpeech, where it means different things in those contexts and makes a English-> other language translation impossible without messing up one of the components.

Since translations can span the whole app, my guess is we want a new type of editor for this. In particular, a recent refactor allowed us to create new editor types (based on previous work on IOT and Alexa editors). We could have a "App Translation" editor listed under the screens, for example, with a custom editor. If we decide to split out the translations per language, then we could also have multiple entries.

1 Like
6

Thank you for the clarification!

The point about avoiding duplicate translations such as "Cancel" or "Save" across multiple components makes a lot of sense. Based on your feedback, I think it would be better for the system to support global translation keys that components can reference, rather than automatically generating keys tied strictly to component instances.

For example:

Button.Text → cancel
Label.Text → welcome_message

Then the translation editor would manage values for those keys across languages.

7

@ewpatton
Thank you for the detailed feedback — the points about shared strings and conflicting contexts are very helpful.

Based on your comments, I’m thinking the system should support two types of translation keys:

  1. Global keys – reusable strings that may appear in multiple places across the app (for example cancel, save, retry). These would only need to be translated once and could be referenced by multiple components.
  2. Context-specific keys – strings tied to a particular screen or component where the meaning depends on context (for example screen1_title, login_button_text, or cases like tts_pitch vs orientation_pitch).

In the translation editor this could be organized as:

  • Global translations
  • Screen1 translations
  • Screen2 translations

This structure would help avoid duplicate translations while still allowing context-specific entries when necessary.

For the UI scalability concern, instead of displaying all languages as columns in a single wide table, another approach could be to group translations per language using a sidebar. Each language would appear in the sidebar (e.g., English, Spanish, Hindi), and selecting a language would open an editor showing the translation keys and values only for that language.

This keeps the UI manageable even when many languages are added and also aligns more closely with how Android (values-LANG) and iOS (.lproj) store localization resources as separate files per language.

At build time, the buildserver could then convert these entries into the appropriate platform-specific files (e.g., values/strings.xml, values-es/strings.xml, etc.).

Please let me know if this direction makes sense or if you think another UI structure would work better.