Determine if/how to update upstream translations in Anki-Android-Backend

[mikehardy]

We need to work on frequency/freshness of the Pontoon translations which are at this point pretty static (we have not ingested changes from that system in months, and...have no plan to do so right now which is not good, I want a plan we just don't have one). I'm not sure if we can ingest just translations easily or if we must necessarily update the whole backend or not, the question bears investigating

Originally posted by @mikehardy in ankidroid/Anki-Android#12448 (comment)

[dae]

Each desktop release pins the strings at a particular point, since newer code may depend on new strings, and obsolete strings may be dropped. You thus can't update the translations separately from the anki module without risk of things falling out of sync. 2.1.55 is hopefully not more than a month away, and when it comes out and a new backend release is made, all the accumulated contributions will be in it. AD doesn't necessarily have to stick to stable releases either - it can update the backend before then if it wishes.

[mikehardy]

Sounds like the same process we have - code and strings need to match (for same reason - string add/drops).
So the process for ingestion of new strings will be to "re-sync" the backend to some specific commit - either a stable tag or some interesting commit, no matter from a sync perspective, it's a commit hash at the end.

A finer question: is there any risk in any specific commits? For example, we typically commit a PR that does string add/drops then we do an i18n sync with crowdin that populates the other languages and commit that. So from an i18n perspective there is a brief moment where strings are out of sync for non-english locales. I don't think that actually has a risk of crashing in Android (it should fall back to the default locale for missing strings?) but maybe it's different for backend?

That would inform whether commits to sync backend need any care when they are chosen or really if any commit would work (assuming it was a "good" commit to choose from a functionality/error perspective)

[dae]

Generally any commit on main is safe, though there have been a few instances in the past where a bug was introduced and then fixed in a follow-up commit after it was discovered.