Revisit sync process for XLIFF files

[bugzilla-to-github]

This issue was created automatically by a script.

Bug 1676336

Bug Reporter: @flodolo CC: @guerojeff, @mathjazz, [email protected]

So far we've been using XLIFF only for iOS projects. For both projects (Firefox, Focus) we built an infrastructure that updates all locales when adding new strings to the reference file (en-US).

Currently, if you add new strings only to the reference file:

• Strings show up as missing for all locales
• The new translations are not submitted back to the repository, since the XLIFF is missing them
• "Download Translations" gives you a file that is missing translations, like the one in the repository.

The downside of this approach, besides being very confusing, is that we need to replicate the infrastructure for every repository. For example, this is the work happening for the new VPN client https://github.com/mozilla-l10n/mozilla-vpn-client-l10n/pull/39

Unlike GetText, XLIFF doesn't come with native commands to propagate new strings to all locales.

I think it would make more sense to be able to add new strings only to the reference locale, and have Pontoon add them to the resulting XLIFF file when serializing it.

[bugzilla-to-github]

Comment Author: @guerojeff

Is this problem unique to XLIFF? I assumed all bilingual file types were affected by this issue due to bidi sync.

[bugzilla-to-github]

Comment Author: @mathjazz

In essence, the problem is the same across all bilingual file types (xliff, po, lang). The only difference is that at least po (not sure about lang) comes with tools to help with the merge of reference and l10n files.

[bugzilla-to-github]

Comment Author: @flodolo

That tool for .lang files is part of langchecker. The expectation there is that new string need to be added to all languages. https://github.com/mozilla-l10n/langchecker/wiki/CLI-scripts-syntax#lang_update

[flodolo]

This is a problem also when a brand new file is added to an existing project (VPN uses multiple XLIFF files).