#269 First iteration of Scribe-Data data contracts

[andrewtavis]

Contributor checklist

• This pull request is on a separate branch and not the main branch
• I have tested my code with the ./gradlew lintKotlin detekt test command as directed in the testing section of the contributing guide

---

Description

As discussed in #269 and in recent syncs, we need to set up data contracts that will determine how the end applications present the data coming in from Scribe-Data. This PR sends along my first ideas on them based on the call we had yesterday.

A short synopsis of this:

• For Scribe-iOS all data values are hard coded into the application
• The data might change on Wikidata's end, meaning that the labels and other information would change in Scribe-Data
  • Ex: More data being added, which as of now would require us to create a new app release to change the hard coded fields meaning that people would not have access to the new data till then
  • Ex: As of now - unlike other languages - Spanish has the feminine and masculine of nouns stored on the same lexeme
    • If this changes, then we'd then have to rework the entire way that data is accessed and the Spanish keyboard would break on the next data update requiring an update of the app

Discussed solution:

• We want to make sure that data updates are completely separate from app updates
• We create "data contracts" that are delivered with new data packs
  • Ex: User downloads Scribe-iOS/Android and wants the German keyboard
    • They get the German data and the German contract
    • Updates of the data would deliver the corresponding contract
• Note that we'd need to set up tests for Scribe-Data whereby the data that should go into the contract is changed
  • Ex again for Spanish nouns
    • Say they're split and we don't have feminine and masculine on the same lexemes
    • We check the data outputs and see if the data that's required to fulfill the current contract is coming in
    • If not, we open an issue that says what parts of the contract aren't being fulfill and we then check to see how the data has changed

Feedback is very welcome on the above! 🙏

Related issue

• [Conjugation] Possible reference of conjugation/tense labels via a conjugation metadata JSON file #269

[github-actions]

Thank you for the pull request!

The Scribe team will do our best to address your contribution as soon as we can. The following is a checklist for maintainers to make sure this process goes as well as possible. Feel free to address the points below yourself in further commits if you realize that actions are needed :)

If you're not already a member of our public Matrix community, please consider joining! We'd suggest using Element as your Matrix client, and definitely join the General and Android rooms once you're in. Also consider joining our bi-weekly Saturday dev syncs. It'd be great to have you!

Maintainer checklist

• The linting and formatting workflows within the PR checks do not indicate new errors in the files changed

• The CHANGELOG has been updated with a description of the changes for the upcoming release and the corresponding issue (if necessary)

[github-actions]

First PR Commit Check

• The commit messages for the remote branch should be checked to make sure the contributor's email is set up correctly so that they receive credit for their contribution
  - The contributor's name and icon in remote commits should be the same as what appears in the PR
  - If there's a mismatch, the contributor needs to make sure that the email they use for GitHub matches what they have for git config user.email in their local Scribe-Android repo (can be set with git config --global user.email "GITHUB_EMAIL")

[github-actions]

Code Coverage

Overall Project	0.59%	❌

There is no coverage information present for the Files changed

[andrewtavis]

Again the goal of this is that we get rid of as much of the "command variables" files from Scribe-iOS that are hard coded.

Noun gender annotation:

• Is there a canonical gender column (there is for all languages except Spanish as of now)?
• Check the singular column for the word and return it's gender
• Also check if it's in the plural column
• For Spanish we need to check to see if it's in the feminine or masculine singular columns given the contract

Plural command:

• Check if word is in the columns that are the value(s) of numbers for "Already plural"
• If not, check the key columns and return the respective value column

Conjugate command:

• The conjugations are presented to the user in the order of the dictionary object
• The title is what appears as the header in the UI
• The keys for the conjugation sub objects are the labels of the conjugation field
• The values are the value that's returned when the user presses the conjugation key
  • Return value from this column

Translate command:

• Is ultimately the easiest as the plan is that we have a word and the data that we have for it is the contract to be fulfilled
• Is the word just a noun, a verb, another type or more than one?
• Then what are the options and their descriptions
  • Ex German translation: Book -> noun or verb? -> noun -> Buch (book) or Roman (novel)

CC @axif0 as well as this effects Scribe-Data work to come :)

[andrewtavis]

@henrikth93 and @Jag-Marcel: You two having worked on iOS the most, basically mapping out files like Scribe-iOS/Keyboards/LanguageKeyboards/English/ENCommandVariables.swift. Not all of those files will be put into the contract, but everything that can change with the data :)

[angrezichatterbox]

I feel the formatting is quite good for now. As far as the experimentation I have with finding the gender of a word. I think this contract makes it easier and proper column would be used for the word depending on the data available.

[angrezichatterbox]

Could we have the naming to be capital for the language codes since we have the same format for the SQLite database naming as well ?

[andrewtavis]

Coming back to this just now, @angrezichatterbox. I guess for now can we leave them as lower case? There's something about the Scribe-i18n JSONs being the lower case language code and these ones being upper case that just doesn't look right to me 🤔 That and that these files are an extension of the Scribe-Data metadata files that are also lower case and will be generated in Scribe-Data really pushes for as it is :)

Hope this makes sense! Thanks for the feedback and all the planning that went into this 😊

[andrewtavis]

Merging this in 😊