gnprice
commented
2 months ago 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:
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.
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.