Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#367 Enable filenames $NAME.$LANG.$SECTION by parameter

output: manpages
closed-fixed
XSL (399)
5
2007-02-03
2006-10-27
Daniel Leidert
No

In Debian bug report #310895
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310895),
it was requested, that the filename of manpages shall
contain the language they are written in. E.g.

foo.fr.1

I suggets to enable this via a parameter. Maybe
man.output.lang. The content for $LANG could be get
from the lang-attribute of the refsect element:

<refsect id="man_foo" lang="fr">
[..]
</refsect>

Your opinion?

PS: I'm currently not able to check the source code to
see, if there is already such a possibility (broken
harddrive). But I read the parameters reference and did
not find a parameters, that seem to enable such a
behaviour.

Regards, Daniel

Discussion

  • Daniel Leidert
    Daniel Leidert
    2006-10-27

    Logged In: YES
    user_id=1102637

    In the case of implementing this feature, the
    man.output.subdirs.enabled should probably sort the manpages
    into $base.dir/$lang (maybe with or without the $LANG value
    in the filename).

     
  • Logged In: YES
    user_id=118135

    It's little work to add support for foo.$LANG.1 and I'm happy to add it if it's really useful. But
    I'm not sure it is useful. As I mentioned in my comment to Debian bug #310895, I don't understand
    what the need for a man page named foo.$LANG.1 would be; that is, why not just put it into man/$LANG/
    foo.1 instead?

    Anyway, adding support for $base.dir/$lang is easy and I will go ahead with doing it. But before I
    add support for foo.$LANG.1 I would like to be sure that's it actually useful or necessary.

     
    • assigned_to: nobody --> xmldoc
     
  • Daniel Leidert
    Daniel Leidert
    2006-10-28

    Logged In: YES
    user_id=1102637

    Two reasons, why it may be useful:

    It is possible, that all manpages (the original and the
    translated ones) are built in the same directory and subdirs
    are not wanted (this might be the case in autotool build
    environments).

    More important: AFAIK the dh_installman debhelper script
    accepts filenames like the requested one (see it's manpage)
    and automatically sorts them into the right installation
    directory /usr/share/man/$LANG/... This might also be a case
    for the above scenario.

    But I would vote for: If subdirs are enabled, only sort the
    manpage into $base.dir/$LANG, without adding $LANG to the
    filename. Only add it, if subdirs are disabled and the $LANG
    extension is requested via parameter.

     
  • Logged In: YES
    user_id=118135

    > Two reasons, why it may be useful:
    >
    > More important: AFAIK the dh_installman debhelper
    > script accepts filenames like the requested one (see
    > it's manpage) and automatically sorts them into the
    > right installation directory /usr/share/man/$LANG/...

    OK. Thanks -- I hadn't actually known about that. But I
    can see that it makes good sense.

    > But I would vote for: If subdirs are enabled, only
    > sort the manpage into $base.dir/$LANG, without adding
    > $LANG to the filename. Only add it, if subdirs are
    > disabled and the $LANG extension is requested via
    > parameter.

    OK, sounds good. I will try to get this implemented
    today or tomorrow.

    --Mike

     
    • status: open --> open-fixed
     
  • Logged In: YES
    user_id=118135
    Originator: NO

    A change for this issue has been added to the current codebase.
    Please test the change with the latest snapshot from:

    http://docbook.sourceforge.net/snapshots/

     
    • status: open-fixed --> pending-fixed
     
  • Logged In: YES
    user_id=118135
    Originator: NO

    Hi Daniel,

    I finally added support for this. Please test it.

    btw, We'll be releasing 1.72.0 soon.

    --Mike

     
    • status: pending-fixed --> closed-fixed
     
  • Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).