Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

specification proposal: gender verbs #1

Open
phseiff opened this issue Jan 6, 2021 · 1 comment
Open

specification proposal: gender verbs #1

phseiff opened this issue Jan 6, 2021 · 1 comment
Labels
enhancement Any issue that shouldn't be counted by isitmaintained.org needed I think we need this in the spec and implementation. spec - proposal

Comments

@phseiff
Copy link
Owner

phseiff commented Jan 6, 2021

As it is now, gender*render assumes every unknown property used as the context value of a tag to be a gendered noun.
However, nouns are not the only words whose grammatical case depends on the preferences of the person they refer to, because some pronouns are grammatically singular, whilst others are grammatically plural - I must admit that I did not think about that when I wrote version 0.1.0 of the specification.
I do, however, think that this issue is easy to address.

The requirements would be as follows:

  • When gender*render encounters an unknown word, it checks whether it is a verb or a noun. If the word is a noun with different versions for different genders, it is assumed to be a noun; otherwise, if it is a verb, it is assumed to be a verb; otherwise, it is assumed to be a noun. This construction should suffice to ensure that, in cases where a word can be a noun as well as a verb (are there even words like this in the English language? Let me know if you know more about this!), confusion can be avoided by simply not setting the word into a tag if it is meant to be a noun and said noun doesn't even have multiple versions for multiple genders anyway.
  • verbs are assumed to be added to tags in their plural-form, since this form fits the "they" used in template-syntax and is easier to convert to the singular form than vice versa.
  • nouns are rendered as specified by the main specification.
  • verbs are gendered as follows: If the individuals pronoun data specifies gender_verbs (potential values are singular and plural), the verb is gendered according to said information (for example, similar to https://smrtenglish.com/cg/lesson/217/2531). Otherwise, the gender is determined based on the persons pronouns (subject), and a warning should be risen (DefaultValueUsedWarning? Or a new type of warning?). Which pronouns corresponds to plural and which correspond to singular is defined by the specification (or would it be a better idea to handle it like gendered nouns and make it implementation dependent? This seems like it'd a bad idea to me since it's far more subjective). In case the pronouns can not be determined as either plural or singular, an error would be risen (probably MissingInformationError).

I feel like this is an important feature, but should not necessarily be part of the main specification, since it comes with lots of logic and therefore, seems slightly too big to me to add it to the main specification, especially since it can be encapsulated relatively well. On the other hand, it's similarly important as gendered noun handling (that is, pretty important), so maybe I should actually make it part of the main specification, or move it out of it together with noun gendering?

Comments & Opinions much appreciated.

@phseiff phseiff added spec - proposal needed I think we need this in the spec and implementation. labels Jan 6, 2021
@phseiff phseiff changed the title specification propposal: gender verbs specification proposal: gender verbs Jan 6, 2021
@phseiff phseiff added the enhancement Any issue that shouldn't be counted by isitmaintained.org label Jan 7, 2021
@phseiff
Copy link
Owner Author

phseiff commented Jan 15, 2021

I've made some thoughts on how to best structure these additions in regards to there place in the specification system, whom I will share in the following.

Noun gendering and verb gendering should probably be part of the same specification, since the way gender*render decides whether a word is a verb or a noun affects both of them, and neither wold it be elegant of one (extension)-specification to refer to the other in this matter, nor would it be elegant and/or maintainable to add this information to both (extension)-specifications.

What remains is the question whether they should be part of the main specification (this would require moving noun gendering out of the main specification, which isn't very burdensome considering the broadness in which it is explained in the main specification) or an extension specification (this would be my prefered way to go about this, since it un-bloats the main specification and leaves more room to go into noun gendering in detail).

The extension specification for this feature could be easily linked to by the main specification (which should probably mention all extension specifications anyway), and would make the underlying design decisions and concepts of this feature easier to access for people who need inspiration for implementing similar or related features. It would also make room in the main specification to integrate the global capitalization system into it, and integrate the concept of canonical context values from the implementation to the specification. Last, but not least, it would remove all features that require data sets to work from the main specification and leave only syntax, parsing, rendering, context values that directly map between template and pronoun data, capitalization system and id resolution to the main specification, which appears more consequential to me than having noun gendering as a part of the main specification, but verb gendering, possessive forms of nouns and other features in the extension specifications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Any issue that shouldn't be counted by isitmaintained.org needed I think we need this in the spec and implementation. spec - proposal
Projects
None yet
Development

No branches or pull requests

1 participant