kicad-doc-devs team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hi,

Am 22.03.19 um 11:45 schrieb Marco Ciampa:

> 1) I preserved my make scripts (in /kicad-doc/utils/old-build-scripts)
> because I did not trust the cmake scripts that I do not understand, now
> sadly it turns out that I was right... we _must_ fix the cmake scripts or
> use another tool, this situation is not acceptable. Unfortunately I do
> not know how cmake works, beside, as cmake scripts _are_ software, some
> docs on those shouldn't hurt us...

if no body is around to fix up such cmake related problems we need to
ask if cmake is the right tooling. And my experience over the years is
simply that cmake doesn't do a better job, it does it just different
than the autotools. Even a more or less statically makefile would mostly
fit the needs kicad-doc has.

So why stay in the long term on cmake?

> 2) asciidoc _is_ migrating to python 3 (there is already a port under
> test but as far as I know it is working well...) so some UTF-8 problems
> should be a thing of the past in the near future.

That depends what "near future" is by the people behind the asciidoc
project. My impression here was it's not really a serious task there to
do any porting work.

> 3) unfortunately asciidoctor is not addressing some i18n issues, like,
> for example i18n for dates/tocs/references ... see for example this:
> 
> http://docs.kicad-pcb.org/5.1.0/it/getting_started_in_kicad/getting_started_in_kicad.html
> 
> look at the toc title in the upper right corner, and it is the same for
> pdf, epub etc.

Sorry, I don't get it. What's wrong here? You mean the untranslated
"Tabel of Contents". This is a really minor issue in my eyes.

> I think they are trying to look for the "perfect method" but meanwhile
> time passes and this "right way to do the things" is not popping up... 
> :-( I would have preferred an imperfect temporary solution for the time
> being but the asciidoctor developers are not listening...

Well, it's Ruby and Ruby is Web shit. ;)
But Ruby is much better than some other thinks in the web+2.0 world.

> The way the old asciidoc is handling this is IMHO ... working (one .conf
> file for language so anybody can supply its language version...

I don't mind which toolset is used as long as the output is what we
expect to see. But the current problems which we see especially in
Japanese is a big problem. I haven't tried asciidoctor to see if this is
getting better here. Such things are good topics for a sprint somewhere
were people can sit together and work for several hours together on
problems and issues like this.
At least we would need to compare the requirements. We should start to
collect these!

> BTW I posted a bug some months ago for chinese translators to check
> it for correctness and to ask for inclusion of their nationalized
> conf file to the asciidoc devs ... will you (chinese translators)
> please do this for me? I do not write chinese, you see...
Yeah, you will see this for every language that is just used on some
small parts in the world. It's not nice but that's a thing FOSS needs to
live with.

-- 
Regards
Carsten Schoenert