Profile Information

Name: Rishan P
Email: Rishan.pgowda@gmail.com
Github : rovertrack
Other communication modes: Discord, Zulip, Slack.
Location during GSoC: Bangalore India.
Typical Working hours (include your timezone) during GSoC: 6:00 pm to 2:00 am (IST) UTC+5:30

Synopsis

App

Scribe-Conjugate is a mobile application for iOS and Android developed by the Scribe community that allows language learners to instantly look up verb conjugations across multiple languages, powered entirely by open data from Wikidata. Users can search for any verb in their target language and receive a structured breakdown of its conjugations across tenses, moods, and grammatical persons in a clean, intuitive interface. The app extends the Scribe community's existing ecosystem, which includes the Scribe-iOS and Scribe-Android keyboard apps into a dedicated standalone tool focused on helping learners understand the grammatical foundations of their target language.

Project

Project Objectives

The development and release of the following

• Scribe conjugate app for Android
• Scribe conjugate app for IOS

Scribe-Conjugate (see designs on Figma)

Why a Separated Conjugate app

• The Present Verb conjugation tools which are available on the market are available easily, but they also come with hurdles such as ads, some are paid and moreover some of them collect user data. To overcome this the scribe community has come up with this idea/project because scribe community is having the infrastructure sufficient to get the required data from Wikidata.
• This app would be an example of how wikidata lexicographical data can be used in the mobile applications
• The Scribe-Conjugate app would be the first verb conjugation app which is fully open-source, completely ad-free, and transparent. Assuring complete privacy to the users and community.

Possible Mentor(s)

@AndrewTavis
@Henrikt93
@DeleMike

Have you contacted your mentors already?

Yes.

Implementation

Figma

• Conjugate tab (link to Figma)
• conjugated view : (link to Figma)
• Download data UI : (link to Figma)
• Autocompletion : (link to Figma)
• verb conjugation view scrollable and filterable :(link to Figma)

Phase 1 - Android

1.Basic UI Skeleton and Navigation integration
I'm choosing to add some UI to the app first instead of database because i feel if we do this then design the database and make it work and get data and connect the dots to the respective screens it proves we completely understand the flow of the app we can then improve it to meet our requirements.

• Setup the Conjugate tab and add it to the existing bottom navigation.
• Building the static version for all major important screens - search bar screen, autocomplete suggestion list, recently conjugated view, conjugation table, there is no real data yet, just UI structure with placeholder content.
• The goal would be to create pixel perfect screens present in the figma provided, Using Jetpack compose and reusing existing scribe UI components
• Tests: Compose UI tests using ComposeTestRule verifying all screens render correctly.

2.Database, Dataparsing and Repository

• Now that UI structure is confirmed, design the Room FTS5 schema, DTO parsing layer, and repository behind it to feed real data into the already-built screens
• Now that the UI is confirmed, we can design the Room schema, DTO parsing layer and repository and feed real data into the screens and test it for required working conditions.
• Design the Room database consisting of three entities Verb, ConjugationForm, and RecentlyConjugated .
• an FTS virtual table VerbFTS with` DAO`s exposing kotlin flow streaming the data for live search.tense-filtered conjugation fetches, and recently conjugated history queries, this ensures that every static screen built in the previous step has a clearly defined data contract ready to be plugged in.
• Implement Kotlin DTO classes to parse language data following the structure defined in scribe-org/Organization/DATA_CONTRACTS.md, mapping structured fields from the locally stored Scribe-Data language packs into Verb, ConjugationForm, and RecentlyConjugated Room entities. I have previously worked on this Wikidata property mapping to labels in Wikimedia Commons App we can use some of the same strategy here to improve the mapping too
• ConjugationRepository wil be the single source of truth using a local-first strategy, all ViewModel facing queries read exclusively from Room via Flow, which is then parsed through the DTO layer and inserted into Room inside a single transaction to prevent partial data states, at this point every dot between the static UI and the live data layer is defined and ready to be connected.Data is read from locally stored files already downloaded via the existing Scribe language pack infrastructure. No new network layer is introduced. The app reuses the same download pipeline already built for the Scribe keyboard app.
• Testing is done using Room.inMemoryDatabaseBuilder with JUnit4 (have implemented this type of tests) and Turbine with kotlinx-coroutines-test for Flow emission assertions.

3.Verb Search UI

• Building the search bar in Jetpack compose and debouncing the input with Flow.debounce() to increase performance and reduce number of DB queries.
• Display search results in real time, showing Verb lemma alongside its detected language tag
• Support simultaneous search across all user-downloaded languages in a single query.
• Handle empty, loading, no-results state with appropriate feedback.

4.Autocomplete

• Connecting the FTS5 table queries to ViewModel .
• Implement suggestion ranking.
• monitor response time and improve based on some dataset (~3,200) as benchmark.

5.Conjugated History

• Store the recently conjugated verbs in the RecentlyConjugated Room entity.
• Display them in a horizontally scrollable chip row or list on the search screen for quick re-access.
• This is implemented by Room db, Jetpack Compose lazy row for ui and ViewModel for data.

Testing : Data insertion and retrieval tests in Room.inMemoryDatabaseBuilder and composetestrule for Ui testing
6.Conjugation Table

• Build the conjugation table using LazyColumn for tense groups and LazyRow for pronouns pairs
• Implement tense-based chip filter bar at the top allowing users to isolate specific tenses
• Handle linguistically defective verbs (missing forms) with a styled placeholder cell instead of crashing or showing blank

Tesitng : implement basic UI testing with some performclick tests on tense chips
7.Tap to copy for conjugation cell

• Implement tap-to-copy on each conjugation cell using Android ClipboardManager
• Show a brief Snackbar or Toast confirmation message on successful copy

Tests: Instrumented UI tests verifying clipboard content after tap using ClipboardManager assertions in AndroidJUnit4.
8.Optimize

• Conduct performance profiling using Android Studio Profiler to catch jank or slow DB queries
• Optimize Ui for performance and check for apk size.

This completes the android Conjugate app

Phase 2 - IOS

1.Basic UI Skeleton & Navigation Integration

• Setup the Conjugate tab and add it to the existing Scribe-iOS TabView navigation so it is immediately accessible within the app alongside existing tabs.
• Build static versions of all major screens — search bar screen, autocomplete suggestion list, recently conjugated view, and conjugation table — no real data yet, just UI structure with SwiftUI placeholder content reusing existing Scribe-iOS components.
• The goal is to create pixel-perfect screens matching the same Figma designs used in Android, this time using SwiftUI idioms like List, ScrollView, LazyVStack, and SF Symbols to feel fully native on iOS.
• Tests: UI tests using XCUITest verifying all screens render correctly and tab navigation routes to the correct destination.

2.Database, Data Parsing and Repository Layer

• Now that the UI skeleton is confirmed, we can design the CoreData schema, DTO parsing layer, and repository to feed real data into the already-built static screens.
• Design the CoreData schema with three entities mirroring the Android Room schema Verb, ConjugationForm, and RecentlyConjugated verbs with NSFetchedResultsController exposing live queries for search, tense-filtered conjugation fetches, and recently conjugated history, ensuring every static screen has a clearly defined data contract ready to be plugged in.
• Implement Swift Codable structs to parse language data following the structure defined in scribe-org/Organization/DATA_CONTRACTS.md, mapping grammatical feature property codes to human-readable labels with Swift optionals handling missing or defective forms via an isDefective: Bool flag on ConjugationForm rather than dropping records.
• ConjugationRepository will be the single source of truth using a local-first strategy all ViewModel-facing queries read exclusively from CoreData via Swift AsyncStream,parsed through the Codable layer and inserted into CoreData inside a single NSManagedObjectContext save() transaction to prevent partial data states, at this point every dot between the static UI and the live data layer is defined and ready to be connected.
• Reuse existing Scribe-iOS language pack download infrastructure, no separate network calls.
• Testing is done using NSPersistentContainer with NSInMemoryStoreType for in-memory CoreData tests with XCTest, testing using locally stored mock data files mirroring the Scribe-Data contracts structure, and XCTestExpectation with async/await for AsyncStream emission assertions.

3.Verb Search UI

• Build the search bar in SwiftUI using TextField with a Combine debounce publisher to reduce the number of CoreData queries fired as the user types, improving performance.
• Display search results in real time showing the verb lemma alongside its detected language tag, supporting simultaneous search across all user-downloaded languages in a single predicate query.
• Handle empty, loading, and no-results states with appropriate SwiftUI feedback views consistent with existing Scribe-iOS UI patterns.

Tests: XCTest ViewModel unit tests verifying correct state transitions, XCUITest UI tests for search input and result display behavior.

4.Autocomplete

• Connect CoreData prefix predicate queries to the ViewModel, surfacing alphabetically ordered autocomplete suggestions in a SwiftUI overlay list below the search bar as the user types.
• Implement suggestion ranking with exact prefix matches shown first, falling back to broader matches, and monitor response time against the same ~3,200 verb dataset benchmark used on Android.
• Technology: CoreData NSPredicate, Combine debounce, optionally SQLite FTS5 via GRDB.swift if CoreData prefix queries prove insufficient for the required response time.
• Tests:

func testAutocompletePerformance() {
    measure {
        // benchmark code here
    }
}

• Performance blocks benchmarking autocomplete response time, unit tests verifying correct suggestion ordering.

5.Conjugated History

• Store recently conjugated verbs in the RecentlyConjugated CoreData entity with timestamps and display them in a horizontally scrollable ScrollView with HStack verb chips on the search screen for quick re-access.
• Include a clear history option consistent with Scribe's privacy-first philosophy, removing all records from CoreData in a single context save.

Tests: XCTest CoreData insertion and retrieval tests using in-memory store, XCUITest UI tests verifying chip appearance and clear history behavior.

6.Conjugation Table

• Build the conjugation table using SwiftUI ScrollView with LazyVStack for tense groups and LazyHStack for pronoun-form pairs, with a tense filter chip bar at the top using a custom SwiftUI HStack of toggle buttons bound to @State filter selection.
• Handle linguistically defective verbs with a styled placeholder cell using SwiftUI's conditional rendering rather than crashing or showing blank, mirroring the isDefective flag approach from the data layer.

Tests: XCUITest UI tests verifying correct table rendering for full and partial conjugation sets, performTap tests on tense filter chips verifying correct table filtering behavior.

7.Tap to Copy

• Implement tap-to-copy on each conjugation cell using UIPasteboard.general.string and show a brief SwiftUI overlay toast confirmation using ZStack with withAnimation on successful copy.
• Tests: XCUITest tap interaction tests verifying pasteboard content after cell tap using UIPasteboard assertions.

8.Optimize, Accessibility and Final Release

• Add VoiceOver labels and hints to all interactive SwiftUI elements using .accessibilityLabel and .accessibilityHint, and run Xcode Accessibility Inspector across all screens to catch unlabeled or incorrectly ordered elements.
• Conduct performance profiling using Xcode Instruments to catch slow CoreData fetches, excessive view re-renders, and binary size regressions.
• Prepare contributor documentation covering the CoreData schema, Swift parsing layer, and how to extend support for new languages, then release a TestFlight build within the Scribe community for mentor and community feedback before final submission.

This completes the iOS Conjugate feature and the full Scribe-Conjugate project.

Hurray.

Deliverables

Timeline

Thank you for a wonderful GSoC 2026.

• This roadmap is designed to be flexible. if technical debt or architectural blockers arise, the transition of secondary features can continue beyond the 12-week GSoC period to ensure code quality is never sacrificed for speed.

About Me

• I have experience in both Android and iOS development, though my depth in Android - Kotlin, Jetpack Compose, My android fundamentals is stronger compared to Swift and SwiftUI. This is reflected in the timeline where Phase 1 delivers the complete Android feature before midterm, leveraging my stronger Android foundation, while Phase 2 applies the same architectural patterns - MVVM, local-first data strategy, reactive streams - to iOS where i have the experience, but is comparatively less. This structure ensures the project benefits from my strongest skills early while Phase 2 serves as an opportunity to deepen my iOS knowledge on a real production codebase under mentor guidance.

Tell us about a few

• How did you hear about this program?

X (twitter)

• Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program?

Have enrolled in one exam happening July 10 - July 20

• We advise all candidates eligible for Google Summer of Code and Outreachy to apply for both programs. Are you planning to apply to both programs and, if so, with what organization(s)?

Yes, Wikimedia Foundation i don't know why but that's the one organization which i get along well.

• What does making this project happen mean to you?

Means gaining knowledge under guidance of some of the best mentors .Knowledge which will help me improve more Giving to open source, Providing values

Availability

Eligible for Google Summer of Code and Outreachy?
I am eligible for Google Summer of Code and am applying only for GSoC.

Do you plan to submit any other proposal apart from this one?
Yes.

Do you have any other plans this summer?
No I will have an exam which i have enrolled in from July 10 - July 20, during time i will test the app manually for proper working and implement bug fixes, after this my full time is for GSoC .

How many hours per week can you dedicate to this project?
I will dedicate a minimum of 44+ hours per week to this project and am willing to invest additional time if required to meet project goals.

Have you been accepted to GSoC before?
No, this is my first time applying for Google Summer of Code.

Contributions to Scribe

Contributions to Wikimedia Commons

Pull request

Link PRs

• Total: 25
• Merged: 13
• Pending: 11
• Draft: 1

Pull Requests Under Review

Draft Pull Requests

Issues

Link Issue

• Created: 13
• Closed: 10
• Open: 3

PR Review

Contributions to Other Open Source Projects

Organic Maps