Simplify Translation Workflow

[ericholscher]

Currently people have to create a new project for each language of a project. This approach doesn't scale in any reasonable way. Especially now that Sphinx lets users add all of their translation material into the main repo, we should support this abstraction too.

Goals

A user should be able to go to Admin > Translations and then simply select the languages that they want built from their project. This would then build Sphinx with the command to use that language.

Front end changes

We need to add the ability to select languages to the Translations Admin panel. This should be as easy as putting a new field on the Project model, that links to our set of language constants in projects/constants.py

Backend changes

The doc builders will need to be upgraded to know what language they are building in. We need to pass the language through all the phases of the builders, which should be pretty simple. We also need to figure out the sanest directory structure for storing the output of the translation builds into. It would be great if this structure matches the URL's we expose to users more closely, so that we don't have to do as much munging of the filesystem to make nginx happy.

Issues

This might also wreck havoc on our locking and rate limiting situations. When a new commit of the project is pushed, do we trigger a rebuild of every translation? Potentially adding 10-20x load to the build servers for every project doc build.

[sebgoa]

Couple comments:

• In our case the git push should only trigger a build of english (the main language), since the other ones are more manual and only built when new strings are pulled from transifex. So no need for an automatic rebuild of each translation IMHO.
• We need to make sure that the canonical URL will also be handle nicely in the case where we have a parent project and translations in each subproject.

[sebgoa]

@ericholscher any luck with this ?

[e9t]

+1 for this issue.

[guokan-shang]

#1280

[73VW]

Hello everyone, do you need help on this?

[neoctobers]

+1

[humitos]

I don't think we can realistically support this at a core level.

As a workaround, users could remove the "language" part from the URL (via #10307) and build all the translations in the same build process outputting each of them under $READTHEDOCS_OUTPUT/html/<language>/ making the final URL being docs.example.com/<version>/<language>/

I think that's enough for this use case, and I'd say we can close this issue. Feel free to re-open, tho.