[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: splitting manpages-nl (and perhaps other manpages translations)



On Tue, Mar 20, 2001 at 08:08:32PM +0100, Joost van Baal wrote:
> OK, the general opinion seems to be it's better to keep 
> manpages-nl unsplit.  I can't resist to do one other shot at pleaing 
> for the cause of splitting.  So here it is.

It seems to me that the problem of internationalization and translation
of manpages to a specific language isn't the main problem we should try
to tackle.

Manpages are often just a part in the overall documentation that comes
with a software program. Other important documents are:

- README's (general and Debian specific)
- NEWS (the changelogs are probably not that interesting to translate)
- copyright file (and the license)
- FAQ's
- HTML files (including howto's and online books)

- GNU-Info files (created from Text-Info sources)
  http://lists.debian.org/debian-i18n-0101/msg00000.html

- In-progam-text (translated with gettext and POT/PO files)
  http://www.gnu.org/manual/gettext/index.html
  http://i18n.kde.org/translation-howto/gui-translation.html

- In the future raw XML documents could maybe be parsed online into 
  several other documentation-formats with reasonable results.
  http://lists.debian.org/debian-i18n-0101/msg00001.html

If the goal is to be able to eg. setup a "Dutch Debian box", and 'all'
you have are the manpages-nl documents and therefore having to get those 
other translated documents from other sources would seem strange to a user.

An idea could be to have a Debian package extension which would take into 
account which language(s), besides the standard English would be recommended
to get translated documents for, as indicated by the system administrator.

We would then need a specific package translation maintainer, alongside 
the real debian package maintainer. They would have to be able to work
reasonably independent, while a general translation (infrastructure)
team would track versioning of translations with new package releases.

Package translation maintainers could then put the translations into
/usr/share/doc/<package>/<language-code>/ and possibly use symlinks
when necessary or convienient.

The destinction between for standard the standard 'linux' manpages
between user and developer pages looks sufficient, and is already
used by other manpages translations.

So my point is that when we want to help the people who would 
rather read documents in another language than English, we should
be able to package the relevant documents, without too many different
package relations and duplication of information.

> > I think that you shouldn't split the package.
> Why not?  I didn't find an argument against it in your mail. 
> I could have misinterpreted it though.

I think the splitting should be done smarter, if splitting is done.
Working out such a smarter packaging implementation for documention 
translations would be interesting I think.

> Michael Neuffer wrote splitting it is overkill.  He didn't say
> why he feels like that, though...
> 
> Any more thoughts on it?

Putting all of the manpages-nl into one package will probably not scale
well, both technical and practical. Seperating the packaging role from
the translation role would then need a new debian package extension.

-- 
Jama



Reply to: