Translation support for module "practice"

[shprotru]

Next step for #17097

This is initial support for translation for module "practice".

preview:

Details

[jonbgamble]

@superuser-does any idea when was the last time we edited/added a new practice study? we've got the names and descriptions of these defined in mod practice UI and stored in mongo, and now with this PR there's a hard coded mapping of, effectively, the entire en-GB destination strings back to translation xml keys, which are then mapped by scalatags to the right language. it's not ideal, and it breaks as soon as a mod edits practice.

i guess the thing to do is use translation xml keys here:

sections = [
{
  name = Checkmates # Arbitrary
  id = checkmates # Arbitrary, for URL, no spaces
  studies = [{
    name = Piece Checkmates I
    id = BJy6fEDf
    desc = Basic checkmates
  },{
    name = Checkmate Patterns I
    id = fE4k21MW
    desc = Recognize the patterns
  },{
    name = Checkmate Patterns II
    id = 8yadFPpU
    desc = Recognize the patterns
  },{
    name = Checkmate Patterns III
    id = PDkQDt6u
    desc = Recognize the patterns
  },{

?

[shprotru]

@schlawg greetings! Please, give me advices on how can be right translation implemented differ way: where should be stored translation for sections[].name and how it should be named?
We create additional translation files spamdb/data/practice-config.en_US.txt, contain language code just as filename, and internally same structure as practice-config.txt. After that we edit spamdb/modules/env.py and spamdb/modules/study.py to meke it upload into collection flag new documents practice_en_US, same name with language code, or directly into document's field config_en_US. Or, may be you wish somehow else, just give me instructions how, this is important to not do same work several times) After that we should appeal from code, using currently selected language code to collection or document which contains our translation, if it's absent, than appeal to the default data. Better implement that as stored procedure, that will take an argument from application layer, do all that checks and gettings, and return resulting strings, or implement that on application layer? Additionally we should make possible upload string identifiers to crowdin, and I currently have no ideas how it should be implemented for that repository, and this is an other big question for me.

Generally, I think this should implemented for 3 steps(PR's):

1. Placing(where?) new translation files, make chenges to translation files uploading into db, implement necessary stored procedure into lila-db-seed
2. Creating translated page routes, change data fetching from flags collection, using that procedure in repo lila
3. Implement the rest for lila-db-seed, which serve all crowdin workflow: string extraction, uploading, etc.

Additionally en-GB language code, which you are noticed, is currently seems absent in lila, am I right understand you?

Details

We don't have to be afraid hardcode currently, because I can manually maintain all changes for this module and operatively send you PR's on updates, while I will doing implementation based on DB translation mechanisms. And will do that for enough long time.

[jonbgamble]

lila-db-seed is just spam data. the real practice config text is stored in a monogodb collection on our production infrastructure. it's nothing wrong that you did, this is our problem to solve before practice can be translated.

[shprotru]

@schlawg oh, if I can be somehow helpful, just contact me directly in discord PM or email: [email protected]. I really want the practice section support translations ❤️

[superuser-does]

I left a more detailed comment in our internal discussion, and will reiterate it here for visibility.

any idea when was the last time we edited/added a new practice study?

The last real edits to the copy were in 2024, with minor adjustments in January 2025. There remains some feedback in #14219 that requires a decision. The decision to effectively freeze the strings should follow some final adjustments to Practice.

We should consider doing a phased release. In a phased approach, we'd first determine which parts of the course we are happy with. They should represent well-written content with an appropriate learning curve. After that, let's make only the OK parts translateable.

This will be a good impetus to actually complete the course. There have often been ideas about expanding it out, and setting a vision for what the Practice course should be, will give us an idea of when a module can be considered 'final'. For example, we may be looking to make a complete one-volume guide to the game, akin to the Mammoth Book of Chess by Graham Burgess.

In summary, here is what I'd suggest:

1. Set a vision for /practice
2. Determine what pages we are happy with so far (I am making the assumption we will want to revise some parts of the course)
3. Make the modules we are happy with translateable, with the understanding they will probably never change again.

[ornicar]

Well this is our last chance to improve the wording:

https://github.com/shprotru/lila/edit/i17097_practice/translation/source/practice.xml?pr=/lichess-org/lila/pull/17969

Many of these sentences are rather lame. That's because I wrote them, rather quickly, while building the feature, a long time ago.

Anyone wants to improve them before they're sent to mass translation?

You can do it right from your browser by going to https://github.com/shprotru/lila/edit/i17097_practice/translation/source/practice.xml?pr=/lichess-org/lila/pull/17969

[jonbgamble]

@superuser-does
are you happy with the existing strings? thibault gave a link to edit them.

i think they're better than nothing. if they're fine, lichess should either request new changes from shprotru or merge this hard work. old PRs start to smell after a few months.

[Truthdoc]

Hi ornicar, schlawg, shprotru, and superuser-does,

I've been tasked to handle this issue a while ago. I will set out a vision for /practice by the end of November. I expect that we can effectively freeze a few pages and make them translatable, but others will have to be part of a larger overhaul. Let's wait until we have the vision before progressing any further. Thank you for your hard work on this!

[jonbgamble]

hi Truthdoc, who tasked you? do you envision a lot of the strings changing?

[Truthdoc]

Hey, I'm taking this on as the community coordinator

[Truthdoc]

The philosophy behind /prcatice has been set out as “Practice is based on the idea of playing against a chess engine in positions that are specifically designed to be instructive, allowing the user to learn about themes, recognize patterns and practice techniques.”

/Practice is not about being a comprehensive chess course; it’s right there in the name, as well as the above explanation, that it is more about practicing certain types of positions. Now, since elementary positions, which are known to all players beyond a certain level, are fixed, it is easy to “freeze” /practice. Before being able to freeze /practice or parts of /practice, though, it is important to be as comprehensive as possible and to ensure /practice as a whole remains cohesive.

After having played through /practice, I believe that there are key missing features that need to be fixed before we can effectively freeze /practice in its entirety, or at least a large part of it. The issues are as follows:

1. The idea is to “play against a chess engine”. That is all fine and dandy, but ever since the advent of neural networks, chess engines play pretty randomly in losing positions. The obvious fix here is to switch away from playing the chess engine and instead input several lines that the computer could choose, but the branching factor in some positions might be problematic. Another possible solution is to use older SF versions, perhaps just SF 11 or so. The issue is significant, and if needed I can provide more examples, but due to the non-deterministic nature of engine play, the problem might not always reveal itself. In addition, there are some positions where practicing against a non-deterministic engine is not necessary; rather, practicing one single line or style of play might be more suitable.

One example of the issue above is the following position:

https://lichess.org/practice/rook-endgames/basic-rook-endgames/pqUSUw8Y/CvqYotss

If you let the computer play, sometimes it doesn’t really show the Philidor position, instead playing a weaker offensive try or outright giving away the pawn since “everything is equally drawn”.

2. The progression is at times inconsistent. We state in our 2017 blog post that “Inside each topic, the exercises typically get progressively more difficult.” I believe “typically” is meant in a hedging type of way here, and there are several times where a more difficult puzzle is thrown midway through.

3. Similarly, the grouping at large has some inconsistencies. For example, it’s not clear why the different checkmating patterns are divided as they are. Similar patterns need to be in the same place.

4. /practice is not comprehensive. /practice must cover more positions, including more checkmating patterns and more theoretical endgames.

In light of the above, I propose to, first and foremost, improve the /practice experience so that the engine is at least testing the player on the knowledge or themes they have learned. To improve coverage, I suggest referencing old instructive books, and making sure that we include all relevant examples from said books. Examples of such books are: The Blue Book of Chess by Howard Staunton, Chess Fundamentals by José Raúl Capablanca, The Game of Chess by Siegbert Tarrasch, and Chess Strategy by Edward Lasker.

After the information has been compiled, we can better organize the work so that it remains cohesive and shows a clearer progression. There are other minor considerations, but those can wait until the larger and more important work has been completed. When we get to that stage, I believe all of /practice can effectively be frozen, and any additions will be relatively minor and not noticeably affect /practice from a more structural / cohesive perspective. Then, translation work for these various pages can take place.

I will start work on this and expect it to take about a couple of months, probably less, to compile information from these books and others, make /practice more comprehensive, and string it together better.

I hope this answers everyone's questions and makes the direction of the work clear.

[ornicar]

ok, sounds good. I still don't know how to solve the problem of stockfish not playing the expected moves in positions where it doesn't matter to it.
I highly doubt that reverting to an older engine would improve it. Equal moves are equal.