[Feature] Support grammatical cases

[TheAlgorythm]

Languages like German have something called grammatical cases which causes inflection of nouns. So depending on the context sentence the noun will be in a different form. Therefore, using an automatic glossary is challenging and using the display parameter all the time defeats the purpose.
Therefore, I propose a relatively simple optional addition which may look like this:

#let entry-list = (
  (
    key: "ram",
    short: "RAM",
    long: "Arbeitsspeicher",
    longplural: "Arbeitsspeicher",
    cases: (
      genitiv: (
        long: "Arbeitsspeichers",
      ),
      dativ: (
        longplural: "Arbeitsspeichern",
      ),
    ),
  ),
)

Der #gls("ram")
Des #gls("ram", case: "genitiv")
Den #glspl("ram", case: "dativ")

[TheAlgorythm]

If this feature is wanted I would be able to implement it.

Basically the most important change would be in the __get_attribute function and then just some additional optional parameters and wiring.

#let __get_attribute(entry, attrname, case) = {
  if case != none {
    return entry.cases.at(case).at(attrname, default: entry.at(attrname))
  } else {
    return entry.at(attrname)
  }
}

If there are other use cases where such a specialization is helpful it would also be possible to rename it to specialization instead of case.

[quachpas]

Hi @TheAlgorythm, thanks for the interesting use case! Would you be able to use the custom attribute for that purpose? It's not documented (this is a WIP #86... sorry about that!!).

[TheAlgorythm]

If i've understood custom correctly, it is possible to use it with multiple subattributes. Then it is possible but rather hacky.
Because then you can't use the automagic of glossarium like letting it decide to use the short or long form and so on. Therefore my specialization based approach would be inferior imo as it integrates well with the current design.

[quachpas]

I'll have to think about how to best approach this. As it is, it would add a lot of complexity, when I find the package a little bit too complex already (in terms of implementation).
Specialized derivation was never meant to be the purpose of glossarium.

In your case, I am wondering if for the regular cases, it would be possible to use the suffix parameter, and for the irregular cases display? Obviously, it's a lot more work, but that wouldn't change defining the initial dictionary of terms in the first place.

Another possibility would be to define as many glossarium entries as necessary for each case, e.g., "ram", "ram/acc", etc. Then you would simply write. That would make it shorter to write Des @ram/gen but also not have a unique first usage across the terms.

I'm open to suggestions on that, as long as the implementation doesn't overextend the current library too much (up to interpretation obviously).

[TheAlgorythm]

I will try to implement specialisation for my bachelor thesis myself as the other options aren't ergonomic enough for me. I don't think, that it's a lot of complexity, but I get, that it's maybe too much. I will let you know when it's done, so that you can decide yourself if it's too much.

[quachpas]

Thinking about it, there should be an opportunity for implementing arbitrary attributes from the user side, as long as it's not default behaviour (with an option in register-glossary). Internally, there are interfaces to pass functions for attributes, you can take a look if you're interested.

I will try to implement specialisation for my bachelor thesis myself as the other options aren't ergonomic enough for me. I don't think, that it's a lot of complexity, but I get, that it's maybe too much. I will let you know when it's done, so that you can decide yourself if it's too much.

[quachpas]

Hi @TheAlgorythm , thanks for the wip patch. As I said previously, maybe it would be better to have a generic attribute generation and expose some kind of options to let the user have arbitrary entry attributes.

Atm, that's the option I'm leaning towards, as adding the special attribute does not feel like a good technical solution for your case.

[quachpas]

Hi @TheAlgorythm , thanks for the wip patch. As I said previously, maybe it would be better to have a generic attribute generation and expose some kind of options to let the user have arbitrary entry attributes.

Atm, that's the option I'm leaning towards, as adding the special attribute does not feel like a good technical solution for your case.