Common strings between two different projects without duplicating translator work

[kewisch]

Hi folks,

in https://hosted.weblate.org/projects/tb-android/ we have Thunderbird for Android which is built using the typical setup for an Android app. We're now starting to work on Thunderbird for iOS and would like to use Weblate as well. I would appreciate your support in finding the right path to minimize the amount of duplicate work that translators would need to do. I'm asking here as I suspect the answer might be interesting to other projects as well.

We imagine that a high percentage of the strings would be shared between Thunderbird for Android and Thunderbird for iOS. However, we need to output them in two different strings formats, once as Android App Resources, and once as iOS Strings (UTF-8).

1) Use a glossary

It appears using a "Glossary" might work, though I'm not 100% sure it works as I think it does.

With my very brief understanding of the "Glossary", I could maybe turn for example onboarding-welcome module into a glossary, share it with the iOS project, then create a new component ios-onboarding-welcome.

It appears that since the terms already appear in the tb-android component, they also appear in top right glossary when someone is translating the ios-onboarding-welcome text. But they would still need to "copy" the translations from the glossary.

Following through with this, it looks like we'd need to make most components in tb-android a glossary, share them with a tb-ios project, and then create separate ios-* equivalent components that could feed from the glossary. Translators would still need touch every string twice, but they'd at least have the glossary to read from.

2) Some unidentified way to export the same strings to two repositories

Maybe there is a feature I haven't found in Weblate where I can have a single component that has two different types of "repositories", so that for one repository I can make Android App Resources the output format, and for the other I can make iOS Strings the output format?

Maybe it would work with a "shared" component, where a separate iOS component would read strings from the "shared" component as a source? But then I'm not sure how to best get strings into the shared component.

3) A way that syncs strings externally and then uses shared components

It looks like I can share non-glossary components to translate between projects. If I make thunderbird-android the "authoritative" source for translations, I could:

1. Maintain an onboarding-welcome component in tb-android
2. Share the onboarding-welcome component with tb-ios, but don't make it a glossary
3. Write a github action that reads the shared localization components like onboarding-welcome from the thunderbird-android repository, converts the strings to iOS resources (maybe using translate-toolkit?), then sends a pull request to the thunderbird-ios repository to commit those strings in all languages, synchronizing what is already there.
4. Don't include the now-committed iOS onboarding-welcome component in the tb-ios weblate, as the authoritative source would be the tb-android component.

Then for all iOS-specific strings I would have separate components in the tb-ios project, and for all Android-specific strings I would have components in tb-android that I don't share with the tb-ios project. Maybe using some naming schemes like shared-onboarding-welcome to indicate that the module is shared between iOS and Android.

Which way would work best? Is there a fourth way that I am missing?

[nijel]

There is (a very short) section in the documentation covering one option: https://docs.weblate.org/en/latest/devel/mobile.html

[kewisch]

Thanks! I tried this locally and was at least able to manually propagate changes from one component to the other. Some caveats:

• It only worked if the component is in the same project. It did not work if I share a component with another project, and then in that other project have a separate component that has the same keys as the shared component. Is this a bug or intentional?
• When I added the components to the same project, I was only able to trigger propagation manually. What are the triggers where it happens automatically? I tried:
  1. Add Albanian in the ios-onboarding component as a new language - all strings are untranslated
  2. Make a change in the Albanian android-onboarding component that has the same key as in ios-onboarding
  3. Expected: Me making the change in android-onbording should have it propagate to ios-onboarding
  4. Actual: Only see the inconsistency checks failing, no automatic propagation

Based on your weblate experience, do you have a recommendation on which approach would work best?

[nijel]

I've clarified the documentation d483b19.

The string should be automatically propagated upon editing if the conditions are met. You should see propagated badge next to the strings in the translation editor like https://hosted.weblate.org/translate/weblate/website/cs/?checksum=4814ad8632fc3613#others

[kewisch]

Alright, I've tested this locally and on our hosted project and it seems to work mostly as expected. When I make a change to a string, it is propagated to the new component. Thank you for the updates! https://hosted.weblate.org/projects/tb-android/ios-localization/

One thing I haven't figured out is if there is a way to manually trigger propagation. The component was added with 3 languages we happened to know. Then through the add-on to keep the languages consistent between components now all the languages have been added, but they are empty.

I would like to click a button or call an API that will propagate strings into this new component for all languages. Given Android is already translated and the other conditions are met, the new iOS component should ideally have all strings already translated/propagated on creation. Is there a way I can trigger this?

It would be great if this happens automatically when creating new languages in the components. #14820 seems related, though in my case the trigger is adding a new language instead of adding a new string. Am I missing a way to do this, or would you appreciate an issue for it?

[nijel]

There is currently no way to manually trigger propagation. You can use automatic translation with other components as source, but that one ignores keys and looks only at the source strings.