Re: [DONE] man://manpages-de/soelim.1.po
Hallo Helge,
Am Di., 12. Jan. 2021 um 19:12 Uhr schrieb Helge Kreutzmann
<debian@helgefjell.de>:
>
> Hallo Mario,
> On Tue, Jan 12, 2021 at 06:56:16PM +0100, Mario Blättermann wrote:
> > Am Mo., 11. Jan. 2021 um 21:14 Uhr schrieb Helge Kreutzmann
> > <debian@helgefjell.de>:
> > > On Mon, Jan 11, 2021 at 07:39:25PM +0100, Mario Blättermann wrote:
> > > > Am Mo., 11. Jan. 2021 um 16:33 Uhr schrieb Helge Kreutzmann
> > > > <debian@helgefjell.de>:
> > > > >
> > > input sourced
> > > file file
> > > | |
> > > v v
> > > preprocessor -> troff -> postprocessor
> > > |
> > > v
> > > output
> > > file
> > >
> > > Was ich mir aber sehr schwer vorstellen kann, ist, wie die übersetzten
> > > Wörter dann in die Boxen passen sollen. Das könnte auf ein ziemliches
> > > Gefrikkel hinauslaufen, die Boxen dann auch richtig zu dimensionieren
> > > und zu positionieren.
> > >
> > Es geht; siehe Patch im Anhang.
>
> Naja, dass es prinzipiell geht, ist mir klar, aber Dein Patch geht auf
> die übersetzte Datei (?) ein, aber es müsste ja vollautomatisch immer
> wieder passieren, ohne explizite Patches. Und wo sollte der Patch dann
> eingespielt werden?
>
Ich wollte damit nur zeigen, dass es überhaupt machbar ist. Es ist so
wie bei UI-Übersetzungen, wo man manchmal voreingestellte Einzüge
verändern muss, dass das Gesamtbild wieder passt. Aber so einen
Patch-Workflow würde ich bei uns nicht einbauen wollen. Ich halte es
mit Übersetzungen generell so: Was ich nicht in der .po-Datei
übersetzen kann, das bleibt halt unbearbeitet.
> Ich weiß, dass es Programme zum automatischen berechnen und bezeichnen
> von Graphen gibt, aber ich würde eher meinen, dass das keine Domäne
> von po4a/groff/troff etc. ist.
>
Dieser »Graph« ist derart simpel, dass die Autoren dieser Seite
getrost auf die komplizierte Variante mittels pic.tmac verzichten und
das einfach als Tabelle oder so bauen könnten. Aber ob sie es machen,
steht auf einem anderen Blatt.
> > > Allerdings werden bei mir (Debian Testing, quasi Unstable) nur der Text
> > > darggestellt, die Graphik selbst spielt keine Rolle:
> > >
> > > man soelim:
> > > …
> > > The normal processing sequence of groff is this:
> > >
> > > input sourced
> > > file file
> > > | |
> > > v v
> > > preprocessor -> troff -> postprocessor
> > > |
> > > v
> > > output
> > > file
> >
> > Im Normalfall würde ich versuchen, die Autoren zu überreden, die
> > »Grafik« anders darzustellen. Ich mache mir aber wenig Hoffnung.
> > Bekanntermaßen stopfen die Schreiber der Groff-Handbuchseiten ihre
> > Werke mit allerlei Zeug voll, das man eigentlich nicht braucht und mit
> > dem Po4a oft überfordert ist. Mit dem KISS-Prinzip haben die nicht
> > viel am Hut. Das ging ja schon wo weit, dass der eigene Manpage-Pager
> > des Projekts die Seiten nicht richtig darstellen konnte (roff2ps.1
> > usw.).
>
> Ok. Ich kann natürlich ein FIXME setzen?
>
Versuch es einfach. Mehr als ablehnen können sie nicht.
> > Ganz ehrlich: Wenn ich alle Vorkommen des unverbrüchlichen
> > GNU-Starrsinns zusammenrechne, auch die in anderen Bereichen, müsste
> > ich eigentlich zu BSD wechseln. Man nehme einerseits die (relative)
> > Klarheit der Mdoc-Syntax und andererseits die kaum beherrschbare
> > Groff-Syntax, die sich auch noch damit paart, dass man ja eigentlich
> > gar keine Handbuchseiten bereitstellen will. Vielmehr setzt das
> > GNU-Projekt unbeirrt auf Texinfo-Handbücher, die außerhalb des
> > GNU-Kerns kaum ein Entwickler verwendet. Die hatten sicherlich mal
> > ihre Berechtigung, als man solche Dokumentationen noch auf Papier
> > ausgedruckt hat. Aber heute gehen die Uhren etwas anders...
>
> Für mich waren Info-Dateien immer eine Parallelwelt zu HTML und
> anderen Hypertext-Systemen, weniger zu Papier. Eingentlich ganz nett,
> die Doku strukturiert anzubieten. Nur wie Du schreibst, hat es keiner
> außerhalb aufgegriffen (und KDE, GNOME etc. haben ihre eigenen
> Hypertext-Modelle erfunden oder HTML genommen).
>
> Und ich persönlich finde für die meisten Handbuchseiten die flache
> Form auch praktischer, da kann ich leicht vor- und zurücksuchen und
> muss mich nicht semantisch durchhangeln. Bei der Doku von make oder
> andern ist das natürlich in einer Handbuchseite ggf. sehr unhandlich.
>
Ich suche selbst oft online in den HTML-Versionen von Handbuchseiten.
Die Texinfo-Versionen in HTML sind mir dagegen zu starr hierarchisch
aufgebaut und behandeln meist gleich mehrere Befehle. Was mich aber an
Texinfo am meisten stört, ist die fehlende Infrastruktur für
verschiedene Sprachen. Übersetzungen sind möglich (siehe [1]), aber
lassen sich nicht aufrufen, zumindest nicht so einfach, wie man es von
Handbuchseiten kennt. Bedingte Aufrufe anhand der Locale gibt es
nicht. Bei dem verlinkten Help2man-Handbuch muss der Benutzer »info
help2man-de« aufrufen, aber woher soll er das wissen...? Als ich vor
ein paar Jahren mit der Bitte an die Texinfo-Entwickler herantrat,
eine seit Jahrzehnten von Handbuchseiten bekannte Locale-Infrastruktur
auch in Texinfo einzubauen, haben die mich behandelt, als käme ich vom
Mond. Dieser Starrsinn ist schon grenzwertig.
[1] http://translationproject.org/domain/help2man-texi.html
Gruß Mario
Reply to: