dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

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,  <johansa@xxxxxxxxxx> 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 <knutst@xxxxxxxxx> wrote:
>>> On Tue, Oct 27, 2009 at 9:32 AM, Jason Pickering
>>> <jason.p.pickering@xxxxxxxxx> 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 <knutst@xxxxxxxxx> 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     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>> > 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     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>