3fade6c849
An artifact of more than MAX_CHAPTERS_PER_TRANSLATION chapters could not be translated. The form refused, said so in red, and left nothing to be done about it -- the chapters are already signed, and unlike a chapter's paragraphs there is nothing the person reading that message can split. It was a cap on how long a book may be, wearing a cap on a batch as a disguise. The same answer the chapter side already gives: propose more than once. The translation and as many chapters as fit go in the first session, and the rest follow in sessions of their own, naming the translation the first is about to sign. The admins answer once per session, and the form counts them before the tap rather than colouring a refusal. MAX_CHAPTERS_PER_TRANSLATION stays, meaning what it now measures -- how many chapters ride in the translation's own session, the batch minus the place the translation itself takes. It is a cap on a session rather than on the work. The cost is the one every second session in this design carries, and is documented where it is paid: if the translation fails to reach a quorum while these succeed, they are valid signatures over rows naming a translation nobody has, which fail a foreign key on the way in and are logged rather than applied. The catch-up on the translation is what fills that in afterwards. **Tests.** TranslationBatchProposalJvmTest now covers the split: an artifact three chapters past the cap proposes a full first session and a second of three, every chapter of the work covered exactly once across both, in order, each naming the translation as the group will author it. The refusal test stays and keeps its point -- one session is still refused a chapter too many, because a batch that quietly dropped its last chapters would sign a translation the group believes covers the whole work while the end of it can never be translated. What changed is who prevents it: the screen splits rather than checks, and the manager still refuses independently. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This is a Kotlin Multiplatform project targeting Android, iOS, Desktop (JVM).
-
/composeApp is for code that will be shared across your Compose Multiplatform applications. It contains several subfolders:
- commonMain is for code that’s common for all targets.
- Other folders are for Kotlin code that will be compiled for only the platform indicated in the folder name. For example, if you want to use Apple’s CoreCrypto for the iOS part of your Kotlin app, the iosMain folder would be the right place for such calls. Similarly, if you want to edit the Desktop (JVM) specific part, the jvmMain folder is the appropriate location.
-
/iosApp contains iOS applications. Even if you’re sharing your UI with Compose Multiplatform, you need this entry point for your iOS app. This is also where you should add SwiftUI code for your project.
Build and Run Android Application
To build and run the development version of the Android app, use the run configuration from the run widget in your IDE’s toolbar or build it directly from the terminal:
- on macOS/Linux
./gradlew :composeApp:assembleDebug - on Windows
.\gradlew.bat :composeApp:assembleDebug
Build and Run Desktop (JVM) Application
To build and run the development version of the desktop app, use the run configuration from the run widget in your IDE’s toolbar or run it directly from the terminal:
- on macOS/Linux
./gradlew :composeApp:run - on Windows
.\gradlew.bat :composeApp:run
Build and Run iOS Application
To build and run the development version of the iOS app, use the run configuration from the run widget in your IDE’s toolbar or open the /iosApp directory in Xcode and run it from there.
Learn more about Kotlin Multiplatform…