give feedback about variable potentially using wrong case

[Alex-Jordan]

Suppose a context has variable x, but not X (or vice versa). And a student enters an answer with X in it. The usual feedback message is variable 'X' is not defined in this context. The change here will recognize that a case change on X would make a valid variable, and adds a suggestion in the feedback message that maybe this is the student's issue.

An alternative I was considering is to replace all instances of variable '%s' is not defined in this context with variable '%s' is not defined in this context; only variables '%s' are defined in this context where the second string is the actual list of the context's variables. Would that be better?

For that matter, is what I'm proposing here a bad idea for some reason I am overlooking? Do problems ever try to hide what constitutes a valid variable?

[somiaj]

variable '%s' is not defined in this context; only variables '%s' are defined in this context where the second string is the actual list of the context's variables.

I don't like this idea. I have problems that have way too many variables defined for this to be useful.

I am for changing the feedback, I wonder if not using the word 'context' would help out students. Wonder if something like The variable '%s' is not allowed in this answer. could be more useful.

I don't have any real opinion on looking for possible case errors is helpful, but it couldn't hurt IMO.

[Alex-Jordan]

Note that these messages are not only for students entering answers. An author would see these when coding a problem and using a bad variable too. I think that often explains the occasionally cryptic (to a student) language. Because the messages try to be close to literally describing what happened in the Parser code, more than they try to assume what is happening for the user reading the message.

[somiaj]

Understood, and I agree the errors are often more technical due to that. Though I think a balance could be found, where the message is useful for both students and problem authors. Though if I were to choose, I would make the messages for students, and let authors learn that variables have to be added to the current context, vs throw the technical language at students.

A much bigger project would be to find a way to centralize these messages, and make a way to translate them (at least for the student output). Maybe also add a way to distinguish between feedback that gets given to students vs authors. But that might require a much bigger redesign of the whole error handling, which will be no easy task.

[dlglin]

I also think that making these messages more meaningful to students is the right direction to go. If the wording is clear enough, then problem authors should be able to understand what the messages are saying about the code, even if the message is less technical.

I can think of many cases where I would like to have the message tell students which variables are permitted, but as @somiaj mentioned there are other scenarios where this could be more confusing than helpful. Another case to be careful about would be adaptive parameters, which are added as variables to the context but students shouldn't be using in their answers.

I am for changing the feedback, I wonder if not using the word 'context' would help out students. Wonder if something like The variable '%s' is not allowed in this answer. could be more useful.

I agree (and so does @drgrice1) that we should get rid of the word "context" in these messages, but I don't think we can use the word "answer". The same error message is used if a problem author creates a formula object containing a variable not defined in the context (e.g. $f = Formula('X');). How about something like You can't use the variable '%s' here.?

[dpvc]

I wonder if not using the word 'context' would help out students

Remember that students are unaware that "context" has a technical meaning in the PG problem code, so they should understand "context" as its normal English meaning, which would be "the setting of the problem as a whole", or of that particular answer. (The authors will understand the technical meaning, but that will have a different meaning for them than for the students.)

That being said, you can certainly change that message if the community feels there is a better one.

I don't like this idea. I have problems that have way too many variables defined for this to be useful.

I also think this is probably a bad idea. There definitely are cases where there are "hidden" variables (there are some in the FormulaUpToConstant objects, as I recall). Also, the student might not have been trying to type a variable, but rather a function name, or a constant, but have gotten it wrong. MathObjects defaults to shining an undefined thing is a variable, but telling them the variables might not be the help they need.

the messages try to be close to literally describing what happened in the Parser code, more than they try to assume what is happening for the user reading the message.

That is because trying to tell what the user really meant is very hard. I prefer not to give misleading error messages (by making assumption about what the user was trying to do and getting that wrong), so often the only way to be sure to give a true message is to give a message about how the parsing has failed. But I'm sure some messages could be improved.

A much bigger project would be to find a way to centralize these messages, and make a way to translate them

Well, the Value->Error() method does include a means of substituting messages, and one of the goals behind that was to make translations possible. All messages are looked up through the Context()->{error}{msg} hash which can be used to replace a message with another one (the original message before substituting values is used as a key in this hash, and if present, is replaced by the key's value, and then again after substitutions are made). It would be possible to seed the Context()->{error}{msg} hash with translations for a given language, at least for the basic messages. One could look for ->Error(...) calls to find the strings and do something like a PO file from them. Of course, problems can have their own error strings, so that complicates things, but the basic infrastructure is already there.

Alternatively, the Context()->setError() method could be modified to use the PG maketext() function (or whatever it is called) that ties into the translation mechanism.

[dpvc]

Does this want to be /^$name$/i instead? As is, it will match any variable prefix (so X would match xyz if that variable were defined). I'm not sure if you want that or not.

Also, do you want to check for constants and functions? I.e., if someone entered PI would you want to suggest pi?

[dpvc]

There are some constants and functions that are "hidden", if I recall correctly, so you might need to filter them out.

[Alex-Jordan]

Thanks for catching that $. I have that in production but somehow lost it in manually moving this to where I prep pull requests.

[Alex-Jordan]

I'm good with proposing this as it is, just a case check. And forget I mentioned exposing the full list of valid variables.

I think we could explore adjusting these messages ("context", etc) later, in a separate PR if we come to concrete ideas. I don't have too much problem with "context", since I see it the way Davide described in its non technical sense. There are things like "unable to find enough text points..." where it would be nice to be friendlier to students. But I confess I don't have ideas for most messages like this that work in all generic situations the message will come up.

I hadn't thought about constants and functions. This only comes up for me in practice because a frustrated student hits this with variables. I'm not opposed to extending it to constants and functions, what do others think?

I should note that this doesn't handle multi-character variables. If there's a valid variable xy and the student enters XY, Xy, etc, then the code currently at line 25 kicks in and we never get to this change I'm proposing. So maybe there is a better way to do what I'm attempting here.

[drgrice1]

I realize after @dpvc's comment it is not the word "context" by itself that bothers me, and that students have had issues with. It is the usage of the word in the context of the sentence it is in. That is "Variable '%s' is not defined in this context". Maybe it is the word "defined" that is the issue. As a whole the sentence sounds very technical, and not something that students in my introductory courses deal well with.