2011/3/25 Greg Lamberson <lamberson@...>
> Thanks for the continued feedback. You say, "I see the notice at the start
> of a page of 3.3 points to 3.2. This may be changed globally, so the
> conventions can point to the latest conventions, so 3.3, you should just
> change the macro of the notice for that."
The macro was this one:
I changed the link now to point to 3.3 (admin rights where needed anyway for
that template to avoid tampering), perhaps we should set up a page outside
of the wiki with some guidance on editing the wiki instead...
I do not see anything on the 3.3 manual pointing to 3.2. I also note that
> the link you include points to the 3.2 manual. Perhaps you're looking at the
> 3.2 manual to begin with? OR were you not referring to the actual manual? In
> any case, I do not see the problem you mention.
> Regarding extraction of the manual for translation and/or having a manual
> document separate from the wiki, my first inclination is to look at some of
> the extraction extensions to MediaWiki such as:
> HierarchyBook (creates a PDF doc from a wiki index using python)
> PDFBook (creates a PDF document from categories)
> Wiki2XML (experimental XML converter [not sure how useful this really would
> Depending on whether this is a good avenue to pursue, I could certainly
> look into this and set up my own environment to do some testing. (This is
> what I normally do, as opposed to that mystic 'programming' stuff you guys
> do.) What do you think of this sort of thing? Should you think this is worth
> investigating, could you tell me what version of MediaWiki currently in use
> and how much of an issue dealing with its setup is (that is, is it on
> infrastructure fully controlled by someone here? Is it hosted [i.e., there's
> no root access to the hosting server]?)?
Yes. This would allow us to optionally ship a manual also to people who want
it when not online. As Jerome wrote, there have been attempts, and the
Slovak translator I think has a local setup, but I don't know how he does
> Greg Lamberson
> *From:* Benny Malengier <benny.malengier@...>
> *To:* Greg Lamberson <lamberson@...>
> *Cc:* gramps-devel@...
> *Sent:* Thu, March 24, 2011 2:08:35 PM
> *Subject:* Re: [Gramps-devel] Questions related to working on the 3.3
> I suggest you update the typographical conventions, and add a section on
> how to do images, see
> I see the notice at the start of a page of 3.3 points to 3.2. This may be
> changed globally, so the conventions can point to the latest conventions, so
> 3.3, you should just change the macro of the notice for that.
> It would be nice if whatever scheme you work out is easy to upgrade to a
> 3.4 manual somewhere in the future.
> Old images must indeed remain for the 3.1/3.2 versions of the manual, these
> are still in use and will remain so for some time!
> Otherwise, you can improve the manual as much as you like. To have a
> translatable manual outside the wiki has many advantages, but we experienced
> too little people where helping out with the manual. The manual on the wiki
> is much better in that regard, but unfortunately more difficult to
> For the future, I believe the best would be:
> 1/english manual in the wiki
> 2/extraction of this to a xml sort of document
> 3/translation of this document to different languages via one of the
> translation tools available for texts
> 4/production of pdf and nice layout html from the xml
> If you know of some way to move towards such a framework, that would be
> great :-D
> I'll look at the name format, I wrote the code, so should know if it is
> 2011/3/24 Greg Lamberson <lamberson@...>
>> Doug et al.,
>> Thanks for the positive feedback related to my working on the manual.
>> Regarding the below, let me clarify and redirect my inquiries and thoughts a
>> First, I was concerned about the fact that my replacing the images for
>> screenshots would have an effect on the images for previous versions of the
>> manual and for the manual's different versions. I had wanted to use some
>> scheme that would make use of my new images distinct from the previous
>> images in case these images are used in previous manuals and make the images
>> easily found for anyone working on other language versions. However, in
>> proceeding, I have realized that all the images really need to be replaced
>> at once for the sake of consistency. Additionally, I see that the manual
>> subdivisions, chapters and the figure numbers used for images within the
>> chapters do not correspond and are in some places muddled and inconsistent
>> and in others they simply conflict.
>> Your responses have helped me determine that what I probably should do is
>> just make all new images and then produce a template or document that shows
>> what the new image names are and how they can be incorporated into other
>> language versions if desired. I do not have a clear naming scheme other than
>> naming the screenshots as they are titled within Gramps and incorporating
>> the version number of the program they are taken from. However, I'll make
>> sure this is consistent going forward.
>> Regarding Backup/Archive/Export, it sounds like the backup function needs
>> some work regarding feedback and overwrite warning. I'll monitor bug #4779
>> and proceed after that is worked out. However, could someone give me a
>> rundown of what the 'make backup' function is doing exactly? It it making a
>> GrampsXML file or package? What's the difference? How does one restore a
>> backup? If there's a 'Make Backup' option, does there need to be a 'Restore
>> Backup' function? Does this option save one's Gramps preferences?
>> Regarding the Name Editor functions, they are currently covered in the
>> manual here:
>> I did some editing of this to correspond with the new interface and I've
>> changed the screenshot already, but as noted, this needs attention from
>> someone more familiar with it. If anyone wants to look at it and simply
>> respond with what need to be changed or explain it to me better, I'll be
>> happy to deal with the manual if you prefer not to.
>> Let me apologize now for what are sure to be further ramblings of this
>> sort related to mundane manual questions in the future.
>> Greg Lamberson
>> Lamberson One-name Study
>> Genealogy wiki for collaboration:
>> *From:* Doug Blank <doug.blank@...>
>> *To:* Greg Lamberson <lamberson@...>
>> *Cc:* gramps-devel@...
>> *Sent:* Thu, March 24, 2011 5:33:29 AM
>> *Subject:* Re: [Gramps-devel] Questions related to working on the 3.3
>> On Wed, Mar 23, 2011 at 10:45 PM, Greg Lamberson <lamberson@...>
>> > Hi,
>> > As part of my self-indoctrination process, I'm going through the 3.3
>> > manual carefully to improve its readability, make sure it's reflective
>> > what the user actually sees, and to generally make sure I'm thoroughly
>> > familiar with things.
>> Excellent way to contribute, and learn! Very useful at this point, too.
>> > The following questions have come up so far during
>> > this process:
>> > 1. Screen Shots: Should I redo all the screenshots to maintain
>> uniformity in
>> > the manual or continue my practice of merely replacing the ones which
>> > changed? It's starting to look rather inconsistent. Is there a naming
>> > convention for screenshots? I could not find one and have been making my
>> > own.
>> Others that contribute to the manual will have to weigh in on this.
>> The manual has been evolving from a hardcopy version, to what we have
>> today. So it is probably time for a step in that evolution. What is
>> your naming scheme?
>> > 2. Backup, Archive, Export: Was the manual written before "Make Backup"
>> > a menu item? This option is not mentioned in the manual (at least in the
>> > obvious places), and instead the export to xml/pkg option is mentioned
>> > the preferred method to secure data before upgrading. If "Make Backup is
>> > still not the preferred option, it should at least be mentioned. Right
>> > the absence of this option within the documentation is confusing,
>> > with the export and archive methods also being mentioned.
>> This one I can answer: yes, the Make Backup is new, and should now be
>> highlighted as the preferred method of backing up. People should also
>> test this functionality as well. (I noticed that it didn't seem to
>> give feedback on status, and didn't warn on overwrite... just reported
>> as #4779).
>> That is another function one could perform: make sure things work, and
>> feel free to suggest refinements on new (and old) features.
>> > 3. Name Editor: I did my best regarding the changes in the Name
>> Editor, but
>> > this section needs to be looked at by someone with more familiarity with
>> > these options just to make sure it's correct and complete.
>> > If I'm jumping the gun here on someone, I apologize. I'm just trying to
>> > in here and learn and get up to speed the best I can.
>> Yes, needs to be looked at from the technology viewpoint, and also the
>> human understanding perspective.
>> > Greg Lamberson
>> > lamberson@...
>> > Enable your software for Intel(R) Active Management Technology to meet
>> > growing manageability and security demands of your customers. Businesses
>> > are taking advantage of Intel(R) vPro (TM) technology - will your
>> > be a part of the solution? Download the Intel(R) Manageability Checker
>> > today! http://p.sf.net/sfu/intel-dev2devmar
>> > _______________________________________________
>> > Gramps-devel mailing list
>> > Gramps-devel@...
>> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
>> Enable your software for Intel(R) Active Management Technology to meet the
>> growing manageability and security demands of your customers. Businesses
>> are taking advantage of Intel(R) vPro (TM) technology - will your software
>> be a part of the solution? Download the Intel(R) Manageability Checker
>> today! http://p.sf.net/sfu/intel-dev2devmar
>> Gramps-devel mailing list