kicad-doc-devs team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hello Nick,

Am 28.09.2016 um 17:40 schrieb Nick Østergaard:
> To comment a bit. I would like to not use use a way that needs
> symlinks because they are not portable. I could possibly be an option
> for systems that do support it,  but I think we should try to avoid
> it.

I don't indent to use symlinks, the stupid M$ systems don't know about
real symlinks so this is no option. By this there will be always some
kind of data duplication needed.

> It seems systems like debian likes to split all languages up into
> seperate packages. I don't know if they have a common package or what
> they do for the common.

It's up to the package maintainers in Debian (and the other Linux
distros). They don't have to do that. But it's mostly more elegant and
saves space to do some foo-common package than do all the same in every
documentation package. Documentation has mostly really big data blobs.

> Please note that there is essentially three locations for images as it
> it seems. Just looking at the html source for the french doc I see the
> following example:
> images/en/status_bar.png
> images/fr/menu_bar.png
> images/toolbar_schedit_standalone.png
> 
> These are relative to the /share/doc/kicad/help/$LANG path.
> 
> How would you handle that gracefully? If we can do it without symlinks
> and duplicated data that would be number one choice.

The layout structure above is exactly that my patch does. Without the
patch there are all the other languages also around and there is no
single other one used than images/en and images/fr.

In the long term I see two possibilities.
Do it the above way, there will be ever two subfolders for the
screenshots and images, one default folder with the images from the
English "mother" and one for the desired language. This requires two
manual actions for the people doing localization.
1.) You need to change the folder in the *.po file for every own
    screenshot or image.
2.) And of course you need (to create and) add the desired image files.

Or there is always only one folder for the depended screenshot and
images. For example, if a new language is added the images from the
English default folder will be copied into $LANG/images/ . The relative
links inside the *.adoc don't need to be changed ever. The localizer for
LANG/foo is just replacing the existing original file against his new
one by the same name.
This would require of course a lot layout migration work to this folder
layout. A helper script or a Make target could help to create new languages.

Booth possibilities also don't be real de-duplication but better than
the situation now I think.

> I would like to not mix up the images root images and the en images
> dir into one dir.

No need for that and that wouldn't be useful at all.

> I have not tested your patch because I am not at my system, but
> reading the comment you mention that it is only a partial solution. If
> you could make a patch for a complete solution that would be best, I
> think.

I think there is no real solution as there is always the MS system to
take care. There are always some side effects to consider on the
different platforms and the need for compromises.

Don't think to much about symlinks, the Linux systems are flexible
enough to take this challenge and can do a real data de-duplication. The
user won't take every time a look into the filesystem as there is no
need for that. So the packager can do simply their job.

-- 
Regards
Carsten Schoenert