[GNC-dev] Porting the Tutorial & Concepts Guide to ReadTheDocs.org
John Ralls
jralls at ceridwen.us
Thu Feb 11 19:41:27 EST 2021
A couple of references to what Geert is talking about:
The W3C specification for Internationaliation Tag Set Locale Filters: https://www.w3.org/TR/its20/#LocaleFilter
Geert had in mind to use ITS Tool for processing Locale Filter tags; the relevant documentation is at http://itstool.org/documentation/its.html. No Anchors, scroll to Locale Filter.
I don't see anything similar in the rather sparse reST/Sphinx i18n docs, but ISTM we could probably accomplish something similar with the build system as long as the locale-unique material is in its own file. With a little more work we could invent a reST directive to hold the locale filter tags and preprocess the file before handing it off to Sphinx.
Regards,
John Ralls
> On Feb 10, 2021, at 5:43 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
>
> Hi Rob,
>
> I have gathered from irc conversations the you have picked up on your interest
> of converting our documentation to reStructuredText. As I'm unfortunately not
> able to spend much time on irc while you are there, I will add some comments
> on this mailing list thread.
>
> From the little information I have so far it looks like reStructuredText and
> the sphinx tool have everything it takes for a good conversion with plenty of
> benefits.
>
> The only concern that remains for me is as mentioned earlier:
> So far I don't see the ability for a master document in which certain sections
> only apply to some languages. To be fair our current documentation doesn't
> support that either as of today, but adding ITS to the current docbook mix
> would allow us to move in that direction.
>
> Personally I find that an important feature to have for our future
> documentation system. Contrary to many other domains, accounting documentation
> is sensitive to regional differences. Each region may have subtle differences
> in how certain things are to be explained.
> Luckily there is standardisation which means an estimated 90% of the
> documentation can be shared, but a small portion is region dependent. A
> typical example would be tax rules. Or some concepts only make sense in
> certain regions and don't apply at all in other regions.
>
> Considering most of the documentation is common, a translation flow based on a
> master document with message catalogs makes sense to me. The huge benefit is
> that we can offer user-friendly systems to translators. I seem to remember the
> biggest hurdle for documentation writers and translators is git. Going for a
> gettext based translation system, at least translators would be able to do
> most of their job in tools familiar to them, like weblate or poedit or
> whatever.
>
> But we should take care to also be able to handle that small part that's not.
> And that's where ITS in the docbook context would come in. It allows (among
> others) to mark certain sections as applying only to one specific "language".
>
> That would allow an American document writer to explain the basics of American
> taxes, and a Dutch translator could replace that with a Dutch alternative in
> such a way that if the American section changes the Dutch translation is not
> affected.
>
> And it would allow the American document to explain state taxes. Belgium and
> the Netherlands don't have states, so that section could be omitted in a Dutch
> translation.
>
> I admit not having searched very hard, but I didn't find something similar
> for reStructuredText or the sphinx build system.
>
> Do you see ways to implement something like that ?
>
> Regards,
>
> Geert
>
> Op zaterdag 25 april 2020 20:16:46 CET schreef Rob Gowin:
>>> On Apr 25, 2020, at 2:24 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
>>> wrote:
>>>
>>> Hi Rob,
>>>
>>> Thanks for running this experiment.
>>>
>>> The stylesheet used by ReadTheDocs is much more modern than ours and
>>> indeed looks much nicer for online consumption. Even the pdf is cleaner.
>>>
>>> On the other hand I also have a few concerns/questions:
>>> 1. How would a translation flow look like with asciidoc ?
>>> 2. Can it support a single master document including sections that should
>>> only appear for certain translations ? 3. ReadTheDocs is a hosted
>>> service. That's a big change from our current philosophy to self-host as
>>> much as possible. Are there self-hosting options ?
>>>
>>> Regards,
>>>
>>> Geert
>>
>> Hi Geert,
>>
>> First off, yes, the documentation can be self hosted. I’ve done that here:
>> https://gnucash-docs-test.codesmythe.net/index.html
>> <https://gnucash-docs-test.codesmythe.net/index.html>. It uses an older
>> stylesheet, so looks a little different, and there’s no PDF there. I have
>> generated a PDF similar to the ReadTheDocs one locally. Note that this
>> experiment uses files in the reStructuredText format, not asciidoc. The
>> reST files are generated from the DocBook files using pandoc.
>>
>> For translation: The underlying tool used by ReadTheDocs is the Sphinx
>> Python Doc Generation Project. Their I18N flow is described here:
>> http://www.sphinx-doc.org/en/master/usage/advanced/intl.html
>> <http://www.sphinx-doc.org/en/master/usage/advanced/intl.html>. I’m no
>> expert in the area, but seems it does support a single master document. I
>> don’t know about sections that should only appear for certain translations.
>>
>> I’ll jump on IRC sometime this week to discuss translations in more detail.
>>
>> Regards,
>>
>> Rob
>
>
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
More information about the gnucash-devel
mailing list