Bug 37612

We don't have any translated man pages yet, so I guess the first step is
figuring out how we'd integrate that into the Makefile.am for the package
so it's included in the distrubution and installations.

Alan,
  Is it worth investigating converting the man page troff files into docbook?  Docbook has built it support for languages.  Separate languages are either kept in separate files or in the same file but marked with a 'lang'  attribute.  Then it would then just be a matter of setting a LANG env var.

 1) I don't say this lightly as I know it will cause me more work.
 2) I'm definitely not pushing this,  just asking out of curiousity.

I'm also willing to provide a patch using po4a: we already take care of translating x11-xserver-utils manpages in Debian inside the manpages-fr-extra package (so all the work is already done, just need to be updated to fit in your build process). po4a offers the translator the ability to translate the manpages in PO files, without altering existing manpages, and works well wih troff files, and makes sure the translation is up to date (not up to date parts of the manpages would be shown in English).

Regards

David

All,
  thoughts on upstreaming that translation work?  

I have a feeling we could pull work from some of the other distros and languages.  everyone benefits.  not pushing, I just hate to see dupication of efforts across distros.

Hi,

> thoughts on upstreaming that translation work?  

If you're referring to Debian's manpage-fr-extra, the answer is yes, we'd be glad too (that's why I'd like to provide a patch to you (upstream), so it would benefit to everyone. The po4a build process can of course handle all needed languages, so it would be even easier to includes new manpages translation.

> I have a feeling we could pull work from some of the other distros and
> languages.  everyone benefits.  not pushing, I just hate to see dupication of
> efforts across distros.

Ditto, I do believe that manpage-fr-extra is just intended to include translation not yet included upstream, and as stated in the social contract [0], “We will give back to the free software community” is one of the motto.

  0: http://www.debian.org/social_contract

I'll try to provide a patch within a week.

Regards

David

(In reply to comment #2)
> Alan,
>   Is it worth investigating converting the man page troff files into docbook? 
> Docbook has built it support for languages.  Separate languages are either kept
> in separate files or in the same file but marked with a 'lang'  attribute. 
> Then it would then just be a matter of setting a LANG env var.

It could be worth thinking about, I think we've even got a couple man pages
already in docbook format in the tree, and I believe the closely related
fontconfig project uses docbook for all it's man pages.

We'd want to make sure that providing nroff man pages for systems that need
them is simple, whether that means doing docbook -> nroff at dist time or
something else, I don't know.

*** Bug 11159 has been marked as a duplicate of this bug. ***

http://patchwork.freedesktop.org/patch/5625/
http://patchwork.freedesktop.org/patch/5626/
http://patchwork.freedesktop.org/patch/5627/

Last I remember from discussions is that adding any translation file requires initializing the po infrastructure with AM_GNU_GETTEXT which adds to build time. To be honest no tests were performed to measure the impact, but it does add a whole whack of files.

Any workaround to using the autoconf solution is bound to go through the whole cycle of reinventing the wheel and will not work on all platforms.

In my book, delaying building to dist is a hack as it was not designed for workloading balancing, just creating a tarball. We already have a module that does po configuration the wrong way with custom code.

Note that I am not really talking about po4a, which looks good last time I try, but to the general infrastructure that is required to host translation which is missing. It may look strange for someone who has always been working in a build system that has always had full support for translation.

I have little experience with translation file in a GNU build system. Introducing a new capability in a build system by trying to be as non obtrusive as possible is not a good strategy in my opinion. If it is worth doing, then it should be done being consistent with the GNU Build system, work on all platforms, and be applied the same way in all modules having translation. There is a possibility of up to 178 modules with man pages and we don't want the code to be different in each of them.

There is one module which looks to me as the correct way of adding translation file to a package:

http://cgit.freedesktop.org/xkeyboard-config/tree/

with one exception of using the GLIB version of the GETTEXT which is not recommended by automake.

If you nead my help for translate this man, I'm here.
Now, I wait for this project.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/app/xrandr/issues/12.