[iOS] Internationalization Infrastructure

[marcotuts]

Goal

Coming soon

Slack: #wg-product-mobile
Requirement Definition: coming soon

Tasks

Beta Give feedback

1. Tech Requirement Discovery (Initial) #169
   +0
   
2. Tech Discovery / Early Definition

[marcotuts]

Candidate for edX development and support given existing context

[moiz994]

Goal: Have the app support multiple languages to increase ease of use for learners from a variety of geographical regions.

The current prod edX app supports 11 different languages (including English).

[moiz994]

@e0d and @marcotuts fyi:

We support a total of 11 languages in our app:

• Arabic
• Chinese
• English
• French
• German
• Hebrew
• Japanese
• Portugese
• Spanish
• Turkish
• Vietnamese

[brian-smith-tcril]

I believe the best path forward for internationalizing the iOS and Android apps is to follow the patterns established by OEP-58.

This would mean:

• Adding a command to extract source strings to the iOS and Android repos (similar to make extract_translations in other repos in the org)
• Updating the Extract Translation Source Files workflow in the openedx-translations repo to include the iOS and Android repos
• Updating transifex.yml in the openedx-translations repo to include the iOS and Android repos
• Adding a step to the iOS and Android app build processes that utilizes openedx-atlas to pull translations

I believe having the iOS and Android repos follow the same pattern for translations management as the rest of the repos in the Open edX GitHub organization will benefit maintainability. Following a consistent pattern for the translations workflow will make it much easier for anyone working with internationalization to understand.

This proposal does not directly address the concerns surrounding duplicated strings. While I understand the desire to deduplicate, I feel doing so in a way that only applies to the iOS and Android repos is less than ideal. Transifex provides tools to aid with this such as Translation Memory, and I believe we should utilize that before looking into adding complexity in service of deduplication.

[OmarIthawi]

Hello there.

I've been asked by the Axim team to review how can we extend the openedx-atlas and https://github.com/openedx/openedx-translations to be used in the mobile apps.

I've worked on openedx-atlas and we've made sure to make it cross-platform compatible with no external dependencies except for Bash.

I'm not an iOS expert and I'll be asking a colleague to work on this. So, please let me know if I've missed anything regarding the build process in iOS.

I've checked the code and noticed that strings are already extracted as part of the development process but they're not grouped.

Transifex and Translators likewise makes prefers to group the translations files to avoid confusion. We've initiated a similar effort in the edx-platform:

• docs: decision to standardize django/djangojs po files FC-0012 edx-platform#32994

To illustrate the point, the edx-ios-app (old one) has more than one resource:

• https://github.com/openedx/edx-app-ios/blob/master/.tx/config
• https://app.transifex.com/open-edx/edx-mobile-apps/content/

Same goes for the edx-app-android which admittedly has much more string resource files:

• https://github.com/openedx/edx-app-android/blob/master/.tx/config

Is it doable to combine those resources into one resource before pushing it to Transifex? This would make it easier for translators to find and translate the resources? We have 54 resources already in the Open edX project and we'd like to keep in general 1 resource per application.

My suggestion to that solution is to write a build script to combine the source translations in a file to be sent to Transifex, then on pulling the translations the file is split based on the source Source/en.lproj/*.strings file so the structure is kept and the mobile apps code won't need editing.

The choice of the build script language can be any of Bash, Swift or Ruby depending on the iOS team preference. We could address the duplication issue during this process if needed -- but that'll extend the development scope a bit.

A release-time script needs to be created to pull the latest translations from the openedx/openedx-translations repository via the atlas pull command.

As far as I understand, the workflow is somewhat similar to Android.

So overall here's the ideal workflow would look like:

• iOS engineers maintain the same workflow by extracting the strings into multiple .strings files
• A new step is added to include the ios app in the Extract Translation Source Files workflow in the openedx-translations repo
  • The extract-translation-source-files.yml will run daily and update the Transifex project
  • The transifex.yml in the openedx-translations repo ensures that Transifex pushes the changes back into the openedx-translations repository without needing developer intervention
• On release time atlas pull will pull the latest translations.

I'm happy to schedule a call to discuss the plan and get your feedback. We've implemented similar steps for projects with different tech-stacks and we believe it's suitable for beneficial for mobile.

[OmarIthawi]

Being fixed by #422