Support multiple languages

[RagnarGrootKoerkamp]

Maybe something like this: Have a language: <en|nl|...> in contest.yaml and/or problem.yaml, so that bt will look for problem.<language>.tex instead of the default problem.en.tex.

A clean way to change the latex constants would be to have language specific en.tex, nl.tex, ... includes that contain all the hardcoded texts as commands.

Most of the diff to the NIO fork should be resolved by this.

CC @ludopulles

[mzuenni]

maybe use translator for latex with <language>.dict files.

[thorehusfeldt]

Regarding specification, language in problem.yaml would be very close to the already-existing languages (which specifies programming languages.)

Suggestion: according to the specification, the name key in problem.yaml already takes a map; it can look like this:

name:
  en: Danish Pastry
  nl: Stroopwafel
  de: Kopenhagener Gebäck
  da: Wienerbrød

From the keys in that map, we can infer the four languages and expect problem.nl.tex to exist (and complain otherwise). I can see that bapctools currently expects problem.settings.name to be a string, not a map; so this would need to be fixed.

[RagnarGrootKoerkamp]

I'd be happy to review a PR for this. I don't imagine this would be too hard to support once you know where to look. I could probably give some pointers if you'd like.

(We don't use/need this for BAPC, and sadly I don't really have time and motivation to write new code.)

[thorehusfeldt]

OK, I like this idea. My current ambition is to use BAPCtools for the next Will Code for Drinks, scheduled for November 2023; but I need to find my way around it a bit more before I commit to anything.

I forked the repo for now and implemented the default grader, which doesn’t really have much to do with statement languages to be honest.

[thorehusfeldt]

First attempt and discussion at https://github.com/RagnarGrootKoerkamp/BAPCtools/discussions/254

[thorehusfeldt]

@RagnarGrootKoerkamp : my https://github.com/thorehusfeldt/BAPCtools/tree/i18n branch now supports some basic functionality, such as

myproblem> bt pdf
myproblem> bt pdf --language nl
cd ..
mycontest> bt pdf
mycontest> bt pdf --language nl

which create myproblem.XY.pdf and mycontest.XY.pdf as expected. You can play with this in test/problems/hellowholeworld/, which has some statement translations.

The problem.yaml file now prefers the map

  name:
    en: Detour

to the string

name: Detour

problem.py still understands the “stringy” version (and translates it internally in problem.settings), but new_problem wakes up with the “mappy” version.

bt new_problem now begins by asking for problem statement languages; this could of course interact with a specification file such as locales.yaml on contest or user level. bt rename_problem iterates over all languages when renaming.

Tell me if you think this goes in the right direction. What would be useful now would be a recent BAPC source directory so that I can check backwards compatibility.

In progress

I haven’t thought solutions through, ideally I at least shouldn’t break anything. Currently, the command

bt solutions

works as before from a problemdir, except for producing solution.en.pdf. (bt solution from a contestdir is currently broken.)

[RagnarGrootKoerkamp]

I played a bit with your branch:

• The warning for language in problem.yaml that's missing from problem.xy.tex should also be an error I'd say.
• Quote the for language "en" in problem.yaml
• For solutions, I'd write solutions.pdf as long as we only have solution.tex input files. The solutions also have these header and footer files contest/solution_{header,footer}.tex that would need per-language customization. Maybe that's better for a follow-up PR if you need it.
• (Building contest solutions works for me in the 2022 BAPC repo; maybe you're missing some files.)
• I'm quite happy with this overall; will check out the code soon but I think you can PR it.
• One issue is bt export for domjuge (as mentioned in the linked discussion): It requires a single problem.pdf and does not support multiple languages. We could make bt export --language en (which is only required if there is >1 language) so specify the correct language and write problem.pdf into the zip.
• As noted on the commit: it would be nice to find a solution to keep the \begin{Input} .. \end{Input} environments in some way. Using \section*{Input} has been accidentally replaced by \subsection*{Input} in the past, and it's nice to allow header/class files to customize the styling of these. Any change to this will also need to be made to the problemtools header files for export compatibility so not ideal..

You can find the 2022 sources here https://2022.bapc.eu/, but you'll have to unzip each problem to it's own directory and some metadatafile may be missing.

[thorehusfeldt]

Thanks for your quick reply, your enthusiasm, and the quality of your response.

The warning for language in problem.yaml that's missing from problem.xy.tex should also be an error I'd say.

The specification is explicit only about one of them. But I’m happy to make both errors, just for symmetry.

But I’ll play around with this branch a bit more before I send a PR. No rush.

[mpsijm]

Implemented in #256 :tada: