== Project information
**Name**: Wikidata Lexeme Forms
**Homepage**: https://lexeme-forms.toolforge.org/
**Project link**: https://www.wikidata.org/wiki/Wikidata:Wikidata_Lexeme_Forms, maybe? I’m not sure what the difference between Homepage and Project link is supposed to be, to be honest.
**Code repository**:
- Source branch: https://phabricator.wikimedia.org/source/tool-lexeme-forms/browse/main/ or https://github.com/lucaswerkmeister/tool-lexeme-forms/tree/main
- Target branch: https://phabricator.wikimedia.org/source/tool-lexeme-forms/browse/main/ or https://github.com/lucaswerkmeister/tool-lexeme-forms/tree/main
- Note: so far, my experience with Phabricator’s code review tools has been dreadful, so I would much prefer translation exports through GitHub pull requests. (In theory, I could give the exporter push rights to the main branch, but I would still need to manually deploy the translations, so I would prefer for the exporter to open pull requests which I then merge.)
**OS License**: AGPLv3+ for source code, CC BY-SA 3.0 for translations
**Issue Tracker**: Mixture of different channels, so far; https://github.com/lucaswerkmeister/tool-lexeme-forms/issues might be the best one.
**Project contact**: [User:Lucas Werkmeister](https://translatewiki.net/wiki/User:Lucas_Werkmeister)
**Logo**:
* Without text: None so far.
* With text: Ditto.
**Project description**:
Wikidata Lexeme Forms is a tool to create and edit the Forms of Wikidata Lexemes, based on templates that define what different kind of Lexemes look like – for instance, there are forms for English nouns, German verbs, Bengali nouns (animate), etc. The templates are maintained on wiki pages (see [Wikidata:Wikidata Lexeme Forms#Language support](https://www.wikidata.org/wiki/Wikidata:Wikidata_Lexeme_Forms#Language_support)), and currently, translations are maintained on the same pages. Both the templates and the translations are manually synchronized from the wiki pages to the tool’s source code (Python) by the developers (mainly me).
The subject of moving those translations to translatewiki.net has been brought up before (cc @Amire80), but I don’t even remember where that was, so I figure it makes sense to kick it off again here. From my point of view as the developer of the tool, the main expected benefit would be to make it easier to add new messages. Currently, if I add a new feature (or some other improvement, e.g. nicer error pages) that introduces a new message, this will require me to add the message to all the language pages on-wiki, so that it can be translated; I’m starting to notice that the prospect of having to update dozens of wiki pages discourages me from such new developments, which doesn’t seem like a healthy incentive. I hope that moving the translations to translatewiki.net will remove that barrier. From a translator’s point of view, I’m told that editing translatewiki.net is more convenient than the current workflow.
The main problem I see is the message syntax. The tool is written in Python, so the standard MediaWiki formatting (`{{PLURAL:}}`, `{{GENDER:}}`) is not available; I wrote some Python formatters that recognize a more Pythonic syntax, and manually translate the MediaWiki syntax to the Python one when moving the translations to the source code, for instance:
> $1, $2, {{PLURAL:$3|0=no statements|one statement|$3 statements}}
```lang=python
{form_link}, {grammatical_feature_labels!l}, {statements!p:0=no statements:one=one statement:other={statements} statements}
```
> Ci dispiace, ma non sei {{GENDER:$1|autorizzato|autorizzata|autorizzato/a}} a usare il caricamento di massa.
```lang=python
Ci dispiace, ma non sei {user!g:m=autorizzato:f=autorizzata:n=autorizzato/a} a usare il caricamento di massa.
```
The first example demonstrates plural (`!p`, `{{PLURAL:}}`) and list (`!l`, no MediaWiki equivalent) handling, whereas the second example demonstrates gender (`!g`, `{{GENDER:}}`) handling. All Python examples also use variable names (`form_link` etc.) rather than numeric indices (`$1`, `$2` etc.), though it’s probably possible to migrate the Python code to positional arguments if adding the variable names to the translatewiki.net export proves unfeasible.
Is it possible to make translatewiki.net translate the MediaWiki syntax to the Python syntax on export? If not, is it acceptable to require translators to write the Python syntax directly when translating?
Another peculiarity of this tool is that the translations are directly tied to the template: there’s no way to select the user interface language – rather, the interface language is the same as the language of the template you’re currently using. (The index page, where the template is selected, has no interface messages at all; the nav bar at the top is always in English.) For this reason, I think it would make sense to limit translations into new languages on translatewiki.net: there’s no point in people spending time on writing, say, Japanese translations of all messages, if nobody is going to see them because the tool has no Japanese templates yet.
NOTE: Section below will be filled by twn staff
== Project setup checklist
[x] Project information (see template above)
[x] Content fit
[x] Quality of strings
[ ] Message documentation
[ ] Activity
[x] File format: JSON
[ ] Commit access
[ ] Update [[ https://translatewiki.net/wiki/Project:News | Translatewiki.net news ]]
[ ] Update [[ https://translatewiki.net/wiki/Group_descriptions | Translatewiki.net group description ]]
[ ] Create project page
== Project configuration (for translation admins)
Namespace: `NS_WIKIMEDIA`
Prefix: `tool-lexeme-forms-`
Validators:
1. MediaWikiPlural
2. MediaWikiParameter
3. HtmlTagInsertablesSuggester (Insertables)
=== Concerns
- [ ] 1. [[ https://translatewiki.net/wiki/Translating:Localisation_for_developers#Message_documentation | Message documentation ]] (qqq.json) file is missing from the repository. An example of this file is here: https://github.com/wikimedia/ws-export/blob/main/i18n/qqq.json
- [ ] 2. Please provide commit access to the user: https://github.com/translatewiki to the GitHub repository.