Wire up to a platform for contributing translations

[gnprice]

This is a followup to #275. After we have that basic framework for using translated strings in the UI, we'll want to set things up so that Zulip's volunteer translators can contribute translations.

The obvious direction to go for this would be to wire things up to Transifex, which is what we use for zulip-mobile and for Zulip web, desktop, and server. But… the format the Dart ecosystem supports for internationalized messages is ARB, and Transifex does not support ARB.

If we were determined to stick with Transifex, we could build tooling to work around that — ARB files appear to be just JSON with some reasonable schema, so it shouldn't be hard to translate ARB to some other format and back. But we've independently been wanting to move off Transifex, to a more open platform like Weblate. So probably this will involve moving to a new service.

TBD how to handle that from a project-management perspective. Some thoughts:

• The end state should be that the whole Zulip project is using a single translation service, be that Weblate or something else. We should avoid dragging on for a long period (like many months) on two services, or migrating and then finding ourselves migrating again — those are likely to be a burden on our translation contributors.

• Translating zulip-flutter may not need to block on migrating the whole Zulip project, though. It might instead serve as the pilot, followed by migrating the rest of the project. We'll just want, when we commit to a service for zulip-flutter, to be confident that we will then be able to migrate the rest of the project there without too much further fuss.

• So in particular before we broadly ask our translators to go start translating on a new service, we'll want to have poked around both to understand exactly how we want it set up for zulip-flutter, and also to understand the setup we'll want for other parts of the project at least well enough to convince ourselves that there won't be any dealbreakers later.

[gnprice]

One quirk in Dart's package:intl which we might have to handle when we go to implement this issue: for number/plural forms, the package expects forms named =1 and =0 when it actually means the behaviors whose standard names are one and zero. See:

• Plurals using "one" not parsed, only "=1", Localizely generated files don't work properly dart-lang/i18n#31
• Support for explicit 0 and 1 rules for number formatting dart-lang/i18n#21

So it's likely that Transifex or whatever other platform we use will emit one and zero forms, and we'll have to write a bit of code to translate them to =1 and =0 as part of the process of syncing them down from there into our repo.

See also related chat thread.

[gnprice]

Current status:

• We have a working setup on Weblate (thanks @alexmv!): https://hosted.weblate.org/projects/zulip/zulip-flutter/ . In fact the integration is smoother than it was with Transifex:

  • Weblate picks up source strings automatically as soon as we push to the main branch;
  • for syncing the resulting translations back into the app, we have a GitHub action which automatically makes a PR each week and can also be triggered manually.

  There are a couple of follow-up improvements I'd like to make, but those can be tracked separately.

• We don't yet have the majority of Zulip's community of translation contributors active in Weblate.

  The main ingredient in making this happen will be that we're planning to migrate to Weblate for the Zulip server and web/desktop app too, and when we do that we'll make an announcement to ask people to join us on Weblate.

  That task is outside the work of the mobile team; but it's important that it happens before the new mobile app is launched (and at least a few weeks before, so that people have time to translate). I'm therefore keeping this issue open in order to track that dependency in our project board.