'name' field in legacy specification is unclear

[Zazmuz]

The 'name' field in problem.yaml in the legacy specification is unclear.

It is stated as "The name of the problem in one of the languages for which a problem statement exists.".
Does this mean it's a global name across all languages? Does it mean it should default to English like in the 2023-07 format?

The only time the 'name' field is currently used in problemtools is in an "# Ugly backwards compatibility hack", setting it as the name for language empty string, '' and in all other cases the name is assigned to language code, taken from the problem-statement names.

I don't know if it makes sense to change it to be more similar to the 2023-07 format, maybe instead of defaulting to English 'en' if only a string is given, instead keeping the backwards compatible hack of setting the empty string language code '' to the name (I dont know what it is a hack for), but allowing for a map from language code to name like in 2023-07. This or simply dropping the hack.

[Matistjati]

To add to this: to make it possible to specify plain problem name in multiple languages, backporting may be a good idea. https://github.com/Kattis/problem-package-format/pull/400/files
@niemela

[niemela]

It is stated as "The name of the problem in one of the languages for which a problem statement exists.".
Does this mean it's a global name across all languages? Does it mean it should default to English like in the 2023-07 format?

No, it means exactly what is says. It must be the name of the problem in one of the languages for which problem statements are provided in the package. So, if the problem only has a Swedish statement, then the name must be in Swedish. If the problem has an Icelandic and an English statement, then the name must be in either Icelandic or English.

The only time the 'name' field is currently used in problemtools is in an "# Ugly backwards compatibility hack", setting it as the name for language empty string, '' and in all other cases the name is assigned to language code, taken from the problem-statement names.

I don't know if it makes sense to change it to be more similar to the 2023-07 format, maybe instead of defaulting to English 'en' if only a string is given, instead keeping the backwards compatible hack of setting the empty string language code '' to the name (I dont know what it is a hack for), but allowing for a map from language code to name like in 2023-07. This or simply dropping the hack.

I don't understand this comment. You say "The only time the 'name' field is currently used", but then you seem to be talking about language codes?

[niemela]

To add to this: to make it possible to specify plain problem name in multiple languages, backporting may be a good idea. https://github.com/Kattis/problem-package-format/pull/400/files
@niemela

Yeah, a backport certainly would be nice, but we should be very careful with what we put into legacy. If we had instead named the version 1.0, we could have put these kinds of "backports" (because I think there are a handful that would make sense) in a version 1.1, that would be kinda clean.

(Those of you screaming "Told you so!" at your screens, feel free to comment)

[Matistjati]

In practice, it's probably fine not to backport it, given that it doesn't really matter; requiring LaTeX in the problem name is very rare.

[niemela]

In practice, it's probably fine not to backport it, given that it doesn't really matter; requiring LaTeX in the problem name is very rare.

For legacy we have the plainproblemname thing, which is not documented in the spec, but I would argue that that's an oversight, and we should add it in.

[Matistjati]

Yeah, I tried to address this is #400. Perhaps it's better to instead document what we're doing instead of what we wish we were doing :).

[Zazmuz]

No, it means exactly what is says. It must be the name of the problem in one of the languages for which problem statements are provided in the package. So, if the problem only has a Swedish statement, then the name must be in Swedish. If the problem has an Icelandic and an English statement, then the name must be in either Icelandic or English.

Yes I understand what is meant to go in the field, I am moreso asking what does this mean in practice. What does it mean to have a name in the config for one of the languages? What should it be used for? That part is very unclear, in my opinion it implies either:

• that it is the name for the problem and that language does not matter and it should be treated a global name across languages.
• that it is a field without any use and does not have any impact on any language.
• that it should default to English like in the new format (though this is does not really make sense).

I don't understand this comment. You sat "The only time the 'name' field is currently used", but then you seem to be talking about language codes?

Yes in problemtools for legacy name is internally a map from language code to problem name, that in legacy is currently created by only looking at the problem-statement names. The only time the value put into the 'name' field is used is to define a key '' (empty string) to have the value put into that field, and with a comment saying "# Ugly backwards compatibility hack".

I hope this clears up my points

[niemela]

Yeah, I tried to address this is #400. Perhaps it's better to instead document what we're doing instead of what we wish we were doing :).

For legacy we should definitely document what we are doing. For the new format we can choose to change (but we should not do so unnecessarily). I think we should retire plainproblemname, so it should be added to the legacy spec, but not the 2023-07 spec.

[Matistjati]

Completely agree.

[niemela]

Yes I understand what is meant to go in the field, I am moreso asking what does this mean in practice. What does it mean to have a name in the config for one of the languages? What should it be used for? That part is very unclear, in my opinion it implies either: [...]

Ok, so you do understand what it means, but you're questioning why that is useful. That's a good point, and that's why we're changing it in the new version.

Yes in problemtools for legacy name is internally a map from language code to problem name, that in legacy is currently created by only looking at the problem-statement names.

This makes sense, for exactly the reasons you point out above.

The only time the value put into the 'name' field is used is to define a key '' (empty string) to have the value put into that field, and with a comment saying "# Ugly backwards compatibility hack".

I don't actually know what the "Ugly backwards compatibility hack" is for. We should figure that out before we remove it (Chesterton’s fence), but hopefully we can remove it.

[niemela]

@Matistjati Could you make a PR for documenting plainproblemname in legacy. I think that's the only change I would like to see as a result of this ticket.

[Zazmuz]

I feel like there should be some sort of comment about how the 'name' field in legacy is HIGHLY deprecated, I've spent some good time and I can't find what this 'Ugly hack' is, which is the only use for 'name' currently.

[Matistjati]

Speaking of Chesterton's fence, it seems we accidentally removed plainproblemname a couple of weeks ago.
https://github.com/Kattis/problemtools/pull/286/files
I'll readd it and make a PR in both repos

[Matistjati]

Also @niemela, do you think it's a good idea to make problemtools match Kattis' behavior? I.e., display the problem name verbatim unless plainproblemname is provided?