Currently translated at 100.0% (48 of 48 strings)

Translation: Conversations/App Store Metadata
Translate-URL: https://translate.codeberg.org/projects/conversations/app-store-metadata/uk/

Currently translated at 6.2% (3 of 48 strings)

Translation: Conversations/App Store Metadata
Translate-URL: https://translate.codeberg.org/projects/conversations/app-store-metadata/gl/

fixes #90

To try to bump us up in terms of which client gets IQs so the bob
queries are more likely to come to us.

Which we don't, because we don't store the list of outcast users...

Instead of submenu, to reduce the chance of fat fingering.

Since this causes it to render as if it had a deleted file, even if it
never had a file.

Only require them on join/rename presence, basically.  Just sending
"away" to the room with no metadata doesn't break you.

* webxdc-import-export:
  Implement WebXDC sendToChat
  Support data uri for sending file
  Implement WebXDC importFiles

Since we removed those other backgrounds ages ago...

If anything goes wrong, we just log.  If app got killed in the middle of
the process, we don't notice.  So now instead we retry after 3 seconds
whenever something goes wrong and we retry when the app comes back to
the home screen if it didn't happen yet.  Still careful to only ever do
it once.

recipients need at least Android 5 to play the message; however
Conversations has been Android 5+ for a while now

Off by default

When replying to or mentioning a null-thread message, re-use the thread
id of any existing forked thread from a previous reply to that message
if there is one, so that not everyone replying to a null thread message
ends up generating a new thread when most of the time they mean to all
end up in the same new thread.

Of course user may tap thread icon at any time if they actually want a
second fork.

Mentions still do not generate a new thread since their association is
not tracked, but will follow the forked thread if it exists.

This switches the SQL based backup format to something JSON based.

The SQL based format has always been prone to SQL injections that, for example, could delete other messages or preexisting accounts in the app. This hasn’t been a concern this far because why would anyone purposely try to restore a faulty backup? However the argument has been made that a user can be socially engineered to restore an exploited backup file.
Before version 2.12.8 a third party app could even trigger the restore process, leaving the backup password entry dialog the only hurdle.
On top of that it has been demonstrated that a backup file can be crafted in a way that puts preexisting credentials into a 'pending' message to an attacker ultimately leading to that information being leaked.

While destorying information has always been deemed an acceptable risk, leaking information is one step too far.

Starting with Conversations 2.12.9 Conversations will no longer be able to read v1 backup files. This means if you are restoring on a new device and you have a v1 backup file you must first install Conversations <= 2.12.8, restore the backup, and then upgrade to Conversations >= 2.12.9.

ceb2txt¹ has support for v2 backup files. Conceivably ceb2txt could be extended to convert between v1 and v2 file formats. (ceb2txt already recreates the database from v1 files; It is relatively straight forward to create v2 files from that database. Pull requests welcome.)

¹: https://github.com/iNPUTmice/ceb2txt/