+++ This bug was initially created as a clone of Bug #5213 +++ > Both Marcom and Artwork require space on Mageia servers for storing artwork and > marketing texts. And Documentation team needs space too, as requested on 15/03/12 : http://www.mageia.org/pipermail/mageia-sysadm/2012-March/004270.html We need a ftp server to upload to and a subdomain like doc.mageia.org to be able to see our Calenco documentation as it is in this moment (it gets updated automatically when a change is made), but also to store finished versions that are meant for the public and that will be kept as history when a new finished version becomes available. The situation for documentation team is less urgent than for Marcom and Artwork, because we have server space outside Mageia, but I suppose it won't take much extra work to help us too, when helping them.
CC: (none) => doc-bugs
Depends on: (none) => 5915
Marja, the doc.mageia.org (see bug 5915) has been opened. Do you still need an FTP account or can you use the svn for that? (with a trunk for your current work in progress and branches for finished ones)
(In reply to comment #1) > Marja, the doc.mageia.org (see bug 5915) has been opened. Do you still need an > FTP account or can you use the svn for that? (with a trunk for your current > work in progress and branches for finished ones) @ Romain We can use SVN for finished work, but we need FTP for things we are working on. From within Calenco, something like http://doc.mageia.org/content/index.html can be automatically updated with every change, if it is on a ftp server. Seeing the changes you made almost immediately, helps a lot when writing or editing the documentation
(In reply to comment #2) > We can use SVN for finished work, but we need FTP for things we are working on. That sounds strange. > From within Calenco, something like http://doc.mageia.org/content/index.html > can be automatically updated with every change, if it is on a ftp server. Aren't you asking for a Web/HTTP server space instead? > Seeing the changes you made almost immediately, helps a lot when writing or > editing the documentation Why can't you see your changes locally as you edit the doc, or through Calenco itself?
(In reply to comment #3) > (In reply to comment #2) > > We can use SVN for finished work, but we need FTP for things we are working on. > > That sounds strange. > > > From within Calenco, something like http://doc.mageia.org/content/index.html > > can be automatically updated with every change, if it is on a ftp server. > > Aren't you asking for a Web/HTTP server space instead? Of course the idea is to see the documents with a common browser. From within Calenco we can only upload those documents (that get synchronised when changed) to an ftp server. I don't have a terrible problem with keeping the documents we work on on mageia.nl, though, if remmy doesn't object. > > > Seeing the changes you made almost immediately, helps a lot when writing or > > editing the documentation > > Why can't you see your changes locally as you edit the doc, or through Calenco > itself? We can, but it is much harder to see and some things you just don't see. We make and edit xml files, but we don't publish xml files. From the xml files html files are generated. Those are the ones where we can really see what we did :)
Ok, got it: Calenco => ftp location that gets published as http for review. So the request is: - a doc-test.mageia.org web site, - a ftp account to upload contents under the document root of it, - need of a cron or something, to generate the index.html page?
Summary: doc.mageia.org + ftp server for documentation team => doc.mageia.org + doc-test.mageia.org (with ftp upload)
Is there other protocols supported by Calenco, or is it only ftp ?
CC: (none) => boklm
(In reply to comment #5) > Ok, got it: Calenco => ftp location that gets published as http for review. > > So the request is: > - a doc-test.mageia.org web site, > - a ftp account to upload contents under the document root of it, > - need of a cron or something, to generate the index.html page? For the first two: yes For the third: probably yes (I miss some understanding, so I'm not sure, I'm only sure it would be nice if, from doc-test.mageia.org, we could click on links to the documents and/or the folders they are in, instead of having to type the full path) (In reply to comment #6) > Is there other protocols supported by Calenco, or is it only ftp ? Calenco was upgraded on may 26th, so I just looked to see whether anything changed in that regard, but ftp is still the only possibility.
Keywords: (none) => Atelier
you would probably should use the git for docs just create accounts in github.com create org and join it or setup git server - it is very useful and userfriendly thing sp after setting it up you will see all your changes in text - it's made for programmes and text there are kinda very-very-very needed.
CC: (none) => oeai
@ Ra Thx for your suggestions. For docteam, the first half of this bug has already been solved, though, it is only the 2nd half that still needs solving. So now adjusting the summary. We do have a good /temporary/ alternative for doc-test.mageia.org, thx to remmy, on docteam.mageia.nl. We'll keep using that as long as this bug isn't solved and that solution is available.
CC: (none) => remcoSummary: doc.mageia.org + doc-test.mageia.org (with ftp upload) => doc-test.mageia.org (with ftp upload)
CC: (none) => atelier-bugs
CC: mageia-artwork => (none)
CC: (none) => filip.komar
CC: boklm => (none)
We already have http://www-test.mageia.org/ but it's currently empty and no upload mechanism known to me ;). Maybe we can use that subdomain for such purpose?
Calenco supports sftp, too, now.
Summary: doc-test.mageia.org (with ftp upload) => doc-test.mageia.org with (s)ftp upload
CC: remco => (none)
Note that docteam no longer has an ftp server to upload the working versions of our documents to. Remmy has, since the very beginning, told us that his server was only temporarily available. We have used it half a decade, which is much longer than intended. mageia.nl (we used ftp to upload to docteam.mageia.org) is currently in quarantaine. https://www.sidn.nl/whois?q=mageia But a solution on mageia.org would be better :-)
If this is quicker for sysadmins to arrange, you can also add a DNS entry for docteam.mageia.org (or whatever), and point it to the following IP's: 178.62.201.32 2a03:b0c0:2:d0::58:1001 Just let me know when it's done and I'll amend things on my side.
For now, it is available at: http://178.62.201.32/~docteam/ I hope this will work for the moment.
(In reply to Remco Rijnders from comment #14) > For now, it is available at: http://178.62.201.32/~docteam/ > > I hope this will work for the moment. It doesn't, but ennael said in council meeting that Mageia can pay for mageia.nl and probably also pay for server space. Can you claim docteam.nl for the mageia.org organization (please contact ennael about that, I'll CC her in this report)
CC: (none) => ennael1
What about comment #13? It should take the sysadmin team just minutes (if that) to do this at no cost to anyone. Then, somewhere in the coming months or so, it can be set up on one of mageia's servers.
CC: (none) => remco
(In reply to Remco Rijnders from comment #16) > What about comment #13? It should take the sysadmin team just minutes (if > that) to do this at no cost to anyone. Yes, but that doesn't mean it can be done, soon. Their TODO lists are so long that they can't find the end, there are too many more things that urgently need to be done, too many of which will also only take minutes and apart from their jobs and families that need time, there's also the voluntary work several (if not all) of them do outside of Mageia..... they're _overloaded_. > Then, somewhere in the coming months > or so, it can be set up on one of mageia's servers. CC'ing Simonnzg, because we need a plan B if our sysadmins can't do all that. @ Simon, Could you help docteam with (sftp) server space and with maintaining it for the draft Calenco manuals that get created or updated? http://meetbot.mageia.org/mageia-meeting/2017/mageia-meeting.2017-10-03-19.05.html
CC: (none) => gm4nzg
Yes. I can host Plan B. Simon(nzg)
(In reply to Marja van Waes from comment #15) > (In reply to Remco Rijnders from comment #14) > > For now, it is available at: http://178.62.201.32/~docteam/ > > > > I hope this will work for the moment. > > It doesn't, Logging in with ftp works, and with ssh works, too... I downloaded everything in docteam/public_html and am currently uploading it to Simon's server > but ennael said in council meeting that Mageia can pay for > mageia.nl and probably also pay for server space. > > Can you claim docteam.nl Oops, that should be mageia.nl, of course! > for the mageia.org organization (please contact > ennael about that, I'll CC her in this report)
Our draft documents can be found here, now http://mageia.org.uk/ Unfortunately there is no fast way for us in Calenco to get our 408 documents to get written to a new server when they're updated. After selecting the new target server for one document, Calenco will immediately regenerate the document and write it to the new server. That slows down the pace at which we can do the same for the other documents: Calenco needs to regenerate and upload 1.2 GB of documentation, during most of that time it will be impossible to select the new target server for another document. As papoteur just said on IRC: "It's possible, but it would take hours or days" So it would be great if docteam.mageia.nl could point to docteam.mageia.org.uk when the latter starts working. _Not_ to mageia.org.uk, because that'll redirect to mageia.org in the future. Btw, mageia.nl is in quarantaine till 2017-11-08 01:54:57 (UTC), unless the former owner releases it before.
I'll happily renew/transfer control of mageia.nl at cost. If desired, just let me know who to transfer the domain to. From my registrar, on .nl domains in quarantine: Quarantine period: After deleting/expiring of a domain of this type, the domain will enter into a quarantine period of 40 days. After this the domain will become available for registration. During the quarantine period, the domain can be restored by us. The costs for this procedure are EUR 20,-. The costs of a quarantined domain transfer are EUR 80,-. All prices displayed, do not include VAT.
€ 80 is more than the € 10 we discussed before the quarantine period, but I guess the € 10 never included a transfer. @ Remmy It doesn't feel good to ask of you to stay involved, after you've helped us so much longer than any of us intended. Or wouldn't it be a problem at all for you if we'd go for the € 20 option? If it would _not_ be a problem, then please let WebConquest renew the domain and tell me the IBAN to transfer the € 20 to. In that case, please make docteam.mageia.nl point to docteam.mageia.org.uk @ all In case the € 20 option can't be used, I don't think we should go for the € 80 option.... but I'm Dutch and very stingy, so feel free to protest :-) _If_ allowed to take a month to do it gradually, then I'm willing to do the needed work to let Calenco write all (re)generated documents to docteam.mageia.org.uk instead of to docteam.mageia.nl (I intend to only adjust the target server for the manuals of one language a day). Doing the hundreds of manuals one after another is no option, because of the huge amount of time lost when waiting for Calenco to regenerate each document and write it to the remote server. http://docteam.mageia.org.uk/ is up and running, btw :-)
(In reply to Marja van Waes from comment #22) > > and tell me the IBAN to transfer > the € 20 to and tell me how much VAT to add to that sum ;-) >
(In reply to Marja van Waes from comment #22) > € 80 is more than the € 10 we discussed before the quarantine period, but I > guess the € 10 never included a transfer. That is because the domain registration expired. Involved parties charge extra during that period to restore things. I can request for the domain to be reinstated, and transfer it at a later date. > _If_ allowed to take a month to do it gradually, then I'm willing to do the > needed work to let Calenco write all (re)generated documents to > docteam.mageia.org.uk instead of to docteam.mageia.nl > http://docteam.mageia.org.uk/ is up and running, btw :-) Would it not be quicker to use sed or similar to do a global replace in all the files?
(In reply to Remco Rijnders from comment #24) > > Would it not be quicker to use sed or similar to do a global replace in all > the files? We don't have access to the files where that information is stored, such files are hidden to us and we can only change them in the web interface of Calenco, one at a time. If there had been a way to work around the web interface to do this faster, then papoteur would have found it.
mageia.nl has been restored and reregistered for 3 more months. Should I point docteam.mageia.nl to the new address, or leave things as they are now? (That is, nothing has been changed on my end but the registration renewed).
(In reply to Remco Rijnders from comment #26) > mageia.nl has been restored and reregistered for 3 more months. Should I > point docteam.mageia.nl to the new address, or leave things as they are now? > (That is, nothing has been changed on my end but the registration renewed). Thanks, Remco :-D please point docteam.mageia.nl to docteam.mageia.org.uk :-)
Thanks Remmy and Marja. There is also a RESTFUL API interface to deal with Calenco content. It's documentation is here: https://doc.neodoc.biz/Calenco-Doc/API/calenco-v23-rest-api-specs.html To update a publication: https://doc.neodoc.biz/Calenco-Doc/API/workspaces-wksp-publications-pub-put.html I presume that you can send the invoice to ennael with IBAN. Will be the subsequent transfer object of an invoice?
CC: (none) => yves.brungard_mageia
Created attachment 9720 [details] Non working script Here is the script in Python I try to use. I can get the list, but changing a parameter in the publication fails each time with "400" error.
DNS has (just) been updated accordingly. Please let me know in case of any issues.
Hello Remmy, For the moment, I get a waiting page from Zen Internet.
(In reply to Remco Rijnders from comment #30) > DNS has (just) been updated accordingly. Please let me know in case of any > issues. (In reply to papoteur from comment #31) > Hello Remmy, > For the moment, I get a waiting page from Zen Internet. I get that page too, when going to 82.71.204.7 Going to http://docteam.mageia.org.uk/ gives the correct page, so does going to http://mageia.potsherds.org/public_html/ (both [sub]domains share the same ip address) Is it possible to point docteam.mageia.nl to docteam.mageia.org.uk instead of to 82.71.204.7 ?
The server is a hosted cPanel instance, so multiple domains on same IP. Must use FQDN or it won't work. Simon
I think this has to be changed on the webserver side of things. I can change DNS to point to CNAME docteam.mageia.org.uk but I think that will only result in the DNS now pointing to docteam.mageia.org.uk DNS instead of directly resolving to the IP. The browser will still ask for docteam.mageia.nl of the server listening on 82.71.204.7 so the end result will be the same.
(In reply to Remco Rijnders from comment #34) > I think this has to be changed on the webserver side of things. I can change > DNS to point to CNAME docteam.mageia.org.uk but I think that will only > result in the DNS now pointing to docteam.mageia.org.uk DNS instead of > directly resolving to the IP. The browser will still ask for > docteam.mageia.nl of the server listening on 82.71.204.7 so the end result > will be the same. Thanks a lot for all your help, Remco. Papoteur managed, with the help of Fabián Mandelbaum, to improve his script and change the target server for all our >400 publications. They do now get written to docteam.mageia.org.uk, so it is OK to let the docteam.nl registration expire. (I'll obsolete this comment and any other comment that our sysadmins won't need when they find time to create a solution within mageia.org)
Well, we still need a permanent solution. For a lot of years now, since Remmy stopped providing server space, we've used server space that simonnzg kindly provided: https://docteam.mageia.org.uk/ However, Simon will retire soon (how soon exactly, Simon?) and his servers will then be taken down, taking https://docteam.mageia.org.uk/ with them. Without a solution, docteam can't test our official documentation (about MCC and installer etc) for Mageia 10. This also makes it impossible for translators to see their recent translations and translation updates from our documentation "in action". Also, it will be much harder to publish the (still untested) documentation on our website and to package it.
CC: (none) => i18n-bugs
Hello, Thanks Marja for this info. The long term solution is to have it hosted on Mageia servers. I presume that we will wait to have new servers in service first. Questions: 1- what is the volume to store 2- in which delay? For a short term, MLO can be a relay. Papoteur
CC: (none) => j.biernacki+mga, jeanmichel.varvou
There's a security issue involved here as well, as JavaScript on doc-test.mageia.org would have access to cookies set on mageia.org, including any cookies used for authentication. If the content isn't coming from svn then there's no tracking of what content has been uploaded and a nefarious user could upload some malicious JavaScript, even for just a short time, and do bad things to visitors to that page with their stolen credentials. This is why web firms put user-generated content on completely separate domains from their main services (e.g. googleusercontent.com instead of usercontent.google.com). If the list of people who can upload to doc-test is small, trusted and authenticated, especially if it's the same set of people as those who can upload to doc.mageia.org, then maybe it's not that big a problem.
CC: (none) => dan
I think we can open a github or gitlab space for some mageia things Artwork could be one of those
maybe you should put it first to transifex also to work wwth translation of files as they do with the program part. just to see if it is done well for github and gitlab they got their docs and wiki parts but you can check if they support adding own subdomains they got better auth system against any of your inmplementation and for art space - maybe you can find something like deviantart or maybe better art space with groups and all such like github with support of adding subdoamins, basically you just need to put some exact art in some group and make some votes or see people feedback and works - this can also advertise this art and group work too. So you need just to find out what are the iinstruments there if it is just file upload or something more about work, i guess there is more than just one site for art wt long story, so this can evolve, not just go offline pretty soon as google groups or many more.
(In reply to ra oeai from comment #40) > maybe you should put it first to transifex also to work wwth translation of > files as they do with the program part. It's already there. > just to see if it is done well Every text needs a special technical approach to be in final shape for that. That's the reason for such domain.
> text needs a special technical approach to be in final shape transifex has native code SDK basically this means - they wiil host your files if you connect their SDK to your site with .js
(In reply to ra oeai from comment #42) > > text needs a special technical approach to be in final shape > > transifex has native code SDK > basically this means - they wiil host your files if you connect their SDK > to your site with .js Are you a volunteer?
> Are you a volunteer? aren't you ? i'm too busy, but i gave the solution - you are not in my pool of projects for a long time, about the time we discussed this same way of moving to github years ago.
(In reply to ra oeai from comment #42) > > text needs a special technical approach to be in final shape > > transifex has native code SDK > basically this means - they wiil host your files if you connect their SDK > to your site with .js Hello, What is code SDK in transifex? I don't understand which feature is provided. Our need, after the translation, is to restore XML docbook files as translated, apply XSL stylesheet to generate PDF, Epub and HTML files then publish the HTML part.
(In reply to Dan Fandrich from comment #38) > There's a security issue involved here as well, as JavaScript on > doc-test.mageia.org would have access to cookies set on mageia.org, > including any cookies used for authentication. If the content isn't coming > from svn then there's no tracking of what content has been uploaded and a > nefarious user could upload some malicious JavaScript, even for just a short > time, and do bad things to visitors to that page with their stolen > credentials. This is why web firms put user-generated content on completely > separate domains from their main services (e.g. googleusercontent.com > instead of usercontent.google.com). > > If the list of people who can upload to doc-test is small, trusted and > authenticated, especially if it's the same set of people as those who can > upload to doc.mageia.org, then maybe it's not that big a problem. Thanks for being vigilant. The users who can access to Calenco is in a short list (Marja, Yuri and me for the essential) and under control. Publications are generated using stylesheets, but these ones are provided by Calenco, I think (Marja, is it true?).
(In reply to papoteur from comment #46) > (In reply to Dan Fandrich from comment #38) > > There's a security issue involved here as well, as JavaScript on > > doc-test.mageia.org would have access to cookies set on mageia.org, > > including any cookies used for authentication. If the content isn't coming > > from svn then there's no tracking of what content has been uploaded and a > > nefarious user could upload some malicious JavaScript, even for just a short > > time, and do bad things to visitors to that page with their stolen > > credentials. This is why web firms put user-generated content on completely > > separate domains from their main services (e.g. googleusercontent.com > > instead of usercontent.google.com). > > > > If the list of people who can upload to doc-test is small, trusted and > > authenticated, especially if it's the same set of people as those who can > > upload to doc.mageia.org, then maybe it's not that big a problem. > > Thanks for being vigilant. > The users who can access to Calenco is in a short list (Marja, Yuri and me > for the essential) and under control. Publications are generated using > stylesheets, but these ones are provided by Calenco, I think (Marja, is it > true?). Yes, for the largest part. IIRC, we had some adjustments (that were made in Calenco) and also some own stylesheets, which were only an overlay to the Calenco stylesheets. I think our own stylesheets are here: https://gitweb.mageia.org/software/i18n/tools/tree/docs/stylesheets @ Camille What are the protocols currently supported by Calenco to write publications to external websites?
CC: (none) => camille
Hello, Would like to get Dan's feedback on this: I think it would be very relevant that we host this production chain (XML -> HTML, PDF, ...) I've done my docs for MondoRescue since years using that, and it's better if we can manage the chain on Mageia servers. From reading bug https://bugs.mageia.org/show_bug.cgi?id=5915 : http://doc.mageia.org/ has been created. You can commit to svn.mageia.org/svn/web/doc/. I tried to do svn co svn+ssh://svn.mageia.org/svn/web/doc mageia-doc and it works (as I'm a dev so allowed to do that). Are the 3 people mentionned as working on docs able as well ? Then: ls mageia-doc/*/* mageia-doc/installer/index.html mageia-doc/mcc/index.html mageia-doc/g/images: bg_ln_1.jpg bg_ln_2.png bg_ln_3.png bg_ln_4.png cauldron_alpha_ln_1.png mageia-doc/g/style: all.css mageia-doc/installer/2: de/ el/ en/ eo/ fr/ index.html nl/ pt_br/ uk/ mageia-doc/installer/3: de/ el/ en/ es/ et/ fr/ index.html nl/ pt_br/ ru/ uk/ mageia-doc/installer/4: ca/ common/ cs/ de/ el/ en/ eo/ es/ et/ fr/ id/ index.html nl/ pl/ pt_br/ ro/ ru/ sv/ tr/ uk/ mageia-doc/mcc/3: en/ et/ fr/ index.html mageia-doc/mcc/4: common/ en/ et/ fr/ index.html ru/ uk/ However, it seems to contain the generated HTML pages, not the sources XML + DSL ones. So wouldn't it be possible to host the XML content under our svn instead, then have a way for you to launch the generation with dockbook2* tools in order to generate the final docs and publish them on http://www-test.mageia.org/ (which exists but has no content) so you can check the result. Can mgarepo be extended to cover that or do we need to write (or reuse) a script ? That would probably allow all devs to also make modifications to the doc to keep it in parity with the development they make, if they wish so. And stay secure by controllling who is able to commit and generate. I'm sure I'm missing a lot of details of how this works, and my proposal may be completely out of scop, but trying ;-) (In particular, I'm not sure why we need an external provider such as calenco in the loop, but would like to get it). Is there any waiki page describing the doc production ? Reading that page https://www.mageia.org/en/doc/ mentions the Calenco tool from NeoDoc, which in FF doesn't display anything. https://wiki.mageia.org/en/Documentation_team mentions DocBook,but doesn't describe the production chain used :-( (However, I'm amazed we have so many doc pages, I wasn't aware of that !!) And I don't know how translations are involved at that point and how to propose to manage them with Transiflex :-(
CC: (none) => bruno
About Calenco: When Mageia 1 was released, we had no official documentation (neither the inline help for installer and MCC, nor the manuals on our website). Camille Bégnis offered us to use Calenco https://www.calenco.com/en/Company/History-CalencosSaasSolution.html for free. He has given us a tremendous lot of help creating several manuals, in Calenco with DocBook, in multiple languages and in html, html WebHelp, epub and pdf. Really, without him, I'm afraid we wouldn't have gotten anywhere. On every change in Calenco at least the matching WebHelp publication was regenerated, overwriting the old one on Simon's website, so that the translator or the person who updated a screenshot or help text, could check their work. However, I failed to regenerate them for almost all of 2025, sorry. We have (or had) separate workspaces in Calenco: Factory (Which matches Cauldron) and one or two for Stable releases, in case after release a publication would need to be fixed for a stable release. But so far, that wasn't needed. About the translations: The translations are nowadays done on the Transifex website and synced back and forth, via git https://gitweb.mageia.org/software/i18n/tools/tree/docs by Yuri. https://gitweb.mageia.org/software/i18n/tools/tree/docs/docs/stable is actually Cauldron, not stable, but creating separate sub trees for cauldron and one or more stable versions shouldn't be too hard if the need ever arises.
(In reply to Bruno Cornec from comment #48) > > From reading bug https://bugs.mageia.org/show_bug.cgi?id=5915 : > http://doc.mageia.org/ has been created. You can commit to > svn.mageia.org/svn/web/doc/. > > I tried to do svn co svn+ssh://svn.mageia.org/svn/web/doc mageia-doc > and it works (as I'm a dev so allowed to do that). Are the 3 people > mentionned as working on docs able as well ? > Actually, git is used nowadays https://gitweb.mageia.org/web/doc/ Publishing manuals on the website is officially a task of Atelier Team. Filip has done it, but in recent years it was Yves who did the publishing there. Now that the alpha ISOs are released, it would be a good moment to regenerate all publications, not only the WebHelp ones, so that the other publications can be checked, too.
Thx for the git link, more up to date ;-) However, I'm still not understanding what the doc-team does: How are you modifying the XML file to change the doc ? Which tool do you use ? How are you then creating the derived doc (HTML, ...) ? Which tool do you use ? I've seen some python scripts inthe repo you mention, what are their role ? I'm allfor helping you produce docs in the easiestway possible, but for the moment, I'm still not getting the full picture sorry :-(
When I last did this (years ago), the xml files could be modified in Calenco with a wysiwyg editor. It is also possible to download them, edit them locally and then upload them again. In fact, since we started translating outside Calenco, that’s how it’s done for the non-English xml files. The derived documents are all created in Calenco, with Calenco tools. Tbh, I don’t see a reason to stop using Calenco. (I do worry about us still using Transifex, though) On my phone now, so can’t take a look, but I think the python scripts you saw are all related to translations. There is at least a script, if you don’t want to use Transifex, that makes it easier to do the translations locally. That’s a script Filip created. He also created scripts to show on our website or wiki, whether what’s in git matches what’s in Calenco and, iinm, how much of what is translated into which language.
Note that Calenco offers an XLIFF export for translations now that could help you greatly with translating the documentation and track translations too. https://publish.calenco.com/Calenco/en/780251e6-0bc8-4597-8cac-202917f5c77d-1621626492/translation_pack.html
Hello Bruno, To complete the picture, know that the documentation is provided in multiple locations: 1- the website, in HTML, PDF and epub form [1] 2- inside the installer, as contextual help (only text, only installer doc) [2] 2- as packages in HTML, draklive documentation being included in Live media to be available even if network is out [3] Each form needs specific work to land in the good place, this is what for the Python script are written for, they pick the published form in Simon' site to put them at the good location. Here a description of the editing phase : https://wiki.mageia.org/en/How_to_write_and_translate_Mageia_doc [1] https://wiki.mageia.org/en/Managing_the_website#doc.mageia.org [2] https://wiki.mageia.org/en/How_to_package_drakx-installer-help [3] https://wiki.mageia.org/en/How_to_package_mageia-doc
(In reply to Camille Begnis from comment #53) > Note that Calenco offers an XLIFF export for translations now that could > help you greatly with translating the documentation and track translations > too. > https://publish.calenco.com/Calenco/en/780251e6-0bc8-4597-8cac-202917f5c77d- > 1621626492/translation_pack.html Thanks, Camille, CC'ing Yuri for that (The other i18n team leader, Filip, is already in the CC)
CC: (none) => yurchor
(In reply to papoteur from comment #54) > Hello Bruno, > To complete the picture, know that the documentation is provided in multiple > locations: > 1- the website, in HTML, PDF and epub form [1] > 2- inside the installer, as contextual help (only text, only installer doc) > [2] > 2- as packages in HTML, draklive documentation being included in Live media > to be available even if network is out [3] > > Each form needs specific work to land in the good place, this is what for > the Python script are written for, they pick the published form in Simon' > site to put them at the good location. > > Here a description of the editing phase : > https://wiki.mageia.org/en/How_to_write_and_translate_Mageia_doc > > [1] https://wiki.mageia.org/en/Managing_the_website#doc.mageia.org > [2] https://wiki.mageia.org/en/How_to_package_drakx-installer-help > [3] https://wiki.mageia.org/en/How_to_package_mageia-doc Thanks for further completing the picture, Yves. I'm shocked at how outdated https://wiki.mageia.org/en/How_to_write_and_translate_Mageia_doc is :-( Yves, can you already create an ssh key pair in Calenco and send it to Bruno? Bruno, sorry for pushing this, but Simon can't control all the whims of his ISP, where his websites are hosted. We really shouldn't stay there. All that's needed right now, is an address for sftp access for Calenco to upload the manuals that should become visible on /www-test.mageia.org For now: A "Factory" directory in there (To be copied to a directory for Mageia 10 when 10 final is released) Also, at least Yves needs ssh access to create the needed tree. @ Yves I'm still confused about what the best possible tree should look like. What about leaving everything as it is now, but, when there is time, additionally creating a directory for translators, containing directories for all languages, each containing links to every uncompressed publication for that language?
(In reply to Marja Van Waes from comment #56) > > Yves, can you already create an ssh key pair in Calenco and send it to Bruno? > Oops Not the entire pair, of course :-((( the public key will do :-þ
(For the fourth time trying to remove four people who left, from the CC)
CC: ennael1, rdalverny, remco, trish => (none)
(In reply to Marja Van Waes from comment #56) > (In reply to papoteur from comment #54) > > Hello Bruno, > > > > Here a description of the editing phase : > > https://wiki.mageia.org/en/How_to_write_and_translate_Mageia_doc > > Thanks for further completing the picture, Yves. > > I'm shocked at how outdated > https://wiki.mageia.org/en/How_to_write_and_translate_Mageia_doc is :-( > I've spend around 3 hours trying to see how to improve that page, but my brain refuses to tell me how to do that (except for a few very minor changes). If you want to know everything about Calenco, Bruno, then read https://publish.calenco.com/Calenco/en/780251e6-0bc8-4597-8cac-202917f5c77d-1621626492/index.html
(In reply to papoteur from comment #54) > To complete the picture, know that the documentation is provided in multiple > locations: > 1- the website, in HTML, PDF and epub form [1] > 2- inside the installer, as contextual help (only text, only installer doc) > [2] > 2- as packages in HTML, draklive documentation being included in Live media > to be available even if network is out [3] > > Each form needs specific work to land in the good place, this is what for > the Python script are written for, they pick the published form in Simon' > site to put them at the good location. Putting on my devops hat, the ideal solution would be that someone checks in a change to the documentation in git, and that change gets automatically converted into HTML, PDF and epub forms and ends up in the right place on the right website automatically. That would require that 1) Calenco can work that way (either update git, or update a local tree that someone can manually commit to git) instead of uploading via ftp, and 2) that the tools needed to convert the output of Calenco into the correct alternate forms can run unattended on a server. This approach eliminates the need to stand up a new ftp/sftp server and the attending issues with security and authentication as well as providing source code control to track changes. Not knowing anything about the current workflow, would this approach even make any sense with the tools we are using?
> Not knowing anything about the current workflow, would this approach even make any sense with the tools we are using? Yeah, Dan. That sounds great. But we need a volunteer creator for such a great tool. > Reading that page https://www.mageia.org/en/doc/ mentions the Calenco tool from NeoDoc, which in FF doesn't display anything. Bruno, what exactly FF doesn't display?
Ah, it goes to the wrong URI. Points at neodoc.biz, which is 'for sale'. I'm not sure where it SHOULD point, but I suspect the main page at calenco.com is the best option here, rather than the neodoc.calenco.com/ login page if the reader is looking to find out more about Calenco. Simon
(In reply to Filip Komar from comment #61) > > Reading that page https://www.mageia.org/en/doc/ mentions the Calenco tool from NeoDoc, which in FF doesn't display anything. > Bruno, what exactly FF doesn't display? I made an attachment. It's just a dark grey window with nothing.
Created attachment 15372 [details] neodoc.biz is empty with FF on mga9
(In reply to Bruno Cornec from comment #64) > Created attachment 15372 [details] > neodoc.biz is empty with FF on mga9 Understood it's the wrong domain that we reference,sorry :-(
Hmm, same in FF 147.0 in RaspiOS. In Brave it redirects to a free domain page. I guess that the proper link is now https://neodoc.calenco.com/. Marja or anyone experienced can confirm? Then I can fix it on our web page.
(In reply to Filip Komar from comment #66) > Hmm, same in FF 147.0 in RaspiOS. In Brave it redirects to a free domain > page. > > I guess that the proper link is now https://neodoc.calenco.com/. > > Marja or anyone experienced can confirm? > > Then I can fix it on our web page. I think, for the line "Documentation built using the Calenco tool from NeoDoc." this would be a better link: https://www.calenco.com/en/index.html And I think "Documentation built using the Calenco tool from NeoDoc." should be changed into "We built this documentation using the Calenco tool from NeoDoc". However, Camille should decide. He's in the CC of this report.
(In reply to Dan Fandrich from comment #60) > Putting on my devops hat, the ideal solution would be that someone checks in > a change to the documentation in git, and that change gets automatically > converted into HTML, PDF and epub forms and ends up in the right place on > the right website automatically. That would require that 1) Calenco can work > that way (either update git, or update a local tree that someone can > manually commit to git) instead of uploading via ftp, and 2) that the tools > needed to convert the output of Calenco into the correct alternate forms can > run unattended on a server. This approach eliminates the need to stand up a > new ftp/sftp server and the attending issues with security and > authentication as well as providing source code control to track changes. > > Not knowing anything about the current workflow, would this approach even > make any sense with the tools we are using? So back to the meat: Yes, that was also my take asking why we were depending on an external env to produce the doc. I mean, I understand that people want to use a WYSIWYG tool to work. Now, once they are happy, there should be a build process (similar to what we do for packages) that takes the xml file, the xsl style sheet and pass it to docbook2ps, docbook2html, ... to generate the documentaion files that are then moved to the right place to be used by the tools needing them. For MondoRescue I just have a makefile doing the job I need, which more or less does that and has the form (shorten) : TARGET=mondorescue-howto SRC=$(shell ls *.sgml) DSL=$(TARGET).dsl $(TARGET).pdf: $(SRC) $(DSL) $(IMAGES) @echo "" @echo "Generating doc in PDF format" @echo "----------------------------" @docbook2pdf -d $(TARGET).dsl'#pdf' $(TARGET).sgml $(TARGET)/index.html: $(SRC) $(DSL) $(IMAGES) @echo "" @echo "Generating all HTML pages" @echo "-------------------------" @rm -fr $(TARGET) @docbook2html -d $(TARGET).dsl'#html' -o $(TARGET) $(TARGET).sgml Wouldn't it be possible to have a similar process for our doc ? (extended by the management of the target dir hosting the results, and their integration into the tools). I'm willing to work on this if that's the right direction to take...
Hello, I'm afraid I can't keep up with the various topics in this ticket. First you talk about a link to Calenco, but I don't understand what for? Second, in the latest comment about PDF and HTML publications you talk about a MakeFile (nice memories since this is how I was managing this 27 years ago ;-), but Calenco handles all this automatically for you. Camille.
(In reply to Camille Begnis from comment #69) > Hello, > I'm afraid I can't keep up with the various topics in this ticket. > > First you talk about a link to Calenco, but I don't understand what for? > This is about the link to Calenco on this page https://www.mageia.org/en/doc/ where we credit NeoDoc. The link leads to a page that obviously no longer belongs to you. What should it be replaced with?
(In reply to Marja Van Waes from comment #70) > (In reply to Camille Begnis from comment #69) > > Hello, > > I'm afraid I can't keep up with the various topics in this ticket. > > > > First you talk about a link to Calenco, but I don't understand what for? > > > > > This is about the link to Calenco on this page > https://www.mageia.org/en/doc/ where we credit NeoDoc. The link leads to a > page that obviously no longer belongs to you. > > What should it be replaced with? Oh OK please make it point to https://www.calenco.com/ Thanks!