cannot edit Term other than its casing

[paotsaq]

Is your feature request related to a problem? Please describe.

Terms cannot be edited in place except for case switching. (eg. "Danske can become danske or DansKE; but never Dansk, or dansk.

Describe the solution you'd like

I would like to be able to change terms in place. If by mistake I included additional words on a term, I'd like to edit both fields (term and translation) without having to create a new term altogether.

Describe alternatives you've considered

I considered deleting a term and creating a new one; but it doesn't feel right.

Additional context

@jzohrab doesn't seem to remember why this is the case. I looked into the model for Term and could not immediately find a good reason.

If terms were tied to the book they came from — but that doesn't seem to be happening. Could it be to avoid collisions?

I created the issue just to keep track of a suggestion for possible improvement. I understand this is not a priority at all.

[jzohrab]

Thanks for the notes @paotsaq.

I still can't recall all of the old reasons for this constraint, but it was necessary at one point! Things have changed since the initial implementation though, so perhaps many of those reasons have gone away.

One tricky/messy thing about the current setup is that the term contains "zero-width spaces" (zws), even in the term edit box. If your term was "Hello there", there are actually hidden characters in there: it's really "Hello| |there", with the | character actually being a zero-width-space. You can't see the zws, but if you move your cursor over them, you'll see that the cursor disappears at token breaks. These zero-width spaces are key to how Lute manages parsing and term matching in the content, so if a user accidentally deletes them (e.g., retypes "Hello| |there" as "hello there", removing the zero-width spaces), the term won't match texts anymore, causing problems. Reparsing the term is no good, because some languages actually change the parse results depending on context. In short, it's tricky :-)

The above is one reason for the "no edits" policy -- but I agree that it's not great to have it locked down like that. I don't have an approach for this at the moment, but I'll let this issue simmer and will see if there's a good way to manage it.

Cheers!

[paotsaq]

Hi! Thanks for the detailed write-up.

I think I understand the reason for not allowing manual edits. One could change a (space-separated) given term and possibly introduce problems by not including the zwc — but then, a single word term change would be okay?

And I am left wondering: if I add terms through Lute term import, will this happen too?

It feels like a solution would be just to delete the edited term and introduce a new one — making an edit really a process of delete and create, which is what I believe to be standard behavior in many object-oriented practices. But maybe (and most likely) I am oversimplifying the problem! :)

Thank you very much for the care. Lute is a wonderful project.

[jzohrab]

Lute actually parses the terms on import, so there shouldn't be a problem.

It's surprisingly tricky to navigate correctly. I don't know if there's a really good way to manage it, honestly. I wonder if it's one of those things that feels like a problem, but really isn't a terrible one ... meaning, if Lute helps keeps you reading at a good pace, then some of these things that feel important end up not being too important. I know that might feel very undisciplined to some :-) but it's served me pretty well! When you get up to a vocab of 1K, 10K, 20K words, things start to blur together.

Your approach about delete and re-create could be the right one. The terms are essentially a "value object", meaning they shouldn't be edited, b/c that can change the meaning of what it actually is. e.g. if I change "kitty" to "kitten", it's not the same thing, there are subtle differences. "Je ne sais quoi" => "Je ne sais", different. :-) But having this stupid constraint feels like Lute's getting in the way -- it certainly feels dumb! If I want to change "kitty" to "kitten" then that's what I want goddammit.

ps - The only time when I've wanted to make a term change was when I had made a very dumb term (in Spanish, I think it was something like "alcanzar a (+ inf)") and wanted to change it (to "alcanzar a"), but it was a parent term to a bunch of things. But that was just a one-off.

Unfortunately, editing a term, or even creating a new one, can result in different parsing results for some character-based languages like Japanese. But maybe we shouldn't care too much -- Lute's open source, it does the best it can, all software is a little bit broken, and so on. I could be overthinking this, it's easy to lose sight of the big picture. And again, the initial constraints that Lute had might no longer be as necessary due to the system changes. :-)

Life is fun!

I shall continue to stew on it. Thanks very much for the question and your thoughts! 👋