Hello,
sorry I send the E-Mail not to the list.
Am 12.09.18 um 12:59 schrieb David Cousens:
> Mechtilde,
>
> I wasn't suggesting we use google translate at all where there is a human
> translator available and willing, but in some
> languages it may be difficult to get a translator, even though
John,
Point taken. I rarely use the yelp viewer from inside Gnucash at all and
mainly use the online HTML documentation. It could be to separate context
sensitive help into it's own structureis one way to go. I would have thought
for the more tutorial aspects currently in the guide it would
> On Sep 11, 2018, at 5:12 PM, David Cousens wrote:
>
> Hi John,
>
> I do understand that alternatives to docbook are being considered.
>
> I keep referring to it primarily because it is the current format, rather
> than necessarily the best or even what may be used in future. Perhaps with
Hi John,
I do understand that alternatives to docbook are being considered.
I keep referring to it primarily because it is the current format, rather
than necessarily the best or even what may be used in future. Perhaps with
an assumption that whatever format is decided on, it will at least
Op maandag 10 september 2018 17:26:44 CEST schreef David T. via gnucash-devel:
> The idea of use-case recipes sounds rather like the “walkthrough" described
> in the pronovix article, which they clearly see as a specific, separate,
> experience. Such resources have their place, but not in the
Op dinsdag 11 september 2018 15:13:51 CEST schreef David T.:
> Hello,
>
> > On Sep 11, 2018, at 4:45 AM, Geert Janssens
> > wrote:>
> > Op dinsdag 11 september 2018 09:15:43 CEST schreef David Cousens:
> >> David,
> >>
> >> Just some comments on a couple of other points:
> >>
> >> Embedding
Yes, sorry. I misspoke on that last point.
Regards,
Adrien
> On Sep 11, 2018, at 1:10 PM, David T. wrote:
>
> Adrien,
>
> I’ll note here that you seem to have the documentation model backwards,
> insofar as you suggest that interface changes wouldn’t affect the Guide. I
> believe that such
Adrien,
> On Sep 11, 2018, at 1:09 PM, Adrien Monteleone
> wrote:
>
>
>
>> On Sep 11, 2018, at 8:13 AM, David T. via gnucash-devel
>> wrote:
>>
>> Hello,
>>
>>
>> I envision that the context help would consist of short _functional_
>> descriptions of one or two sentences. I believe
I don't know about allowing room for it, but it's pretty far in the future
because we still have too many Gnome dependencies in the core and too many MVC
violations to be able to implement a different toolkit.
Regards,
John Ralls
> On Sep 11, 2018, at 10:23 AM, Adrien Monteleone
> wrote:
>
> On Sep 11, 2018, at 8:13 AM, David Cousens wrote:
>
> Hi Geert
>
> "I know you can define these links in docbook. However my remark earlier in
> this thread is how will they work in practice ? How can one document on the
> system know where the other is stored ? I presume this means we
Then I misunderstood some earlier discussions about the UI, at least with
respect to Linux. What toolkit is envisioned to be used? What layout
principles? Or are those questions so far in the future as to not be worth
spending time allowing room for?
Regards,
Adrien
> On Sep 11, 2018, at
> On Sep 11, 2018, at 10:09 AM, Adrien Monteleone
> wrote:
>
>
>
>> On Sep 11, 2018, at 8:13 AM, David T. via gnucash-devel
>> wrote:
>>
>> Hello,
>>
>>
>> I envision that the context help would consist of short _functional_
>> descriptions of one or two sentences. I believe that the
> On Sep 11, 2018, at 8:13 AM, David T. via gnucash-devel
> wrote:
>
> Hello,
>
>
> I envision that the context help would consist of short _functional_
> descriptions of one or two sentences. I believe that the rate of change in
> the functions of the UI elements is exceedingly small. In
Hi Geert
"I know you can define these links in docbook. However my remark earlier in
this thread is how will they work in practice ? How can one document on the
system know where the other is stored ? I presume this means we should have
strict rules about the relative locations of documents.
Hello,
> On Sep 11, 2018, at 4:45 AM, Geert Janssens
> wrote:
>
> Op dinsdag 11 september 2018 09:15:43 CEST schreef David Cousens:
>> David,
>>
>> Just some comments on a couple of other points:
>>
>> Embedding even the context help in the program code is not a really good
>> idea. It means
Op dinsdag 11 september 2018 09:15:43 CEST schreef David Cousens:
> David,
>
> Just some comments on a couple of other points:
>
> Embedding even the context help in the program code is not a really good
> idea. It means that text cannot be edited /altered easily separately from
> the program
David,
Just some comments on a couple of other points:
Embedding even the context help in the program code is not a really good
idea. It means that text cannot be edited /altered easily separately from
the program and without rebuilding the program. My understanding is that it
can be done from
Op dinsdag 11 september 2018 06:03:28 CEST schreef David Cousens:
> This link (http://www.sagehill.net/docbookxsl/Db5Tools.html) provides the
> mechanism for linking between different docbooks. It would probably a good
> idea to mark any docbook links with a do not delete message for example. so
David,
I also subscribe to your manifesto:
I agree that the Concept guide should be just that. Not how to specifically
do something using Gnucash
1. A minimal set of basic accounting concepts with reference perhaps to more
detailed material.
2. Some discussion how GnuCash implements these:
Hi David Cousens,
I opened Bug 796852 - Context sensitive Help broken. Can you add the
details there?
TIA
Frank
Am 11.09.2018 um 04:13 schrieb David Cousens:
> Geert,
>
> No, my mistake in thinking it was in yelp Geert. I was looking into
> something else at the time and just noticed that the
Geert,
It can process HTML but I haven't yet put other markup through it. I am not
sure how to batch it but there is an interface which will up load a file and
translate it and presumably allow you to save it back. I doubt if you would
use it if you have an active translator available for a
Geert,
No, my mistake in thinking it was in yelp Geert. I was looking into
something else at the time and just noticed that the context Help did not
come up in passing yesterday. Imentioned it in the post last night without
having checked it out fully. My apologies for that. When it happened I
Chris,
It maybe worth pursuing if libwebkit can support context sensitive help. It
HTML Help on Windows I believe a set of
aliases mapped onto URLs for the appropriate section of HTML help files from
the help file is generated by the processor
and then used to pull up the appropriate section of
Am 10.09.2018 um 00:32 schrieb D:
> Frank,
>
> You raise significant points about the effect that this might have on
> translations.
>
> How would it be if these changes occurred in the course of a piecemeal
> approach? In other words, if I or someone else were to essentially remove the
>
OK. In reply to my own message, I have paged through the Help and compared it
to the Guide. I compiled a mapping framework from Help to the Guide, and found
that this might not be as huge an undertaking as I initially thought.
Here are my thoughts:
1. Introduction to GnuCash
Dear All,
I reply to this message (even though it lacks the previous discussions for
context), as it is the latest in the thread. I will, however, try to take on
some of the issues that have gotten raised. I apologize for the length and
density of the reply.
With regard to translations, I am
Op maandag 10 september 2018 15:26:19 CEST schreef David Cousens:
> Geert,
>
> Is there not perhaps a way to leverage Google translate as a first pass to
> translate text. The result may not be colloquial and produce some
> interesting results. I have used it for Russian to English translations
XInclude reference also modular files:
http://sagehill.net/docbookxsl/ModularDoc.html. It should just require
using a switch on xsltproc --xinclude when building
David
-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
Geert,
Is there not perhaps a way to leverage Google translate as a first pass to
translate text. The result may not be colloquial and produce some
interesting results. I have used it for Russian to English translations and
it doesn't do too bad a job.
Geert
Docbook has a mechanism for including other xlm files either by declaring an
ENTITY which maps on to the filename containing the snippet xml code. You
can then use & to include the file contents at any point. You
can also construct "header files" which contain the entity definitions which
Op maandag 10 september 2018 13:51:28 CEST schreef Christopher Lam:
> On Mon, 10 Sep 2018 at 19:31, David Cousens
>
> wrote:
> > One problem I see for Unix is that at present there doesn't appear to be a
> > help viewer in Unix that has support for context level help. Doc books can
> > obviously
On Mon, 10 Sep 2018 at 19:31, David Cousens
wrote:
>
> One problem I see for Unix is that at present there doesn't appear to be a
> help viewer in Unix that has support for context level help. Doc books can
> obviously support defining links that can be accessed from help buttons or
> a
> key
Op maandag 10 september 2018 13:30:20 CEST schreef David Cousens:
> One problem I see for Unix is that at present there doesn't appear to be a
> help viewer in Unix that has support for context level help. Doc books can
> obviously support defining links that can be accessed from help buttons or a
Op zondag 9 september 2018 12:21:08 CEST schreef Frank H. Ellenberger:
> -: I18N: We will loose the current translations and probably frustrate
> the last translators and loose their readers.
>
Absolutely true. However I don't know if that's sufficient reason to keep the
less that satisfactory
Thanks Geert
My apologies to David T if I misunderstood the intention re a single
document. A single document with separate sections may help to reduce
duplication, but that mainly requires editorial effort no matter whether it
is a single document or not. it would certainly help with searches.
Op zaterdag 8 september 2018 16:57:52 CEST schreef David T. via gnucash-devel:
> Hello,
>
> As I have noted in another thread recently, I am finding the process of
> updating the various documentation pieces extremely challenging—due in
> large part to the fragmented nature of this documentation.
Op maandag 10 september 2018 10:11:11 CEST schreef David Cousens:
> David,
>
> As well as Frank's objections to rewriting, why does having one massive file
> necessarily improve the structure or maintainability. This is not the case
> with programming code. Docbook can include files in a far more
David,
As well as Frank's objections to rewriting, why does having one massive file
necessarily improve the structure or maintainability. This is not the case
with programming code. Docbook can include files in a far more structured
manner than the gnucash xml sources do at the moment. I would
Frank,
You raise significant points about the effect that this might have on
translations.
How would it be if these changes occurred in the course of a piecemeal
approach? In other words, if I or someone else were to essentially remove the
text from one document, put it in the other, and add
Hi,
Am 08.09.2018 um 17:48 schrieb John Ralls:
>> On Sep 8, 2018, at 7:57 AM, David T. via gnucash-devel
>> wrote:
>>
>> Hello,
>>
>> As I have noted in another thread recently, I am finding the process of
>> updating the various documentation pieces extremely challenging—due in large
>> part
David,
Count me in. (with a vote for Markdown)
Consider the idea of making the bulk of the current Help to be appendices of
the new Manual. Many of those pages are simply reference lists of the menu
entries.
Also, consider arranging the Manual by function rather than form. If GnuCash
evolves
> On Sep 8, 2018, at 7:57 AM, David T. via gnucash-devel
> wrote:
>
> Hello,
>
> As I have noted in another thread recently, I am finding the process of
> updating the various documentation pieces extremely challenging—due in large
> part to the fragmented nature of this documentation.
Hello,
As I have noted in another thread recently, I am finding the process of
updating the various documentation pieces extremely challenging—due in large
part to the fragmented nature of this documentation. Different contributors
have placed information on similar topics in any of a number
43 matches
Mail list logo
