Allow per-language Git repositories

[m-aciek]

Describe the problem

I'm considering switching with Polish translation of Python documentation to Weblate. Python documentation translations in different languages are being kept in separate Git repositories.

PO files in the repositories are stored in the main directory, without language prefix in directory structure.

"Filemask" field validation in new component form prevents entering a file mask without language code in it, which would be desired in my case. Also after creating a component potentially some other language would like to switch to using Weblate, and then we'd want those translations to land in separate Git repository, not Polish one.

Describe the solution you'd like

• Allow to by-pass filemask validation for language placeholder in the pattern.
• I think it's ok for me to have a Weblate project per language for case of Python documentation. It would be awesome to have a possibility for having single project with many repositories for different languages. Presumably that can be difficult to implement, as for as far as I know it's not compatible with current Weblate projects architecture.

Describe alternatives you've considered

I've forked original Polish Python docs translations repo and moved all resources to pl directory to set proof-of-concept project on Weblate and investigate other parts of integration.
But such a move is not an option to original repository due to the convention for fetching and rendering the docs.

Screenshots

Additional context

PEP 545 -- Python Documentation Translations

[github-actions]

This issue has been added to the backlog. It is not scheduled on the Weblate roadmap, but it eventually might be implemented.

In case you need this feature soon, please consider helping or push it by funding the development.

[josix]

+1 Currently, Traditional Chinese translation of Python documentation is facing the same problem.

[nijel]

Isn't it better for all Python documentation localization to be in a single place? This brings numerous benefits - for example, it is easier to find problematic source strings or people understanding more languages can benefit from other translations.

We do not accept single language projects in our libre hosting plan for this reason.

[m-aciek]

Definitely it would be better to have one Weblate project with multiple languages. In the issue description I was meaning to consider having separate Weblate projects for languages as a temporary workaround only. I understand and agree with your reasoning.

[nijel]

The problem here is that the "temporary workaround" means quite some development in Weblate. I don't mind getting a pull request implementing this, but it is certainly not something we would push on our own.

[burner1024]

you can create the dir and symlink the files into it

[m-aciek]

@burner1024 I created a symlink to the main directory. It occurs that currently Weblate doesn't handle that. Please see #7909. I think that creating a pl directory and many symlinks to resources instead would be very similar, and also wouldn't work.

[m-aciek]

Isn't this issue a duplicate of #5447?

[nijel]

No, this is about translating files in a single language repository, that one is about supporting configuration for language teams.

[m-aciek]

I'd like to try to tackle this issue in my free time. Instead of doing shenanigans to sync commits from Weblate backend repo to many per-language repositories outside of Weblate, I'd like to invest my time by bringing this feature in Weblate.

For now I imagine that as being able to put a placeholder in repository URL instead in filemask when configuring a component. Then repository state for such a component would be tracked on per language basis. I would like to try to do minimal changes in UX/UI as well as in the code logic to make this all work.

[nijel]

So we're looking for support of many single-language repositories within a component, right?

I think the cleanest approach from the current Weblate architecture would be to handle this within the VCS backend.

• It would check out multiple repositories in the working directory. This list should be manually configured and not use wildcards.
• The component would then be configured with an additional prefix.
• All operations would be dispatched to the actual backend for each repository.
• It should not be limited to languages only, there might be other use cases such as support cross-repository screenshot mask #10164.

Tricky parts:

• Configuration doesn't support customizing VCS configuration per backend. So for the initial implementation, I'd go with encoding all information in the repository URL. Maybe using JSON, so that UI can be built for that independently.
• Will there be a single multi-repo implementation supporting all VCS integrations (again, this would have to be configured somehow), a separate multi-repo VCS for each existing VCS, or multi-repo would be in the base class and turned on based on JSON in the URL?

The Python docs could then have a repository URL like {"pl": "https://github.com/python/python-docs-pl.git", "fr": "https://github.com/python/python-docs-pl.git"} and components would be configured like */about.po.

Do I miss something? Does it sound viable?

[m-aciek]

Thank you for your guidance on the direction.

Will there be a single multi-repo implementation supporting all VCS integrations (again, this would have to be configured somehow), a separate multi-repo VCS for each existing VCS, or multi-repo would be in the base class and turned on based on JSON in the URL?

For now I'm in favour of a single generic multi-repo implementation supporting all VCS integrations.

Then repository JSON could look like {"pl": {"vcs": "git", "repo": "https://github.com/python/python-docs-pl.git"}, "fr": {"vcs": "git", "repo": "https://github.com/python/python-docs-fr.git"}}.

If I'm not mistaken it looks like the same format should be repeated for push repository URL.

Also probably we would need a dedicated key for "new base" (POTs) repository in the repositories JSON, to use it along with msgmerge addon. Not to hack the dispatch for this case and store the POTs in a language repository.

{"pl": {"vcs": "git", "repo": "https://github.com/python/python-docs-pl.git"}, "fr": {…}, "new_base": {"vcs": "git", "repo": "https://github.com/python/python-docs-gettext.git"}.

[nijel]

Yes, that's why I didn't want to bind it to languages only. Using more complex JSON makes sense.