Bug 705881 - Clarifying handling of localized man pages (with manpages-l10n)
Summary: Clarifying handling of localized man pages (with manpages-l10n)
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Documentation (show other bugs)
Version: unspecified
Hardware: All All
: P4 normal
Assignee: Jamie Lemon
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-18 16:02 UTC by Helge Kreutzmann
Modified: 2024-01-11 12:42 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Helge Kreutzmann 2022-09-18 16:02:11 UTC
Hello,
I'm the Debian maintainer for manpages-l10n, a collection of man page
translations (from over 100 sources).

While translating some of the ghostscript man pages I noticed that you
as upstream already ship some German translations, and tried to avoid
file conflicts (translating a page which is already translated in your
sources).

However, the translations do not seem to be maintained automatically
(frozen at the version they were inititally translated to). And besides
German I do not see other languages included. Manpages-l10n has
(partial) translations for Danish, Czech and Polish for some pages as
well.

There are three options how to resolve this:
1. You keep only the translations as is. The remaining German and the
   Czech, Danish and Polish would come from manpages-l10n, as before.

2. You don't ship any translation and manpages-l10n would import the
   current German set. In the future, manpages-de, manpages-cz,
   manpages-da and manpages-pl (and maybe even more, e.g. manpages-uk)
   would maintain and ship these manpages. As we use
   po4a, they would be aligned with your changes, but of course with a
   delay (from a few weeks up to several months). Of course I would
   invite the previous translators of the German man pages to join
   manpages-l10n and keep working on them, if they like.

3. You integrate po4a to properly maintain language translations (this
   is not difficult and would need to extend your current manpage
   generation Makefile).
   Pending on my time, I could help you on this, but I would
   definitely help you integrate the existing translations.
   This way translators would work with you directly and you always
   ship up to date translations yourself (depending on the availability
   of the translators, of course).

My preference would be 3., followed by 2., followed by 1. (I would
really love to avoid 1.).

If you have any further questions regarding these options, please let
me know.

If I don't hear from you until mid October, I assume option 1. is valid.

Greetings

         Helge
Comment 1 Ken Sharp 2022-09-18 16:18:05 UTC
I'm assigning this to Chris provisionally as our build maintainer and Linux expert, maybe should be Jamie as our docs person.

But I suspect this needs discussed at Tuesday's staff meeting, I will make an agenda item for it.
Comment 2 Chris Liddell (chrisl) 2022-10-05 12:57:15 UTC
So, basically, the man pages and their translations were not written by nor, generally, maintained by us. They were contributed and the contributors have since lost interest, moved on, whatever... neither the English language man pages, nor the translations have had much attention.

Ultimately, our main source of information is always going to be the stuff in the doc/ folder, so the man pages always risk falling behind.

Our current plan is to review the English language man pages, cut them back to a minimal set of command line options (ones that have essentially existed from pre-history, and so are almost certain to never change), and then refer readers to our main documentation for more details.

That would then minimise the man page maintenance (and translations) effort in the long term.
Comment 3 Helge Kreutzmann 2022-10-09 13:32:41 UTC
Hello Chris,
thanks for the clarification.

From the manpages-l10n point of view: Do you want to carry the translated man pages in the future? Using po4a you can ensure they are always up to date, even if the original changes (even if this is unlikely in your proposal), or would you like to have them maintained externally (i.e. in manpages-l10n).

In the first case I can support you with the integration of po4a and potentially some initial partial translations for some languages (depending how much the new man pages differ from the old). Then I could announce this on the appropriate language lists and (hopefully) translators will finish the translations over time.

In the second case it would be best to remove the translated man pages from your repository at your earliest convenience to avoid file conflicts (which triggered this issue, as I discovered your translations this way as package maintainer for Debian).

Please inform me of your next steps so I can prepare accordingly on the manpages-l10n side (and/or provide you with the requested help).

Thanks

Greetings

        Helge

P.S. As a heavy user of man pages, which are conveniently accessed under *nix based operating systems I would be happy to have as much (almost) static content in the man pages themselves, but of course I'm biased, I know.
Comment 4 Chris Liddell (chrisl) 2022-10-10 14:06:17 UTC
Hi Helge,

Well, our next steps will be to find time to internally review and agree what to remove, keep and/or add to the existing English man pages, and make those changes. In all honesty, this isn't going to take a high priority, so I can't promise when it will be finished.
Comment 5 Helge Kreutzmann 2022-10-15 09:09:19 UTC
Hello Chris,
I perfectly understand that reviewing the existing man pages will take time. No problem on my side on this. Please do take your time for this.

What I intended to ask (sorry, if I was unclear on this) is how to handle the conflicts arising *today* in respect to *translated* man pages. There are three ways forward:

1. Translated man pages are not going to be contained in ghostscript itself.

2. Translated man pages are handled in ghostscript itself, but the infrastructure comes later.

3. Translated man pages are handled in ghostscript itself, and the infrastructure should be added now (which I can help you, if you want).

My preference is 3., 1. and then 2., but in the end, it is the way you would be most comfortable with.

It would be great if you could discuss and decide on this.

The implication on your side then would be:
For 1. You simply remove the existing translations. Nothing more.
For 2. I send you the translations from my side and you commit them. Maybe the install target needs slight updates, but nothing more now. 
For 3. I work on the po4a integration and you comment on this. Once ready, you commit it alongside the (converted) existing translations. And some testing, of course.

Therefor the required effort is (at least for 1. and 2.) rather low on your side and avoids quite a bit of (potential) hazzle in Linux distributions later.

I can expand on this, if so, please simply state what information you are missing/which would help you decide (and "implement").
Comment 6 Chris Liddell (chrisl) 2022-10-20 08:57:29 UTC
Hi Helge,

I would rather the translations were not included in the ghostpdl repo, because it just raises the possibility of the same problem we have now happening again in the future.

By that I mean, should po4a disappear or be wound up for some reason, we'd be left with unmaintained/unmaintainable content in our repo (again!).
Comment 7 Helge Kreutzmann 2022-10-31 18:10:44 UTC
Hello Chris,
the nice thing about po4a is that texts are always current, even if translations are lacking (i.e. the new text is shown in English, until the translator updates it, but no outdated text is shown).

However, you are right, if for some reason po4a should vanish (a proposition I don't share), then yes, the translated texts are no longer updated and new paragraphs are no longer replaced by their english version.

I personally would have preferred a different solution, but since you made the decision, I would kindly ask at which version the current translations are removed? I ask, because then manpages-l10n can take over without file conflicts.

I will integrate the current translations starting with that version into manpages-l10n, so for users who install manpages-de nothing will change then.
Comment 8 Helge Kreutzmann 2023-01-11 16:58:23 UTC
Hello Chris,
do you have any time frame on proceeding?

Your first step is easy - remove the translated man pages, release a new version and inform me.
Comment 9 Helge Kreutzmann 2023-04-08 16:59:28 UTC
Hello Chris,
do you have any time frame on proceeding?

I'd really like to remove the file conflicts between ghostscript and manpages-l10n. This would make the package maintainers of various distributions happier. And once you made the step, translators in manpages-l10n can also work on the translations again.

If there is any (other) information you need, please let me know.

Greetings

              Helge
Comment 10 Helge Kreutzmann 2023-10-07 16:24:00 UTC
Hello Jamie,
is there anything I can do to get this bug progressed? In the end, it is a few simple "rm" commands.

For the translators, manpages-l10n and downstream package managers this bug is quite annoying.

Thanks for taking care!

Greetings

          Helge
Comment 11 Jamie Lemon 2023-10-09 13:39:55 UTC
Hi Helge,

Are you able to create a patch off the main Ghostscript branch with your suggestion email it to me?
Comment 12 Helge Kreutzmann 2024-01-09 13:34:28 UTC
Hello Jamie,
first of all, sorry, I somehow missed your reply, thus I'm now replying with delay.

Secondly, when trying to come up with the requested patch, I noticed that you already removed the man pages in commit 00f9c8bc1acdd9d17691d9b4515c3d89509c21b5 almost exactly about a year ago.

Thus this bug is fixed and now manpages-l10n can ship the translated man pages itself.

If, at any later time, you would like to ship translated man pages (again), do not hesitate to contact me.
Comment 13 Jamie Lemon 2024-01-11 12:42:26 UTC
👍