Add option to deliver fallback for missing translations for Events and POIs

[timobrembeck]

Motivation

Parts of the content are less language-dependent than others (e.g. lists of contact-addresses) or change so frequently that they are not translated via the normal workflow. Instead, some regions want to show the translation in the region's default language per default for translations that are missing.

Proposed Solution

• For the content types Event and POI, add a new option to the region model to determine whether missing translations should be delivered in the region's default language.
• In the API, deliver the fallback translation for each missing translation if this option is enabled
• Adapt the translation report and icons in the page list to make it more obvious that the translations are in fact missing, but the fallback translations are shown in the apps instead.

Alternatives

Additional Context

[ulliholtgrave]

Is this the same behavior as in the Wordpress system? As you can see in the screenshots, we have pages that are available in different languages (see the extra language for the corona information).

[svenseeberg]

As the app uses slugs for identifying objects (pages, news, etc) we need to ask the app team what happens if the same slug is used for another language.

[timobrembeck]

As the app uses slugs for identifying objects (pages, news, etc) we need to ask the app team what happens if the same slug is used for another language.

I don't think this has anything to do with this issue. We already allow the same slug for different languages, even for manually created translations, so if this is a problem, it's one independently from this issue.

But this doesn't seem to be an issue, e.g.

• https://integreat.app/augsburg/de/corona-virus
• https://integreat.app/augsburg/en/corona-virus

work just fine. Probably the app uses the whole path augsburg/de/corona-virus and augsburg/en/corona-virus as identifier for a translation.

[timobrembeck]

This issue is no longer as relevant, because we need duplicates for individual pages anyway (see issue #1053).
So we should keep this idea in our minds, but let's move that to the backlog and think about it another time.