Non-English manuals should be translations of English master #1832
Comments
|
I strongly suggest to the nextCloud team to migrate the documentation to an awesome MediaWiki instance. With the Extension:Translate it will be super-easy to translate everything and keeping everything updated. This is an example of some Translated pages: This is the super-simple translation interface (in this case is even public for everyone, but you can change it): This is maybe related to #216 |
|
Quite agree with @vasyugan! There is a chapter in the readthedocs, ahem, docs explaining how to utilise gettext for translation: https://docs.readthedocs.io/en/stable/guides/manage-translations.html and later integrate with transifex. BTW, translation link, mentioned in the latest docs yields 404 |
|
Yeeep, that would be very awesome! |
That's a good starting point. We can provide some hardware and technical resources to create a MediaWiki instance for you with the Translate extension enabled. The documentation provided in this way could be released under CC BY-SA of course, in order to allow you to dump it anytime on your hardware. In the other hand it's not clear to me if the official documentation is already under a free cultural work license, to start something from it and allowing the community to going on, instead of doing a complete rewrite to avoid any legal issue. Can you just clarify this point? |
|
@valerio-bozzolan why are you so biased towards wiki engine? IMHO, readthedocs is quite decent platform and it's quite popular nowadays. It is a cloud solution provided free of charge, supporting integrations with collaborative translation platforms. Also, it provides means to download offline docs, too. With readthedocs documentation source code is hosted under git allowing merge requests for docs improvements. Not sure if wiki angine will cover all those aspects... |
|
I'm interested in boosting the translation process, allowing non-tech translators volunteers in contributing, because actually I see this problem: very few people are contributing in this sector. So much years are passed since the first release, but our user documentation covers exactly 3 languages. That's a problem for the adoption of this software. The good news is that something could be changed and without much efforts. For example just trying another platform loved by translators.
Yep that's important, but that's covered too:
My friend, you found the problem: translators often does not know git, do not love it, or they have not the time for a merge request, because maybe they have time to just contribute on 2-3 paragraphs in their 5 minutes spare time in dinner pause. This involves a kind of real-time collaboration that is inefficient with git, and that's why actually our documentation is covered in 3 languages, sadly without even stubs in other languages.
Well, not to spam MediaWiki, but it has batteries included for this stuff :)
Actually I have just some interest in involve more people in this process. |
|
There are ways of hiding the complexity of gettext-based translation. See https://hosted.weblate.org/ Many free software projects are using it already. |
|
@vasyugan actually, I was meant to mention weblate (we're using it internally for gui localisation), but I did not find any references on how to integrate it with readthedocs. To be frank, as of now, the whole pipeline of delivering git docs to the readthedocs is a bit vague for me. May be, there is no need to integrate weblate with readthedocs and readthedocs will itself pull latest git revision to render all the docs. I will need to dig documentetion a bit to make more clear statements... |
In addition of what @aol-nnov said, note that Weblate is very efficient for translating user interfaces, or other one-way contributions, where you want an upstream string to be translated in multiple languages. In the other hand, with Weblate or similar solutions you do not simplify the contribution and the expansion of the original English version as-well. |
|
So we've discussed this a bunch of times. We'd love to make our docs easier to both edit and translate. But there are some requirements:
Now the very-good-to-have are:
Honestly, my idea solution would be something that allows us to run a process on one of our servers that takes our docs as they are here and gets them into Transifex so our existing community there can translate it and then generates HTML and PDF which we can put on our server and into Nextcloud. Because that hits almost all the good points above:
Any other solution is going to be problematic. Anyone know a way how to do it that way? Only if that's really not possible/feasible should we consider setting up an entirely new thing, converting everything etc etc etc... |
If transifex is an option, then by all means, go for it! As it stands, the German manual receives only a couple of edits per year, it must be heavily outdated, so it should make way for an actual translation... Since a large number of Nextcloud's users speak German, there would be some urgency in that. And of course, having Spanish, Russian, French etc manuals would be great, if volunteers show up to translate them. |
Well, yes, it would be ideal. But I don't KNOW if it is, and IF it is, somebody has to do the work, or at least the research so the 'work' can be done following a few predefined steps. The sysadmin team is sadly just too overloaded right now and they don't have time for it, as I said, at least for the next 4-6 months. So help welcome or - this won't happen any time soon. |
|
@vasyugan if you want to discuss how to help people non familiar to git to improve documentation, please open a new issue. I think, like @jospoortvliet, that we have to use git. The translation issue is already tackled in #216. I will close as the title suggests it is a duplicate of #216. |
This is maybe a broader issue, which is not easily fixed, but when contributing a little to the documentation on Thunderbird and its integration with Nextcloud calendar and contacts, I saw that the English and the German versions are substantially different. (I did a bit of fixing there but my fixes are incomplete)
Shouldn't the non-English versions be exact translations of the English one? Isn't there a standard for internationalisation of FLOSS software, with .po files / gettext, meaning that the non-English manuals shouldn't be part of this tree at all but rather be handled by a seperate translation process? Else it is a bit like Wikipedia, where every language version does their own thing with little coordination between the language versions. To me this doesn't look feasible.
The text was updated successfully, but these errors were encountered: