[android] Don't allow setting fallback languages

To work around KI18N's incredible slowness when setting multiple languages in KLocalizedString. Currently, setting a fallback language makes Krita completely unusable anyway, so this should be no loss in functionality, it just prevents the user from breaking the application. If/when upstream fixes this bug or we upgrade to a later version that doesn't have it, we can remove this hack again.

This duplicates some logic between the main file and the language switcher dialog, but that's how the situation is already, all other logic regarding the language settings is duplicated in both places and I don't want to do refactorings as part of a hack like this.

Specifically, the slowness is in KF18N's loadMessageCatalogFile, called by loadMessageCatalog. This calls closeLoadedMessageCatalog, fread, malloc and free ludicrous amounts of times. Like, multiple seconds during Krita's minutes-long startup time are just spent inside malloc and free. It's like it's constantly reloading the entire translation.

CCBUG:518351

Test Plan

  1. Before applying this patch, follow the instructions in the related bug. Observe that everything is slow.
  2. Install this version. Observe that it's no longer slow and only the primary language gets loaded on Android. On other operating systems, it behaves as before.
  3. Open the language switcher. Observe that you can't add fallback languages on Android, on other operating systems it behaves as before.

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.
  • Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.

Merge request reports

Loading