Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Epic: localization #3841

Open
luixxiul opened this issue Nov 29, 2024 · 2 comments
Open

Epic: localization #3841

luixxiul opened this issue Nov 29, 2024 · 2 comments
Labels
suggestion This issue is a feature request

Comments

@luixxiul
Copy link
Collaborator

luixxiul commented Nov 29, 2024

Is your feature request related to a problem? Please describe.
I would like to see the documentation (and potentially comments inside role files) be available for localization. It will have great potential to make this project more useful.

Describe the solution you'd like
Since it will be a big task, I am not sure what solution should work, but my rough idea would be:

  • Using Weblate (hosted.weblate.org / self-hosting)
  • Use current files (especially in docs/ which are nicely rendered) as source and keep them as they are
  • Use Sphinx somehow? https://www.sphinx-doc.org/
  • Localized documentation and actual playbook should be sync'd (old and unmaintained localization can break installation based on the actual playbook); disclaimer will be required

Describe alternatives you've considered

Additional context
Let's make Matrix more international by reaching outside of Europe 🗺️

@luixxiul luixxiul added the suggestion This issue is a feature request label Nov 29, 2024
@aine-etke
Copy link
Collaborator

That sounds like a colossal effort that cannot be accomplished with current contributions level. You are the Docs Jedi of this playbook, and it took you quite a lot of time and insane effort (really appreciate that!) to fix it, now imagine how translation process will work - translations will always be outdated, and in the situation where something constantly changes, that means such docs will be useless, as they won't reflect the up-to-date situation.

So, while the idea sounds really great, I doubt the implementation will be on par with the English/main/original version.

@luixxiul
Copy link
Collaborator Author

luixxiul commented Dec 4, 2024

The basic idea is same as other projects which apply Sphinx + Weblate combination; the issue of being outdated becomes not really relevant 1) by setting a certain completion level (around ~90%?) to make the localization public (using something like this), and 2) by shipping untranslated strings as they are in English. Once localization is provided (and/or whenever *.md files are updated), a script to run the update task will be manually executed to pull localization from a Weblate instance, convert .po files into .md (for which I've created conf.py for Sphinx as a test), and push these localized *.md files to this repository (or possibly another one dedicated for handling localization), pushing original update *.md files to the Weblate instance too (note: this is just an amateur idea of mine).

IMHO, the more basic (and necessary) strings are, the less chance for constant changes there will be. So the chances for being outdated for important changes will naturally be lower, and even when there are breaking changes, we would not have to be worried about it too much, since untranslated strings will always be available on (partly) localized files too. And once the things for documentation are settled (by tidying up, removing inconsistencies, etc., stuff like I do these days), the activity for it and constant changes like today will decrease for good, unless something radical is coming up…

Also, because roles/ directory is indeed constantly updated, it should be safe to manage stable files only; mainly in docs/ and the root directory (README.md, CHANGELOG.md, and also YEAR-IN-REVIEW.md maybe).

Until we begin, we will truly be not sure how much contribution will be there, and in general among FOSS project it is low for languages which are pretty different from English, while it is mainly the countries where these languages are used that require localization (ie. I'd imagine translation into de or nl would not be useful as much as translation into zh for example). Still, if other active projects take a similar approach like above, I think it should work for us too, unless something certain (which I'm not really sure of) to this project would block it 😃

I think integrating it with this project would be ideal, but if that does not sound reasonable, I think I could take a set up another repository somewhere to try it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion This issue is a feature request
Projects
None yet
Development

No branches or pull requests

2 participants