The goal of this project is to translate The Qubes OS Documentation into multiple languages. Translations are contributed via the Crowdin platform, automatically synchronized with the GitHub repository, and can be previewed on GitHub Pages.
We welcome anyone interested in documentation translation to join us. If the target language is not supported in the project yet, please submit an issue to request the new language. Once the requested language is added, you can start translating!
maiska has pointed out that this is unfortunately not in sync with the
existing plan there is for the localization of the Qubes OS
documentation.
Probably best to ignore until this has been resolved.
I completely understand why it might look that way at first glance, but I’d like to clarify the context behind these repos and messages.
The projects under @localizethedocs share a unified localization infrastructure. Because the underlying technical workflow, contribution methods, and project goals are identical across these projects, the core information that needs to be conveyed is naturally the same.
To maintain efficiency, I prepare a standardized announcement template. Redesigning a unique post for every single project would introduce high overhead, following the same logic as to why a project maintains a consistent format for its Release Notes.
Let me know if you have any questions about the qubesos-docs-l10n project or the localizethedocs organization.
I would also recommend not using LLM translations per default, but let the users decide for themselves. I know some professional translators who really do not kindly look upon this
I would like to confirm the Qubes OS team’s official policy on AI/LLM-generated translations:
Is it acceptable for translators to use AI/LLMs as an assistance tool when translating documentation? Furthermore, to look at a more extreme scenario, would it be acceptable if a translator simply copies and pastes AI/LLM-generated translations directly for submission?
In my dealings with collaborators, I find it necessary to distinguish “AI/LLM-generated” from “translated”. It is a common confusion.
When it matters, the work necessary to correct errors, false friends, and simple corruption of domain specific terminology in generated output, is at least 2-3 times greater than proof-reading a translation.**
Luckily for me, the consequences are only financial, and loss of reputation.
(** It is a very technical field - maybe the factor is smaller for some other areas.)
If you use generative AI in your contributions, you must disclose this at the time you submit your contribution.
I’m curious: if translators submit their translations through TMS platforms (e.g. Crowdin, Weblate, or Transifex), do they still need to disclose that their contributions used AI? If so, how should they do that?
After all, unlike Git repositories, TMS platforms don’t allow you to note AI usage in a commit message using something like Co-authored-by: AI <ai@email.com>.
There’s ongoing work to integrate localization into the official docs. This was also one of the motivations for the big migration to Read the Docs.
In fact, if the official team intends to adopt the translations maintained by the qubesos-docs-l10n project, as I demonstrated in “How to Reuse Translations?” section, it just need to make sure that the git clone command is executed in .readthedocs.yml to download the contents of the po/$version branch before building the documentation:
Then, by setting the Language field in the Read the Docs project Settings page to a language currently maintained (e.g., Traditional Chinese), the translated documentation can be successfully deployed. Below are the qubes-doc-zh-tw project I created on RTD and the forked repository I used for demonstration on GitHub:
This is nice of you. But still there - as I stressed in the github issue comment - must be a reviewing process, in which, the correctness and if I may add flawlessness in translating the technical details of the documentation (at the bare minimum) must be guaranteed.
Thus, just deploying translations, however well meaning and good they are from your organization, is not gonna cut it.
The submiting of the already done translations should be done via the translation platform and thus reviewed.
About AI/LLM/ML Translations - yes, please refer to the official document.
On my personal note - Everybody is free to do whatever they do, but it must be prior to that disclosed that such tooling is of use, so that imho extra caution/consideration is being applied.
There is a right way to engage with the Qubes project. This is not it.
If you want to contribute to Qubes, at a minimum you should read this
page
In particular, "Before you engage in an activity that will take you a
significant amount of time, like implementing a new feature, it’s
always good to contact us first, preferably via the qubes-devel mailing
list.)
You should also be aware of the guidelines on using generative AI and
disclose your use up front.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Actually, a “review process” is precisely what the qubesos-docs-l10n project currently lacks. However, even without designated Proofreaders to review translations submitted by the community, the qubesos-docs-l10n project can still utilize Crowdin’s “voting system” to decide which translations to adopt through a vote.
If the Qubes OS team intends or wishes to manage the Proofreader selection for the qubesos-docs-l10n project in the future, I can assign the “Language Coordinator for All Languages” role to you. This way, you will be able to assign appropriate Proofreaders for each language to ensure the accuracy of the translations.
qubesos-docs-l10n 
Preview: qubesos-docs-l10n
Crowdin: qubesos-docs-l10n
GitHub: qubesos-docs-l10n
