[Qgis-community-team] See the doc images at github (or not)

[Richard Duivenvoorde]

Hi List,

if you look at the rst files in our documentation repo, you will only
see text, NOT the images:

https://github.com/qgis/QGIS-Documentation/blob/master/source/docs/training_manual/forestry/map_georeferencing.rst

It appears that this is because we keep our images at /resource/en/...
and copy them into /static during the build, to be able to have
localized images....

But after seeing the foss4glabs (markdown) sources in their github repo:

https://github.com/FOSS4GAcademy/GST101FOSS4GLabs/blob/master/Module%205%20Lab/QGIS%202.8/Module%205%20Lab.md

I wondered if it would also be possible that we showed our images in the
rst-view of github.

It indeed is easy: just copy the english (en) image directory to a
directoy 'static' and all images which are referenced like:

.. image:: /static/training_manual/forestry/f_1.png

are viewable now at github (this is a temporary fork to be able to
fiddle a little with this, note only foresty images are copied):

https://github.com/rduivenvoorde/QGIS-Documentation/blob/master/source/docs/training_manual/forestry/map_georeferencing.rst

as you can see, it is only plain images you see, the images which are
'shortcuts' from conf.py you will not see.

But I think it is valuable to see the images immediately in Github, it
makes spotting 'old' images much easier for doc writers/editors.

The only reason the images currently are not in '/static' dir/tree is
that we want the building process to be able to FIRST copy the
english(original) images in the /static dir during build and THEN copy
(optional) localized images over it during a localized build.

But there is not reason to not put the english images already in the
'/static' dir (so moving them from /resource/en/... to /static) and
change some steps in the build proces

So please comment on the following proposal:
- we move the resource/en directory to /static
- change some steps in the build scripts
- we could do the same for the website...

Comments?

Regards,

Richard Duivenvoorde