Define new localization flows

[stefanceriu]

Now that we're reusing Android strings we need to define the flow for contributing back iOS specific ones.

One approach would be to create a separate Everything Mobile project and weblate and copy over actually used strings. This would help with cleaning up existing android strings.

Another approach would be to split it up in 2 different Android weblate projects and have each client use a separate one. We would benefit from the existing Android strings but we won't have a hard dependency on them anymore.

[stefanceriu]

While looking into a conversion error on our android importing script I ran accross this https://docs.weblate.org/en/latest/faq.html#how-to-translate-multi-platform-projects

It seems that we can have multi-platform projects on weblate and move away from custom conversion scripts. We'll need a new project to test this out but definitely worth a shot.

[pixlwave]

I've looked into using Weblate, Localazy, Phrase Strings and Lokalise:

Weblate

• Easily open to the community, no option to buy professional translations.
• Public Android strings component for translators.
  • Enable “Manage Strings” allows to add new strings directly on the platform.
• Private components for iOS and iOS plurals.
  • Enable "Translation Progagation" will copy any translations from Android.
    • Needs the base string to be added manually in the iOS components to have effect.
    • Seems likely error prone with missing base strings on iOS.
  • Could instead convert but tools to do with with stringsdict output are lacking.
• Has a CLI which claims to support conversion but I couldn’t get this working.

Localazy

• Single set of strings.
  • Easily added on the platform itself.
• Download a specific format via CLI.
  • Can ask for iOS strings and stringsdicts (with a bit of filtering).
  • Needs a bit of regex to change placeholder formats.
• Supports public projects so anyone can translate.
• ML strings and paid for translation.
• Figma plugin to send strings for translation.
• $65/month for 5000 keys (unlimited translators)

Phrase Strings

• Single set of strings.
  • Easily added on the platform although the editor UI is a bit clunky.
• Download a specific format via CLI.
  • Can request iOS strings and stringsdicts (automatically does the right thing).
  • Automatically changes placeholder format if asked.
• Can’t have public translators.
• ML strings and paid for translation.
• Figma plugin to send strings for translation.
• $36/user/month for unlimited keys (min 5 users).

Lokalise

• Single set of strings.
  • Easily added on the platform.
  • Has its own placeholder format and clearly shows them using pills.
  • Very easy to choose strings that shouldn’t be sent to iOS/Android/Web.
• Download a specific format via CLI.
  • Requesting iOS strings automatically includes stringsdicts as a config.
  • Converts placeholder format automatically.
• Can have a public link for translators
  • BUT each one adds to cost of service and no obvious way to restrict link to specific languages.
• ML strings and paid for translation.
• $12/user/month for 5000 keys (min 10 users).
• Figma plugin requires a much higher plan: $55/user/month (min 15 users)
• Definitely the slickest platform.

[manuroe]

@bmarty what do you think about Localazy for Android?

[bmarty]

https://poeditor.com/ is another possible option.

Some thoughts:

• the tool and especially the library if we need to add some have to be suitable for open source project (in particular, can we make the api keys public) and will it cause any trouble for the F-Droid build;
• in EA currently we use a pattern ${app_name} to replace the application name at compilation time (but app_name could be any other existing string resource). We will have to check if this is still possible to do that.
• I think we can give Localazy a try, if we manually (or by CI) import the strings in our project source. Hosting the string on an external server and get them at runtime seems a bit scary. I will still double check with F-droid people if this can work, if we decide to use the gradle plugin on Android (and I think we should)

[manuroe]

Thanks @bmarty.

poeditor has been mentioned. @pixlwave did you have a look at it?

Hosting the string on an external server and get them at runtime seems a bit scary

This is out of scope. Let's make it work first before trying to optimise app size by lazy loading internalisation. If we go there at some point, we will need to check privacy concerns involved by this technique. Even using element.io to store the strings is not great.

[pixlwave]

I originally dismissed poeditor as it doesn't support an iOS stringsdict directly (instead needing you to go through some kind of import dance with XLIFF files if you want plurals). I'm happy to try out the demo and see what that would mean for us in practice if you want? I see its free for OSS projects which would be a big win if it works for us.

If we go there at some point

That whole idea makes me really nervous, don't think I'd be keen to do it based on any platform.

[pixlwave]

POEditor

• Single set of strings.
  • Can be added on the platform itself but it is a bit clunky.
  • You first add a "Term". This is the key, but without a base translation.
  • Then you add the English translation of the term in a separate tab.
  • Doesn't appear to have the concept of a base language.
• Uploading my small set of test strings resulted in %s's changes being added as %s\'s changes.
• Download a specific format via an API.
  • There isn't an official CLI, but seem to be plenty of third party ones.
• Supports iOS strings but you need to use XLIFF for plurals.
  • In my testing downloading a XLIFF didn't include plurals (pinged support to ask why).
  • Importing the XLIFF into Xcode fails miserably as it doesn't know how to map the keys to existing files.
  • Looks to me like the only way that would work is if iOS was the source of truth and we exported strings as XLIFF and uploaded these to POEditor for translation.
• There isn't automatic placeholder format adjustment, maybe there's an option to configure it but I didn't look.
• Supports public project for community translations.
• ML strings and paid for translation.
• Figma plugin to send strings for translation.
• Free for open source projects.

[manuroe]

We are using localazy now. See the doc.