I have considered this, and suggested to Thuy that multilingual documents be placed into separate folders. However, the docbkx maven plugin that is used to render DocBook XML into PDF/HTML and other format expects, by default, all documents to be in the src/docbkx folder. It should be possible, by modifying the pom.xml file, to include the documents in other folders. I have not figured out how to do this yet however, and am not sure if it is 100% possible. I think there are three options.
1) Place each file in a separate directory, using the ISO language code for each language. This keeps things neat, but as mentioned above, may not be possible until we figure out how to do it. 2) Use the naming convention, by appending the ISO language code to the end of the file name. Maybe not a bad option. 3) Use the language attribute of DocBook and have everything (all languages in a single document). This could get messy, and is probably not a good idea, although we probably should use this tag anyway inside the document. I will try and dig a bit more and see if we can move everything into separate folders based on language. On Tue, Oct 27, 2009 at 10:17 AM, <[email protected]> wrote: > A couple of thoughts regarding the documentation... > How do we keep track of several languages? > I see the gis doc has postfix _en. Should we have folders for each > language? At least there should be language specific folders for the > images. Not that it is really really urgent, but nice to have in place > from the start. > > Johan > >> Well, I would not regard Launchpad as really any more difficult than a >> proprietary source control system like SourceSafe or MKS (horribly >> complex, ask the WHO devs). It is difficult at first, but the >> advantages clearly outweigh the initial pain in getting everything >> setup and getting people used to the work flow. We really have no >> choice. We are spread out across the globe, and some version control >> system is the only way to work together. I think we should offer some >> sort of tutoring on issues like this, to get potential contributors up >> and running with the system. I was totally confused by bzr the first >> time I used it, having been using a rather simple system like >> subversion, but I think we should just offer to support those that >> cannot get it running. >> >> >> For the documentation, even though I was the one that started all of >> it, I think we are going to run into issues with some people being >> totally overwhelmed by the technology required to do any >> documentation. I wrote an email to the documentation list regarding >> the concurrent use of Serna and XXE, and it is far from simple to try >> and merge documents back if two people are editing them. I guess the >> same could be said for source code as well. But since we are expecting >> that non-devs are eventually going to contribute to the documentation >> branch, we need a bit better strategy on how to handle these >> situations. I tried to do a three way merge with the Excel report >> document, after having made some changes, but gave up, as it was far >> too time consuming. Subversion might lower the barrier a bit, but I >> do not think it would be a good idea in the long run. I still have >> dreams of having the documentation integrated into the application >> itself, and having the source in two separate version control systems >> could create more problems that would be more difficult to deal with >> than simply tutoring those that cannot get bzr working with a few >> clicks. >> >> Anyway, my two cents. >> >> On Tue, Oct 27, 2009 at 9:40 AM, Knut Staring <[email protected]> wrote: >>> On Tue, Oct 27, 2009 at 9:32 AM, Jason Pickering >>> <[email protected]> wrote: >>>> >>>> I think anyone can download the code, but committing code back is not >>>> possible without an SSH key pair AFAIK. >>>> >>>> It is pretty complicated, but if one is coding stuff, it should be >>>> pretty easy. :) >>> >>> Agree in principle, it just sucks that this is the initial experience. >>> In >>> last week's workshop in Rwanda, I had a very smart guy comment that >>> "this >>> open source stuff is always so complex" comparing it to click-click >>> installers... >>> >>>> >>>> I do think it should be much more simple for the DcoBook branch. It >>>> seems like total overkill, but since there was a decision to move to >>>> Launchpad, I think we have to live with this and provide assistance to >>>> anyone who wants/can commit code but cannot get everything setup. >>>> >>> >>> Good point about the documentation. Not sure what the solution is >>> though, as >>> we do need authentication. We could of course host it on a Subversion >>> server >>> (e.g. Sourceforge, Google Code) which could lower the barrier a bit? Or >>> would it be too confusing? >>> Knut >>> >>>> >>>> On Tue, Oct 27, 2009 at 8:20 AM, Knut Staring <[email protected]> wrote: >>>> > Hello, >>>> > It is very unfortunate that it is so complicated to get hold of the >>>> > latest >>>> > source code. >>>> > There are simply too many hoops for Windows users on this page - it >>>> > drives >>>> > people away at an early stage: >>>> > https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair >>>> > Is there no way to avoid having SSH keys for simple download of the >>>> > code? >>>> > Knut >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Mailing list: https://launchpad.net/~dhis2-devs >>>> > Post to : [email protected] >>>> > Unsubscribe : https://launchpad.net/~dhis2-devs >>>> > More help : https://help.launchpad.net/ListHelp >>>> > >>>> > >>> >>> >>> >>> -- >>> Cheers, >>> Knut Staring >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~dhis2-devs >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~dhis2-devs >> More help : https://help.launchpad.net/ListHelp >> > > > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
