Re: Bug#144456: ITP: qref -- debian quick reference.
I realize I'm only being asked about the post-installation directory
structure of your documentation, but I'll take the liberty of commenting
on a few other things as a Debian user, only bear in mind that I'm
coming into the discussion just now.
Javier Fern?ndez-Sanguino Pe?a wrote:
>> - documentation packages should *not* include the documentation, they
>> should just do a "cvs co" from the DDP CVS (see harden-doc for example,
>> or the java-common package)
Do you mean source packages or .deb packages? Either way, this is a
problem for installation and development of Debian when a network
connection is not handy or is too slow to be desirable.
It's also a problem that CVS may not always be in a usable state. I
don't even think this is desirable for source development in all cases.
What if someone wants to customize documentation for their local site
against, for example, the version that came on their CD-ROM.
>> - (if the layout for languages in the DDP CVS is homogeneus -sp?- this
>> can easily be done) each documentation package creates one package for
>> every language that the documentation is available in.
Makes sense.
>> - documentation is always available under /usr/share/doc/package_name
>> /usr/share/doc/package_name-XX (XX is the iso reference for a given
>> language) contains a symlink to the documentation there. Translations
>> (I assume English is *always* the reference language, per policy)
>> are under /usr/share/doc/package_name/XX
>>
>> Now, there is also an interested (but unused) idea in the doc-debian-fr
>> package which makes /usr/share/doc/package_name/XX a symlink to
>> /usr/share/doc/LANG/XX/package_name
I don't think you want "/usr/share/doc/package_name-<language>/".
I think you want "/usr/share/doc/<language>/package_name/" and/or
"/usr/share/doc/package_name/<language>/". If both, then one is a
symbolic link to the other.
>> This could be useful if packages provided *all* the translations to be
>> able to remove unuseful translated documentation (similar to cleaning the
>> locale with localepurge). *But* at the same time provides an easy way for
>> users to find translated documentation (since everything under
>> /usr/share/doc/LANG/es/ is, for example, in spanish).
Would a good interface for users would be something like this? Have a
top-level documentation i18n package which asks the user on installation
for a prioritized list of languages. Someone could then say, I want
"all of es fr en" or "es with en only as fallback", etc. I still think
you want to download each translation separately, though.
Chris Tillman <tillman@voicetrak.com> writes:
> I like those ideas. And I think the most important thing is to get some
> sort of i18n system in place, whether perfect or not.
>
> For my .02 worth: It always seems better to me, to make a separate
> directory named for the lang itself rather than a separate directory
> with the lang appended with a - or something. If we were to stick with
> that convention, it would be quite easy to extract all of one
> languages' documentation in the end, plus users would come to know what
> to expect. I didn't see anything relevant in the FHS - should there be?
> (cc'ing to quinlan@pathname.com) Aside from documentation, as our
> operating system itself becomes more i18n'd, a standard becomes more
> important.
I would be very happy to accept a proposed patch to FHS (and it would be
fastest if someone from Debian could contribute it). I would recommend
using the above plus the /usr/share/man specification as a starting
point.
Dan
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: