Grants:Programs/Wikimedia Community Fund/Rapid Fund/Unified Lithuanian Inflection System for English Wiktionary (ID: 23941422)
Applicant details
[edit]- Main Wikimedia username. (required)
TongcyDai
- Organization
N/A
- If you are a group or organization leader, board member, president, executive director, or staff member at any Wikimedia group, affiliate, or Wikimedia Foundation, you are required to self-identify and present all roles. (required)
N/A
- Describe all relevant roles with the name of the group or organization and description of the role. (required)
Main proposal
[edit]- 1. State the title of your proposal. This will also be the Meta-Wiki page title.
Unified Lithuanian Inflection System for English Wiktionary
- 2. and 3. Proposed start and end dates for the proposal.
2026-08-31 - 2026-12-13
- 4. What is your tech project about, and how do you plan to build the product?
Include the following points in your answer:
- Project goal and problem you solve
- Product strategy or project roadmap
- Technical approach (infrastructure, tech stack, key tools and services)
- Integrations or dependencies (if any)
Project goal and problem
[edit]English Wiktionary currently has approximately 8,400 Lithuanian lemma entries, served by over 100 fragmented, undocumented legacy templates. Most carry no documentation; several require reading raw template source code to determine what their parameters do. One template in active use across 47 pages cannot represent mobile-stress accentuation paradigms — classes of words whose stressed syllable shifts to a different syllable across inflected forms, rather than staying fixed — at all, meaning entries that use it appear to have inflection coverage but silently do not. A further 198 lemma pages have been explicitly flagged by the community as missing inflection tables entirely. The practical result is that contributing Lithuanian inflection data currently requires both a thorough command of Lithuanian morphology and substantial familiarity with undocumented wikitext code — a combination that excludes most potential contributors.
This proposal replaces that infrastructure with a unified, modular Lua-based inflection system: one module per part of speech, all sharing a common parameter convention and a common shared-logic layer, each generating complete inflection tables automatically from a word's citation form and accentuation paradigm. The system is partially built, with progress uneven across parts of speech: the shared-logic layer exists, and the noun and adjective modules are near-complete, while verbs and participles remain at prototype stage and adverbs and numerals are not yet started. This grant funds the remaining development, validation, migration, and documentation work required to take the system from its current partial state to full deployment.
The budget covers only work to be carried out during the grant period. Components already complete at the time of application — the existing shared-logic layer and the near-complete noun and adjective modules — are not charged to the grant; the per-component day estimates in the budget reflect only the remaining work on each.
Product strategy and roadmap
[edit]The project runs over 15 weeks (August 31–December 13, 2026) at 4 developer-days per week, organized into six phases:
Phase 1 – Architecture consolidation (Week 1): Consolidate the shared logic that all modules draw on into Module:lt-common and update the existing modules to reference it cleanly, verifying that the current codebase loads without errors before part-of-speech work begins.
Phase 2 – Module completion by part of speech (Weeks 2–10): Complete inflection modules in order of current development status and logical dependency: nouns and proper nouns (near-complete), adjectives (near-complete), pronouns (mostly working), verbs (prototype; largest single phase), participles (prototype; reuses adjective logic), adverbs (new; reuses adjective logic), numerals (new; mixed adjectival and nominal behavior). Multi-word noun–adjective phrase integration to follow in Week 7 once both modules are stable.
Phase 3 – Headword-line templates (Weeks 10–11): Build one consistent headword template per part of speech using a unified parameter convention. At the end of Week 11, once all modules and headword templates are stable, a migration proposal is posted to the Beer Parlour for community review.
Phase 4 – Validation (Weeks 5 and 12, ongoing throughout): Cross-check generated forms against multiple Lithuanian grammar references; resolve conflicts with the language consultant and, where necessary, by correspondence with the State Commission of the Lithuanian Language (VLKK).
Phase 5' – Community review, migration tooling, and execution (Weeks 12–14): Weeks 12 and 13 serve as the community discussion period for the Beer Parlour proposal; the migration tool is built in parallel during this window. Migration proceeds in Week 14 only after the discussion period closes with no unresolved objections.
Phase 6 – Documentation (Week 15): Technical documentation for each module and grammar overview pages for non-specialist editors.
Note on the Phase 2 estimate: Verbs receive the largest single allocation because, unlike the nominal parts of speech (nouns, adjectives, participles), which share a common accentuation-paradigm framework, verb inflection follows an entirely separate generative logic and involves morphological phenomena that the nominal parts of speech do not exhibit, so none of the nominal logic layer can be reused. Regular conjugation across all grammatical forms is already implemented, pending integration with the shared logic layer consolidated in Phase 1, after which the remaining nine days cover reflexive and prefixed verb formation and other verb-specific complications that require targeted handling, built on that working core, using the same module-construction pattern already applied to nouns, adjectives, and pronouns.
Progress will be tracked on a dedicated English Wiktionary project page, updated weekly and accessible to any community member or Program Officer throughout the grant period.
Technical approach
[edit]All deliverables are on-wiki Lua modules hosted on English Wiktionary, rendered via the Scribunto extension. No external server infrastructure is required or used.
The modules share a common logic layer through Module:lt-common — an existing module created in March 2025 and substantially reworked in April–May 2026 to consolidate shared logic used across the pronunciation and inflection modules — which handles shared character processing, encoding utilities, and Lithuanian-specific functions used across all parts of speech. Individual part-of-speech modules depend on standard English Wiktionary infrastructure modules (Module:string utilities, Module:links, Module:languages) and cross-reference each other where morphological logic is shared: the noun module references the adjective module to handle noun–adjective phrases; the participle module reuses adjective inflection logic.
The migration script is a Python tool using the mwclient library, executed on the developer's local machine. It reads existing Wiktionary page content and writes updated content via the TongcyBot account, which holds an active bot flag on English Wiktionary. This architecture is identical to the one used for the lt-pron migration, which updated approximately 20,000 pages without incident. Processing approximately 8,400 lemma pages is expected to take under 24 hours of runtime.
- 5. What is the expected impact of your project, and how will you measure success?
Include the following points in your answer:
- Milestones and progress tracking
- Project impact and success metrics
Milestones and progress tracking
[edit]Progress will be tracked on a dedicated English Wiktionary project page, updated at the end of each week and publicly accessible throughout the grant period. Each phase has a concrete, on-wiki-verifiable completion checkpoint:
- Phase 1 complete: shared logic consolidated into Module:lt-common, existing modules updated to reference it, no loading errors in current codebase
- Phase 2 complete: each part-of-speech module generates correct output for common cases
- Phase 3 complete: consistent headword templates deployed for all parts of speech; Beer Parlour migration proposal posted
- Phase 4 complete: generated forms cross-checked against reference grammars; unresolved cases documented
- Phase 5 complete: community discussion period closed with no unresolved objections; migration executed on lemma pages; cleanup category live
- Phase 6 complete: technical documentation and grammar overview pages published
The Beer Parlour migration review thread (Phase 5) functions as a formal community checkpoint: migration does not proceed until the thread has been open for at least two weeks and any raised concerns have been addressed.
Project impact and success metrics
[edit]Grant-period deliverables (directly verifiable at project close):
[edit]Seven Lua inflection modules deployed on English Wiktionary, one per part of speech: nouns and proper nouns, adjectives, pronouns, verbs, participles, adverbs, and numerals. Approximately 8,400 Lithuanian lemma pages migrated from legacy templates to the new module system. Approximately 100 legacy inflection and headword-line templates deprecated. Ten or more technical documentation and grammar overview pages published.
These are measurable via on-wiki transclusion counts (Special:WhatLinksHere), bot edit logs, and direct page counts — all publicly visible and independently verifiable.
Early indicators observable during the grant period:
[edit]A cleanup category will be created to flag entries that require manual attention after migration. Its initial population reflects the scope of the legacy infrastructure problem; its composition over time provides a signal of community engagement with the new system.
Expected post-grant impact:
[edit]The primary long-term effect of this project is not the migration itself — which is executed by bot — but the removal of the infrastructure barrier that has made Lithuanian contribution inaccessible. Whether this translates into increased editor activity is not guaranteed within any fixed timeframe, but it is observable: the cleanup category should shrink through editor action rather than bot action over the months following deployment; editors should begin creating entries for morphologically complex forms, particularly verbs and participles, that were effectively inaccessible under the old infrastructure. Neither of these is a grant deliverable, but both are publicly visible and provide a meaningful signal of whether the project achieved its underlying goal.
A secondary expected impact is architectural: the documented module system provides a working reference model for Baltic language editors considering comparable projects for Latvian, Samogitian, or Latgalian, none of which currently has a unified Lua-based inflection system on English Wiktionary.
- 6. Who is your target audience, and how have you confirmed there is demand for this project? How did you engage with the Wikimedia community?
Include the following points in your answer:
- Project demand and target audience description
- Links to interaction(s) with Wikimedia community
- Evidence from community consultation such as the [Community Wishlist]
Target audience
[edit]The primary audience is current and prospective editors of English Wiktionary who work on Lithuanian entries. Within the past 30 days, 192 distinct registered editors made at least one edit to a Lithuanian-only entry, representing the active editor population that stands to benefit most directly from the infrastructure improvements this project delivers.
The barrier these editors face is not an absence of inflection information, but a template infrastructure that has left significant, measurable gaps in coverage. Cross-referenced against Dabartinės lietuvių kalbos tarties žodynas (Kazlauskienė, Raškinis & Vaičiūnas, comps., Vytautas Magnus University, 2021; [1]), a reference dictionary of approximately 145,534 stressed and phonetically transcribed Lithuanian headwords, English Wiktionary's current Lithuanian lemma count shows that nouns and proper nouns are covered at approximately 6.25% ((4,328 + 1,869) / 99,238; [2], [3]), while verbs are covered at approximately 2.71% (933 / 34,411; [4]), roughly 2.3× lower relative to their share of the reference dictionary. The structural reasons this project treats verb inflection as a larger undertaking than noun inflection are discussed in Q4 (Note on the Phase 2 estimate). The unified system replaces the current infrastructure with a single, consistent interface across all parts of speech: an editor supplies a word's citation form and accentuation paradigm, and a complete inflection table is generated automatically.
A secondary audience is Lithuanian language learners, researchers, and developers of natural language processing tools. No existing Lithuanian lexicographic resource provides coverage of this depth under a license permitting unrestricted reuse, including for commercial purposes. English Wiktionary's CC BY-SA 4.0 / GFDL license places no such constraints, making a complete, machine-readable Lithuanian inflection and accentuation dataset on Wiktionary uniquely valuable for language technology applications targeting Baltic languages.
Community demand and engagement
[edit]Demand for this project originated in community discussion rather than being proposed in isolation. In a February 2026 Grease Pit thread about updating the Lithuanian noun headword template, two experienced editors independently identified the same underlying need: Dijacz wrote that "someone REALLY ought to make a comprehensive Lithuanian noun declension module... instead of several separate declension templates and paradigms," and Helrasincke agreed that "a single, unified template would be a dream." In response, the applicant posted a working prototype of the noun declension module, demonstrating that the approach was technically viable. Thread: [5]
The Beer Parlour discussion linked below documents community engagement for Module:lt-pron, the pronunciation module developed and deployed by the applicant in 2026. The applicant opened a thread notifying the Lithuanian-language community of the new module, actively responded to questions and corrections raised by Dijacz and Eragonas5 over two weeks, and proceeded with deployment after the community had been given the opportunity to review and raise concerns. This established the working method that will be followed for the inflection project: a Beer Parlour thread will be opened before any migration is executed, community members will be notified, and the applicant will respond to all feedback before proceeding. Thread: [6]
For per-language technical decisions of this kind, English Wiktionary does not operate through formal votes or explicit approval procedures; consensus is established through substantive engagement with the relevant community, with the absence of unresolved objections after a reasonable period taken as an indication that the proposed approach is acceptable.
- 7. How will your team predict and manage potential user security and privacy risks, and what risks do you currently see?
Include the following points in your answer:
- The level of in-house or consulted security and privacy expertise you will have available to you during delivery of this project
- How your development, testing, and deployment processes mitigate the introduction of unnecessary security or privacy risks
Security and privacy expertise
[edit]The applicant has direct experience deploying a large-scale bot migration on English Wiktionary (Module:lt-pron, approximately 20,000 pages) and is familiar with the relevant Wikimedia developer guidelines, API usage policies, and bot operator expectations. No external security consultants are required for this project given its technical scope, described below.
Architecture-level risk profile
[edit]The Lua inflection modules run entirely within Scribunto's sandboxed environment on English Wiktionary. Scribunto modules cannot make external HTTP requests, access the filesystem, or interact with user data. This is an architectural constraint, not a configuration choice, and eliminates an entire class of security and privacy risks at the infrastructure level.
The migration script accesses only English Wiktionary's public API via the mwclient library, authenticated under the TongcyBot account (the applicant's dedicated bot account). It reads page content and writes updated wikitext; it does not access, store, or transmit any user data. All external data sources consulted during development (kalbu.vdu.lt, ekalba.lt, vardai.vlkk.lt) are public-facing read-only linguistic databases with no user data component.
Development and deployment process
[edit]Lua modules are developed and tested in on-wiki sandboxes throughout development. Two categories of error are addressed separately. Runtime errors — such as Lua tracebacks caused by malformed input or missing dependencies — surface as visible rendering failures on the page itself and are immediately apparent to any editor. Correctness errors, where a module generates a plausible but morphologically incorrect form, require systematic testing: each module is developed with a companion testcase submodule using Module:UnitTests, which checks generated inflection forms against a set of gold-standard expected outputs. These testcase submodules are on-wiki and publicly accessible.
The bot migration follows a staged deployment process: a dry run first to verify the script's output without making any edits; a canary run on a small sample of pages to confirm correct behavior in production; and full execution only after the canary results have been reviewed. Each edit is made with a clear edit summary identifying the change. A full log is maintained locally for every operation, recording the page name and the relevant old and new content fragments, enabling rapid identification and rollback of any incorrect edits. The migration script will be published publicly for community review prior to execution.
As noted in Q5 and Q6, the migration does not proceed until after a two-week Beer Parlour review period with no unresolved objections. This community review step provides an additional check on the migration plan before any large-scale changes are made.
- 8. Who is on your team, and what is your experience?
Include the following points in your answer:
- Your experience as a developer, relevant past projects
- Wikimedia SUL (developer), Gerrit, Github, Gitlab or other relevant public account handles
- Other team members, their roles and expertise
TongcyDai — project lead and sole developer
[edit]The applicant is an administrator on Chinese Wiktionary and Minnan Wiktionary, and a bot operator on Chinese Wiktionary, English Wiktionary, and Wikidata. The most directly relevant prior project is Module:lt-pron, a Lithuanian pronunciation module developed, community-reviewed, and deployed by the applicant in 2026. That project covered the full delivery cycle this proposal requires: module development, on-wiki documentation, community consensus-building on the Beer Parlour, bot flag acquisition, and a large-scale automated migration that updated approximately 20,000 entries over two to three days. Those entries continue to draw pronunciation data from Module:lt-pron today. The inflection system is technically more complex, but the delivery process is identical, and the community approval pathway is already in place. This is the applicant's first Wikimedia Foundation Fund request. Module:lt-pron was tractable as unfunded volunteer work because its rules are set out in a single official reference that can be read end to end; the inflection system is a substantially larger undertaking, requiring data assembly, derivation of subclasses that grammar references omit for space, and a migration far riskier than lt-pron's given the many-to-one legacy input problem described in Q4 — sustained work that volunteer time alone does not reliably accommodate.
Public account handles:
- Wikimedia SUL: TongcyDai
- Bot account: TongcyBot (active bot flag on English Wiktionary)
- GitHub: [7]
- Gist (public scripts and tools): [8]
- Phabricator:https://phabricator.wikimedia.org/p/TongcyDai/ — not required for this project, as all development and version history occur on-wiki via Lua modules
- lt-pron migration script (used for the ~20,000-page deployment): [9]
The Lithuanian inflection modules are maintained directly on English Wiktionary rather than in an external repository, because the surrounding Lua module ecosystem and rendered output are only available on-wiki; maintaining a separate off-wiki repository would add overhead without benefit. Full version history and diffs remain publicly accessible via each module and template page's on-wiki revision history, which will be linked in project reporting in place of a Gerrit/GitLab repository.
Simonas — language validation consultant
[edit]Simonas is a Lithuanian native speaker who served as language consultant during the Module:lt-pron project in a volunteer capacity. His contributions there demonstrate capabilities directly relevant to this project: he located the relevant VLKK official resolution and recent peer-reviewed literature to resolve a contested IPA-marking question that had stalled development; he translated morphophonological rules from official Lithuanian grammar references into step-by-step algorithmic logic that informed module architecture; and he corresponded directly with the VLKK linguistic advisory service to obtain an authoritative ruling on a case where two official databases produced contradictory results. (The VLKK — the State Commission of the Lithuanian Language — is the state body under the Lithuanian parliament responsible for language policy; its rulings on language questions are legally binding on companies, institutions, and media in Lithuania, which makes it the definitive authority for resolving contested forms.) These three contributions — navigating primary sources, bridging linguistic description and computational implementation, and engaging official institutions — map directly onto the validation functions this project requires.
Simonas's role is entirely advisory and off-wiki; all on-wiki implementation is performed by the applicant. He does not hold a Wikimedia account, as his involvement does not require on-wiki editing. He is aware of and has consented to his involvement in this proposal.
- 9. How will the project be maintained long-term?
Include the long-term maintenance plan with maintainer(s) in your answer. If you expect the long-term maintenance to incur expenses, please list those and the plan for long-term expense coverage.
The maintenance model does not depend on any single person remaining active, which is a deliberate design choice rather than an afterthought.
First, all modules are on-wiki. Any editor with the relevant permissions can modify them directly, without needing the original author's approval, and every change is subject to the standard version-history and discussion-page infrastructure that governs all on-wiki content. Maintenance is therefore decentralized by construction.
Second, the architecture is built to keep the cost of taking over low. The modules share a consistent parameter convention and a common logic layer, and they are documented inline at the code level, with comments explaining the logic for each morphological class and accentuation rule. Adding a new inflection subclass or correcting a stress rule requires modifying a single, clearly delimited section of the relevant module — not understanding the entire system. The testcase submodules described in Q7 give any future maintainer a way to confirm that a change produces the correct forms and has not broken existing ones, without needing to consult the original author.
Third, on the technical durability of the system: the modules depend only on other on-wiki infrastructure modules and the standard mw library, not on anything exposed to version migrations, and Scribunto's Lua environment has been stable for years. A breaking change at that level is unlikely, and if one occurred it would affect a large share of the wiki's modules at once — the kind of issue resolved in the platform's shared infrastructure, not within any individual module.
There are no ongoing expenses. The system requires no servers, subscriptions, or external services, so no long-term funding is needed to keep it running, and nothing in the maintenance plan depends on additional grants.
Finally, the applicant does not intend to leave the project. While other commitments will reduce available time, a meaningful share of it will remain allocated to English Wiktionary, so the author will in practice be reachable for issues in the period following the grant. This is offered as a supplement to the structural points above, not as the primary guarantee — the system is designed to survive without depending on it.
- 10. Under what license will your code be released, and how will you ensure the product is well documented?
Include the following points in your answer:
- Code license and compatibility with Wikimedia projects
- Documentation plan
License
[edit]All modules, templates, and documentation pages are created directly on English Wiktionary and are therefore automatically covered by Wiktionary's standard content license: per Wiktionary:Copyrights, all Wiktionary content — including module code — is dual-licensed to the public under both the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0) and the GNU Free Documentation License (GFDL). Both are recognized free licenses fully compatible with reuse and maintenance by the Wikimedia community. No separate licensing step is required, since on-wiki content inherits this policy by default; anyone may reuse, modify, or take over the code under these terms.
Documentation plan
[edit]Documentation is organized in three layers, each addressing a distinct audience, following established English Wiktionary conventions:
Template pages (for example, Template:lt-ndecl) document how an editor uses each inflection template — the parameters to supply and the output produced. This is the entry point for ordinary editors who want to add an inflection table without needing to read the underlying code.
Module pages (for example, Module:lt-noun) carry inline documentation at the code level: the function of each significant function, its parameters, and the logic of each morphological class and accentuation rule. This is the layer a future maintainer reads.
Appendix pages (for example, Appendix:Lithuanian nouns) give a grammar overview of each part of speech for editors who want to understand the linguistic background that the template pages should not be cluttered with. This follows a well-established Wiktionary convention for language-specific grammar documentation (compare Appendix:Latin second declension, Appendix:Polish pronunciation, and similar existing pages).
This three-layer structure ensures that ordinary editors, future maintainers, and editors seeking linguistic background each have a documentation entry point suited to their needs, without over-documenting any single layer. The standard is already reflected in existing work: the current noun module carries roughly 330 lines of comments across approximately 1,900 lines of code, and a near-complete draft of the corresponding template documentation for Template:lt-ndecl already exists in the applicant's sandbox ([10]), ready to be moved into place once the template itself is deployed.
- 11. Will your project depend on or contribute to third-party tools or services?
The deployed system has no runtime dependency on any third-party tool or service. The modules run entirely within Scribunto on English Wiktionary; their output depends only on the parameters supplied on the page (accented citation form, accentuation paradigm) and the inflection rules written into the module itself. No external service is contacted when a page renders.
External Lithuanian linguistic databases (kalbu.vdu.lt, ekalba.lt, vardai.vlkk.lt) are consulted by the applicant during development and validation — to determine the correct accented form, accentuation paradigm, or inflection class for a given entry — but this is a manual reference activity. The resulting values are written into the wiki page or module as static data; the live modules never query these databases. A database becoming unavailable after the grant period would have no effect on the deployed system.
On the contribution side, the project produces a complete, machine-readable Lithuanian inflection and accentuation dataset on English Wiktionary under CC BY-SA 4.0 / GFDL. As noted in Q6, this is openly reusable by third-party language-technology and NLP tools working with Baltic languages — so the project contributes to the broader open-data and open-tooling ecosystem without depending on it.
- 12. Is there anything else you’d like to share about your project? (optional)
Budget
[edit]- 13. Upload your budget for this proposal or indicate the link to it. (required)
https://docs.google.com/spreadsheets/d/1RNXd_AhR8R9bRJv5v3r3oK-3F3J55DJ-xMm_GiDSRa8/edit?usp=sharing
The USD 5,000 total covers two components: developer time (USD 4,500; 60 dev-days at USD 75/day) and a language-validation consultant honorarium (USD 500; 25 hours at USD 20/hour). No other expenses.
The developer rate (equivalent to approximately USD 9.4–12.5/hour at a 6–8 hour working day) is benchmarked against Taiwan junior software-engineer compensation (NodeFlair/Glassdoor data); the consultant rate against average Lithuanian professional rates. The "Budget & Scope" sheet itemizes all 60 dev-days across 14 scoped work packages (architecture, per-part-of-speech development, integration, validation, migration, documentation), each tied to its current development status. The "Schedule (15 wk)" sheet cross-checks this against a week-by-week plan; the totals match. Full rationale and sourcing are in the workbook.
- 14. and 15. What is the amount you are requesting for this proposal? Please provide the amount in your local currency. (required)
159211 TWD
- 16. Convert the amount requested into USD using the Oanda converter. This is done only to help you assess the USD equivalent of the requested amount. Your request should be between 500 - 5,000 USD.
5000 USD
- By submitting your proposal/funding request you confirm that you have read and agree to the Application Privacy Statement, WMF Friendly Space Policy, and the Universal Code of Conduct.
Yes
Endorsements and Feedback
[edit]Please add endorsements and feedback to the grant discussion page only. Endorsements added here will be removed automatically.
Community members are invited to share meaningful feedback on the proposal and include reasons why they endorse the proposal. Consider the following:
- Stating why the proposal is important for the communities involved and why they think the strategies chosen will achieve the results that are expected.
- Highlighting any aspects they think are particularly well developed: for instance, the strategies and activities proposed, the levels of community engagement, outreach to underrepresented groups, addressing knowledge gaps, partnerships, the overall budget and learning and evaluation section of the proposal, etc.
- Highlighting if the proposal focuses on any interesting research, learning or innovation, etc. Also if it builds on learning from past proposals developed by the individual or organization, or other Wikimedia communities.
- Analyzing if the proposal is going to contribute in any way to important developments around specific Wikimedia projects or Movement Strategy.
- Analysing if the proposal is coherent in terms of the objectives, strategies, budget, and expected results (metrics).
This is an automatically generated Meta-Wiki page. The page was copied from Fluxx, the web service of Wikimedia Foundation Funds, where the user has submitted their application. Please do not make any changes to this page because all changes will be removed after the next update. Use the discussion page for your feedback. The page was created by CR-FluxxBot.