Open phseiff opened 3 years ago
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.
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:
gender_verbs
(potential values aresingular
andplural
), 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 toplural
and which correspond tosingular
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 (probablyMissingInformationError
).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.