Translation support for module "practice"

[shprotru]

Next step for #17097

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

preview:

[schlawg]

@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?

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.

[schlawg]

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: ser3da.p@yandex.ru. 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