Re: stale manpage rename.ul in manpages-{de,fr}?

[Mario Blättermann]

Hello,

Am Do., 9. März 2023 um 18:13 Uhr schrieb Helge Kreutzmann
:
>
> Hello Martin,
> On Thu, Mar 09, 2023 at 05:33:02PM +0100, Martin Schulte wrote:
> > > On Thu, Mar 09, 2023 at 11:38:00AM +0100, Martin Schulte wrote:
> > > > Hello French and German l10n-maintainers,
> > > >
> > > > there's no rename installed with util-linux in Debian 11, 
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926637 explains why.
> > > >
> > > > But still there are French and German manpages in the according 
> > > > packages, I consider this an error – at least it is confusing.
> > >
> > > Could you kindly be more precise? Which version of manpages-de do you
> > > have installed?
> >
> > I'm using "Debian GNU/Linux 11 (bullseye)" on a x86_64 system.
>
> Ok, stable.
>
> > > I just checked our sources and $ dpkg -L manpages-de|grep rename
> > > /usr/share/man/de/man1/rename.ul.1.gz
> >
> > Yes, the manpage is there, but the program isn't. There is also no manpage 
> > in /usr/share/man/man1 - it just exists in the French and German 
> > translations (as far as I've checked).
>
> This happend when we had a transition of maintainers upstream. So
> I think we carried the rename.ul man page back then a little too
> long and so it went into Bullseye when it should't have.
>

We weren't aware of this change. I will archive the appropriate .po
files and remove the template prior to the next release of
manpages-l10n (btw, which happens today :)) Then I could add the
»rename« package (see below) to our package lists, if desired, so we
can translate it and ship the German and French man pages with the
next version.

> I apologize for the inconvenience.
>
> You have the following options:
> 1. Ignore the translated man page
>
> 2. Install the backport for manpages-de / manpages-fr
>This also contains more and improved man page translations
>
> 3. Upgrade to testing/bookworm
>
> In Testing/Bookworm, rename.ul is both present in english, as well as
> in German, French and Ukrainian. So everything is fine there.
>
As you can see at [1], the English version of rename.ul isn't
available anymore from Debian, only our translated versions. The
rename.1 man page [2] comes from a separate package [3]. What happens
when you call »rename« in a terminal. Does *anything* happen, or maybe
the rename command isn't part of a typical Debian installation
anymore?


[1] https://manpages.debian.org/bullseye/manpages-de/rename.ul.1.de.html
[2] https://manpages.debian.org/bullseye/rename/rename.1.en.html
[3] https://packages.debian.org/source/unstable/rename

Best Regards,
Mario

Re: Some observations regarding manpage translations

[Mario Blättermann]

Hello Jean-Philippe,

Am Di., 19. Apr. 2022 um 18:55 Uhr schrieb Helge Kreutzmann
:
>
> […]
> >
> > Indeed, unfortunately. It completely disappointed me last months to review
> > man1 due to this. A pain! Thanks to Jean-Pierre who tries to catch up this.
>
> I share your pain. I know projects which like to reformat their man
> pages about once a year. And even the regular updates can be quite
> time consuming, e.g. for systemd.
>
> > > Another example from today: wget.1.po was checked in today,
> > > unfortunately not completely translated. However, one missing
> > > string was just a typo away from an already translated string and
> > > others were trivially to handle (e.g. version numbers), so I could
> > > almost complete the part of OpenSUES Leap as well, even without
> > > French knowledge.
> > >
> > > I noticed (and sometimes handled) similiar issues in the past as well,
> > > but doing this more systematically of course requires some time. And
> > > since I don't speak French, I can only perform trivial updates and some
> > > easy fixes (if I knew French), i.e. "low hanging fruits" I have to
> > > skip.
> >
> > What is your approach? Reviewing this manually is really a pain for me. Any
> > suggestion to reduce the needed work is welcome.
>
> Well, I'm not sure which editor you use. Some po editors can handle
> fuzzy strings quite nicely, I was told. I'm quite old school myself
> and I use vim (with po extensions) and run plain "diff" on the
> previous and the current string, May some day #611544 is resolved
> (dreaming).
>
See the attached screenshot. It shows the lower left part of the
Lokalize window with po/fr/man1/script.1.po opened. In a fuzzy
message, you can exactly see what has been changed since the last
update. This makes it very easy to »unfuzzy« files. However, Lokalize
is a bit sensible: the bigger the .po file, the more often Lokalize
crashes … But I prefer it anyway, because the crashes happen only in
very big files (> 1000 messages).

Best Regards,
Mario

Re: Some observations regarding manpage translations

[Mario Blättermann]

Hello Jean-Philippe,

Am Di., 19. Apr. 2022 um 00:41 Uhr schrieb Jean-Philippe MENGUAL
:
>
> Hi,
>
> Le 18/04/2022 à 13:17, Helge Kreutzmann a écrit :
> > Hello fellow manpage translators,
> > I made some observations when watching the French updates which I
> > would like to share with you. Please kindly disregard them if they are
> > obvious, done on purpose or do not apply; I'm not speaking French and
> > I'm not involved in any discussion regarding French translation, hence
> > these observations might be totally not applicable.
>
> Thanks for your message, it is useful to see how we can do better
>
> >
> > Without further ado:
> >
> > 1. After completing a translation, it is quite helpful to reformat it,
> > either before committing or in a second commit. This has two
> > benefits:
> > a) If there are any syntax errors, you immediately spot this.
> > b) Further scripts do not touch the file simply for reformatting,
> >making the "git diff" better to read.
>
> I apply hooks/pre-commit in my git command. Is this enough?
>
> > 2. If a translation has been proofread, it is usually quite helpful to
> > immediately (after reformatting) add it to the compendium
> > (../use-for-compendium.sh manx/foo.x.po)
> > and then update all translations
> > ../update-translations.sh
>
Reformatting is not mandatory, but recommended. But it is very helpful
to add the file to the compendium. And also ../update-translations is
not urgently needed, because it is very time-consuming and will be run
during each upstream update every two or three weeks. To benefit from
recent compendium additions/changes, you should update a certain file
which you like to edit (using ../update-po.sh) to get it in sync with
other files.

> To be honest I am not completely confortable with compendium stuff, so
> ok, I add those 2 commands to my automated committing scripts and we
> will see the result. I trust you.
>
> > Before committing, "git diff" is quite helpful.
> >
> > This has two benefits:
> > a) In many cases, other man page translations (fuzzy strings, missing
> >strings) are updated as well, easing the work and bringing more
> >pages over 80% (and thus the translations to users).
> > b) This is an extra check; in my recent updates I noticed errors
> >when performing these steps, especially during the final "git diff",
> >which I corrected, even though I do not speak French.
>
> Could you give an example please? I dont feel good to review again via
> git diff before commit but if something was not seen by our review
> process, I can try for it to eliminate this kind of typo
>
> >
> > 3. I'm not sure about your systematics, but I do notice that quite a
> > few man pages are close to complete or close to reach the 80%
> > threshhold. Once they are at 80% they are shipped to users. Of
> > course, sometimes you do not want them to be shipped (unless 100%),
> > maybe because of problematic strings, so this might be deliberate.
> > However, when prioritizing, looking at
> > 
> > https://manpages-l10n-team.pages.debian.net/manpages-l10n/debian-unstable-fr.html
> > (and similarly for all other distros like Arch, Fedora, ...) you
> > can notice that several man pages just lack one or two strings to
> > reach 80% (and using the compendium, see 2., the number of these
> > pages maybe reduced even further).
> >
> > I regularly build all man pages and provide you a list of all pages
> > between 70%-79% below. In case you would like to receive this list
> > regularly, I can try to set this up (but the web listing above
> > should cover this nicely as well).
>
> Many thanks. So far I just go forward following the alphabetic order.
> Because I want to avoid the risk of duplicate work with other
> translators, without needing to use an ITT message to the list. It would
> require a good coordination process. But why not, according to what
> others think.
>

With every upstream update, before I update the .po files, I try to
find out what can be easily updated without speaking all our supported
languages. Then I update strings in the compendium files which
containstuff which needs only to be copied or, for example, in already
translated strings which became fuzzy due to a changed version number
or so.

> > 4. Check for similar strings or easy unfuzzy after upstream updates.
> > When looking at French pages, I often noticed that there were quite
> > a few strings which are trivially to handle. Sometimes upstream
> > just removed or added spaces after full stops, corrected a link or
> > a typo ...
>
> Indeed, unfortunately. It completely disappointed me last months to
> review man1 due to this. A pain! Thanks to Jean-Pierre who tries to
> catch up this.
>

To mention, most of the changes in util-linux translations are the
result of a code base change from pure groff/mdoc to Asciidoctor. I've
done 

Re: [DONE] po://xz-utils/po/fr.po

[Mario Blättermann]

Hello,

Am Di., 4. Jan. 2022 um 14:31 Uhr schrieb Jean-Pierre Giraud
:
> […]
> C'est terminé, les fichier sont dans manpages-l10n. Merci à bubu pour sa
> traduction et à Daniel et Lucien pour leurs relectures.
> Amicalement,
> jipege

Maybe you have seen that the xz* man page translations are only
enabled for Debian Bullseye in manpages-l10n. Have a look at [1]: The
upstream project already has a working po4a infrastructure. My German
translation is there for a while, and some of the distributions which
ship xz-5.2.5 already have the translated man pages packaged. For
Bullseye, I don't expect that they would accept a bug report for the
missing files, but for Sid it needs to be reported. Fedora, Mageia and
Opensuse have the translated versions, the latter in a separate
package named xz-lang. That's why I removed the xz stuff from most
package lists at manpages-l10n.

It would be nice if you would merge the existing .po files into one
using msgcat, update with the latest template (just run update-po in
the xz git repo) and send the result to the xz-devel mailing list [2],
even in the current (incomplete) state. If you need help with this,
get back to me, I'm subscribed to xz-devel anyway.

BTW, the obviously finished xzdec.1.po doesn't contain any translator name…?

[1] 
https://git.tukaani.org/?p=xz.git;a=tree;f=po4a;h=aeb49fd1816e0e8fd952c4ca16b12036e6f090f1;hb=HEAD
[2] https://tukaani.org/xz/lists.html

Best Regards
Mario

Re: French translations of util-linux-man

[Mario Blättermann]

ain/ util-linux-man.html.
> >
> > I see Jean-Paul Guillonneau and Jean-Philippe MENGUAL worked on some
> > translations in 2021.
> >
> > Only one person can work on a po file at a time, do any of you want to take
> > over that translation ?
> >
> > Frédéric
> >
> >
> > Le mercredi 15 septembre 2021, 19 h 46 min 50 s CEST Mario Blättermann a
> >
> > écrit :
> > > Hello Frédéric,
> > >
> > > you are the current translator of util-linux at GNU TP. Some months
> > > ago I started with migrating the util-linux man pages from *roff to
> > > Asciidoctor. As I side effect, I have convinced the util-linux
> > > maintainer to integrate the man page translations in the upstream
> > > tree. I've imported the following translations from manpages-l10n [1]:
> > >
> > > addpart.8.po
> > > agetty.8.po
> > > blkdiscard.8.po
> > > blkid.8.po
> > > blockdev.8.po
> > > cfdisk.8.po
> > > chcpu.8.po
> > > chrt.1.po
> > > ctrlaltdel.8.po
> > > delpart.8.po
> > > dmesg.1.po
> > > fallocate.1.po
> > > fdformat.8.po
> > > fdisk.8.po
> > > findfs.8.po
> > > findmnt.8.po
> > > flock.1.po
> > > fsck.8.po
> > > fsck.cramfs.8.po
> > > fsck.minix.8.po
> > > fsfreeze.8.po
> > > fstab.5.po
> > > fstrim.8.po
> > > getopt.1.po
> > > hwclock.8.po
> > > ionice.1.po
> > > ipcmk.1.po
> > > ipcrm.1.po
> > > ipcs.1.po
> > > isosize.8.po
> > > kill.1.po
> > > last.1.po
> > > ldattach.8.po
> > > libblkid.3.po
> > > logger.1.po
> > > losetup.8.po
> > > lsblk.8.po
> > > lscpu.1.po
> > > lslocks.8.po
> > > mcookie.1.po
> > > mesg.1.po
> > > mkfs.8.po
> > > mkfs.cramfs.8.po
> > > mkfs.minix.8.po
> > > mkswap.8.po
> > > more.1.po
> > > mount.8.po
> > > mountpoint.1.po
> > > namei.1.po
> > > nsenter.1.po
> > > partx.8.po
> > > pivot_root.8.po
> > > prlimit.1.po
> > > raw.8.po
> > > readprofile.8.po
> > > rename.ul.1.po
> > > renice.1.po
> > > resizepart.8.po
> > > rev.1.po
> > > rtcwake.8.po
> > > runuser.1.po
> > > script.1.po
> > > scriptreplay.1.po
> > > setarch.8.po
> > > setsid.1.po
> > > setterm.1.po
> > > sfdisk.8.po
> > > sulogin.8.po
> > > swaplabel.8.po
> > > swapon.8.po
> > > switch_root.8.po
> > > taskset.1.po
> > > terminal-colors.d.5.po
> > > umount.8.po
> > > unshare.1.po
> > > utmpdump.1.po
> > > uuid.3.po
> > > uuid_clear.3.po
> > > uuid_compare.3.po
> > > uuid_copy.3.po
> > > uuidd.8.po
> > > uuid_generate.3.po
> > > uuid_is_null.3.po
> > > uuid_parse.3.po
> > > uuid_time.3.po
> > > uuid_unparse.3.po
> > > wall.1.po
> > > wdctl.8.po
> > > whereis.1.po
> > >
> > > After the import, I've merged the .po files into one and synced with a
> > > template newly created from a Git checkout (the current template from
> > > TP is outdated). Then I've fixed the
> > > markup where possible and added some more translations, as far as
> > > possible without speaking French (merely copying messages such as
> > > "B<-r>, B<--reverse>" which don't need to be translated).
> > >
> > > From my side, the import is finished; the translation state is
> > > currently at 83%. Maybe you have the time and/or motivation to work on
> > > the file? It would be nice if you could translate and/or proofread at
> > > least the 9 messages at the beginning of the .po file. They rely on
> > > some addendum files which appear in almost all of the resulting
> > > translated man pages.
> > >
> > > You can test the translations as follows: Checkout the util-linux Git
> > > repo with the command "git clone
> > > https://github.com/karelzak/util-linux.git;. Then copy the .po file
> > > into po-man/, rename it to fr.po and add "fr" to the [po4a_langs] line
> > > in po-man/po4a.cfg. Then run "po4a po4a.cfg", and the translated
> > > *.adoc files will appear in po-man/fr/. Currently you will get 96 out
> > > of 135 possible files.
> > >
> > > @debian-l10n-french: Many thanks for your work on the util-linux man
> > > page translations last years. In manpages-l10n, we will keep the .po
> > > files still for a whil, until all of our supported distributions ship
> > > the translated man pages with the util-linux package. Maybe someone of
> > > you likes to help the French TP team to complete the translation and
> > > keep it up-to-date?
> > >
> > > [1]
> > > https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/tree/master/po
> > > /
> > > fr
> > >
> > > Best Regards,
> > > Mario
>
>
>
>

Next release of manpages-l10n

[Mario Blättermann]

Dear translators,

as you might know, the manpages-l10n project releases a new tarball
approximately every three months. The next release will happen around
June 13, 2021.

Have a look at the status pages [1]. There you see some (or even lots
of) .po files marked in red. In many cases, there are only a few
Gettext messages to translate to reach the 80% threshold. This needs
Po4a to create the translated man page. Even if you don't complete the
translation, you make sure that this man page is available for users –
admittedly, still with some English parts, but it is present.

The Git infrastructure is already prepared for including two new
languages into the tarball: Czech and Danish.

Happy translating!

[1] https://manpages-l10n-team.pages.debian.net/manpages-l10n/index.html

Best Regards,
Mario

Translated man pages of util-linux will move to the upstream project

[Mario Blättermann]

Dear translators,

the manpages-l10n project [1] hosts man page translations of the
util-linux tools [2] for some years. Because this external approach
has some disadvantages, the .po files will be moved to the GNU
Translation project soon. Besides the conversion of the source files
from *.roff to asciidoc, the localization using po4a [3] has been
enabled in util-linux itself. A translation template is already
available from [4] (will still be moved to another location in the
project tree, probably po-man/, see [5]).

To mention, in manpage-l10n we have .po files for util-linux man pages
in German, French, Spanish and Polish. I'm already working on the
import of the existing files. This will need at least a few weeks,
maybe months. Because util-linux v2.37 will be released soon and the
template will then be available from a newly to be created TP domain:
Please don't start with the translation into the mentioned languages,
to avoid double work! I will send the prepared .po files to you or
your mailing lists once I'm finished with the import. Of course,
translators of other languages can start as usual. The early
publication of the template is only to give translators of other
languages as much time as possible for their work.

A util-linux tarball *including* translated man pages will not be
released before the import has been finished, this means, possibly
during the lifecycle of util-linux 2.37 (in one of the v2.37.x bugfix
releases), or even later, with v2.38 in autumn this year. Otherwise it
would be too difficult to avoid file conflicts in distribution
packages. In manpages-l10n, we need either to keep all affected .po
files or remove them all in once. If we would try to remove only some
files partially, it would be almost impossible to consider all
imaginable file conflicts. That's why we postpone the activation in
util-linux for the time being.

[1] https://salsa.debian.org/manpages-l10n-team/manpages-l10n
[2] https://github.com/karelzak/util-linux
[3] https://po4a.org/
[4] 
https://raw.githubusercontent.com/karelzak/util-linux/master/man-common/util-linux-man.pot
[5] https://github.com/karelzak/util-linux/pull/1271

Best Regards,
Mario

manpages-l10n: Upcoming release 4.9.3

[Mario Blättermann]

Dear translators,

the next release of manpages-l10n [1] will happen 2021/03/09 around
19:00 UTC. We need this release to stay in sync with the current
packages in Debian Bullseye. Our update from upstream packages is
already done yesterday. The upcoming Debian version is already frozen
regarding package versions and changes are only possible with the
agreement of the release managers. Sorry for this small time frame; as
an Archlinux user, I'm not really familiar with the release management
policies in Debian. Nevertheless, v4.9.3 will be the final version for
Bullseye, because it becomes more and more difficult to jusitfy new
package versions and can end up in long discussions.

Maybe it's now the time to shift priorities and have a look at the
status pages [2] (the »Debian Unstable« pages, which are still in sync
with Bullseye). As you might know, we use Po4a for managing
translations, and this tool requires that a .po file is at least 80%
translated to get the localized version. You see many files marked
red, which means that the corresponding .po file doesn't reach this
threshold. By working on these, you can easily increase the number of
localized man pages users will get. In many cases there are only a few
gettext messages to translate. Example from Polish:

Name   |Percent |Translations > 80% |Statistics
make.1 |79% |1  |78 translated, 9 fuzzy, 11 untranslated

This means, even without completing the translation, you decide
whether users get a localized man page - or not - by translating one
(!) message.

After 4.9.3, changes will flow in backport packages, but not all users
are aware of or willing to use backports. So this release will be the
very last localized man page collection which Bullseye users will get.

For those of you who don't have direct write access to our Git
repository: Just send your updated files to me, I will commit them.

Happy translating!

[1] https://salsa.debian.org/manpages-l10n-team/manpages-l10n
[2] https://manpages-l10n-team.pages.debian.net/manpages-l10n/

Best Regards,
Mario

Next release of manpages-l10n

[Mario Blättermann]

Dear translators,

as you might know, the manpages-l10n project releases a new tarball
approximately every three months. The next release will happen around
February 6, 2021.

Especially for Debian users it is of particular interest that Bullseye
is almost »frozen« – however, the upcoming release of manpages-l10n is
probably not the final version which gets into Bullseye, but maybe
*now* it would be time to shift personal priorities and point to that
new Debian version, regarding translation efforts.

Have a look at the status pages [1]. There you see some (or even lots
of) .po files marked in red. In many cases, there are only a few
Gettext messages to translate to reach the 80% threshold. This needs
Po4a to create the translated man page. Even if you don't complete the
translation, you make sure that this man page is available for users –
admittedly, still with some English parts, but it is present.

The Git infrastructure is already prepared for including two new
languages into the tarball: Italian and Spanish. Because the current
man-pages-it package in Mageia is v4.08, we will jump from 4.2 to 4.9
to get a proper upgrade path. Note, the Spanish part of manpages-l10n
brings Spanish man pages back to Debian, but will *not* replace the
manpages-es-extra package for the time being. After our v4.9 has been
released, I will start with importing the files from
manpages-es-extra.

Happy translating!

[1] https://manpages-l10n-team.pages.debian.net/manpages-l10n/index.html


Best Regards,
Mario

Re: manpages-l10n: Problems with applying the compendium messages

[Mario Blättermann]

Hello Thomas,

Am Do., 31. Dez. 2020 um 15:39 Uhr schrieb Thomas Vincent :
>
> Hello Mario,
>
> Le 31/12/2020 à 10:02, Mario Blättermann a écrit :
> > In general, it would be very helpful if the committer of a .po file
> > would run the script use-for-compendium.sh for that file. This way the
> > translation can be written back to other .po files, which saves time.
> > But before committing such changes, always run »git diff« to see what
> > would be changed.
>
> Could this be done automatically in a git hook?
>
> I would see something like this:
> - The translator changes a .po file and commits it.
> - The git hook (pre-commit, probably) runs use-for-compendium.sh.
> - If the script didn't change anything, the commit goes on. Otherwise,
> the commit is stopped and a message is displayed to advise the
> translator to add the changed files.
>
> What would you think about this?
>
First, let's have a look at the desired workflow:

Once someone is finished with translating and/or reviewing a .po file,
it gets committed into the Git repo. If this file contains some
Gettext message which appears more than once in the .po file
collection, that message is also to find somewhere in the compendium
files.

There are two possible cases:

In the first case, the message in question is already translated
somewhere - and also translated in the compendium. If the recently
changed .po file contains a new version of that message (wording,
formatting etc. have been changed), then this new message in the .po
file gets overwritten with the older version from the compendium next
time someone runs update-po.sh, either explicitely or through another
script like update-translations.sh. The updates and the review of the
.po file would become useless. That's why it is needed to run
»./use-for-compendium.sh man?/filename.po« to overwrite the
compendium.

In the second case, the message is part of the compendium, but still
untranslated or »fuzzy« there. If someone runs
./use-for-compendium.sh, the message will be added to the compendium
and next time someone runs ./update-translations.sh, it will be
written back to all .po files where it appears - maybe lots of files
would benefit of it. In fact, it's what I do when I update the .po
files from recently downloaded upstream packages: After running
./update-common.sh in each of the language directories, I have a look
at the compendium files, especially common/min-100-occurences.po.
After an upstream update of the »manpages« and »manpages-dev«
packages, in a few messages only the version number has been changed,
for example 5.09 to 5.10 some days ago. Then I fix this, remove the
»fuzzy« tag, and hundreds of files benefit of this simple change when
I run ./update-translations.sh.

So let me summarize: It is urgently recommended to run
./use-for-compendium.sh after changing a .po file.

Back to the Git hook question. As far as I can evaluate, it would be
not very helpful, because the effect of use-for-compendium.sh always
should be reviewed by running »git diff«. In some cases, the things
added to compendium are ambiguous. In such cases, the Gettext message
in question needs to be added to templates/exclude.pot, as described
in CONTIBUTING.md. Anyway, if you like to run the script
automatically, do it at your own risk.

Best Regards,
Mario

manpages-l10n: Problems with applying the compendium messages

[Mario Blättermann]

Hello,

today I've added the recently committed .po files to the compendium,
as I do from time to time. The following gettext message from
man2/fcntl.2.po has been added:

#. type: Plain text
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
#: opensuse-tumbleweed
msgid "For a successful call, the return value depends on the operation:"
msgstr ""
"La valeur renvoyée par B() varie suivant le type d'opération\\ :"

It is there from the first day on; it came with the initial import
from Perkamon. But now the message resides in the compendium, it will
be written back to other .po files where this message appears, like
man2/bpf.2.po. But then the translation is wrong. I've fixed it (see
the appropriate commit), but this should be proofread by a native
speaker.

In general, it would be very helpful if the committer of a .po file
would run the script use-for-compendium.sh for that file. This way the
translation can be written back to other .po files, which saves time.
But before committing such changes, always run »git diff« to see what
would be changed.

Best Regards,
Mario

Translations of Pacman in manpages-l10n

[Mario Blättermann]

Hello,

some time ago I imported old French translations of the Pacman tools
(the package management system from Archlinux) and added them to
manpages-l10n. Although 11 years old, some of them even reach the 80%
threshold for Po4a. However, most of the files are too incomplete, and
I'm not able to maintain them because I don't speak French.

Assuming that Debian translators don't want to bother with
Archlinux-only stuff, I asked for help in the French Archlinux forum
[1] and got an answer. Someone is willing to help with completing the
files. But usually translations go through a review process here
(ITT/RFR/LCFC etc.). Unless someone of you is really willing to review
the Pacman manpages, would it be OK for you to skip this process for
Non-Debian translations? Then I would commit the .po files for Jean,
or he gets his own Git access and commits his files, where he is not
allowed to touch other files which don't belong to Pacman (unless he
provides them for review). What do you think?

Please keep J.-J. in CC, maybe he's not subscribed to this list.

[1] https://forums.archlinux.fr/viewtopic.php?f=18=22024=175347#p175347

Best Regards,
Mario

Re: Next release of manpages-l10n

[Mario Blättermann]

Hello all,

I've just released v4.2.0, I've succeeded to figure it out how this
works. It was simpler than expected, see below.

Am So., 4. Okt. 2020 um 10:29 Uhr schrieb Jean-Philippe MENGUAL
:
>
>
> Le 04/10/2020 à 07:32, Helge Kreutzmann a écrit :
> > Hello Jean-Philippe,
> > On Sat, Oct 03, 2020 at 08:25:36PM +0200, Mario Blättermann wrote:
> >> Am Sa., 3. Okt. 2020 um 20:03 Uhr schrieb Jean-Philippe MENGUAL
> >> :
> >> You don't have to be an »uploading developer« for releasing an
> >> upstream tarball of manpages-l10n. This is only for Debian packaging.
> >> Upstream releasing and downstream packaging do not necessarily have to
> >> be linked to each other. Of course, this can be done by different
> >> persons, although manpages-l10n is still to be considered as a Debian
> >> project, but meanwhile distribution-agnostic.
> >
> > I strongly concour with Mario.
> >
> > manpages-l10n uses Debian infrastructure, but it is not a Debian
> > project, but rather an upstream one.
> >
> > There are various downstreams as Mario gave a nice overview.
> >
> > One of them is Debian, where currently Tobias is the Maintainer.
> > Unfortunately Tobias is not able to maintain both the Debian
> > downstream and the upstream project as he used to be.
> >
> > Mario is very involved in getting the upstream part working again
> > (which I stronly support where I technically can) and we are
> > discussing this (albeit very slowly) with Tobias.
> >
> > I offered to take over the Debian downstream part, which I technically
> > could (though reviewing the steps once more especially for backports
> > could be helpful), but I'm no developer, so Tobias would need to grant
> > me the permission for uploads. This has been proposed to Tobias, so I
> > hope the Debian side gets going properly again as well.
> >
> > But the big issue are the upstream releases.
>
> Can Tobias, Mario and whoever write a step-to-step doc (eg. in
> CONTRIBUTING.md) with administrative commands and actions needed to be a
> release manager? Perhaps I can help if I have the process and the git
> commands written, if I know who announce the next release to, etc. In
> case I have technical issues, I may find help on the mailing lists. But
> this initial doc is absolutely needed to help a non-tech person to do
> the release management I think.
>
Preparing a release is quite simple:

Search with grep for the current version number. You'll get some
occurrences in »configure«, »configure.ac«, »CHANGES.md« etc.
(Don't bother with the version numbers in .po file headers)
Replace the old version number with the new one.
Write an appropriate entry in CHANGES.md.
Run »autoreconf« (don't know if this is really needed).
Commit and push the changes.

Then, use the Gitlab web interface for creating the tag:

In the sidebar on the left, click on »Tags«. In the tag overview on
the right, click on the »New tag« button.
Fill the mask with the values for the new release:
Tag name: v4.2.0
Create from: master (just leave this entry untouched)
Message: Release 4.2.0

That's all. Users and downstream packagers can now download the
tarball from the known location. I'll add these steps to
CONTRIBUTING.md soon.

Usually I tell then the Mageia, Opensuse and Archlinux packagers about
the new release (Fedora has its own notification service for upstream
releases). Regarding Debian, someone needs to pick up the package
maintenance.

Best Regards,
Mario

Re: ...

[Mario Blättermann]

Hello,

Am Sa., 3. Okt. 2020 um 21:57 Uhr schrieb Jean-Philippe MENGUAL
:
>
> Hi,
>
> Thanks for the report. What you report does not seem to be a manpage
> problem, but rather in the GNU make translation itself. Please check if
> the bug is still present and if it is, could you report to GNU make
> upstream?
>
This is the appropriate Gettext message in the French translation of
GNU make-4.2.93:

#~ msgid "%s: recipe for target '%s' failed"
#~ msgstr "%s : la recette pour la cible « %s » a échoué"

In this latest version it has already been fixed, and moreover, this
message is no longer used. The most recent occurence is in make-4.0:

#: job.c:501
#, c-format
msgid "%s: recipe for target '%s' failed"
msgstr "%s : la recette pour la cible « %s » a échouée"

This version has been released october 9, 2013 and is still shipped
with Debian Jessie. Don't know whether it's worth the effort at all.
Jessie is actually EOL (June 30, 2020), but still marked as
»oldoldstable«, maybe until Bullseye has been released and Stretch
becomes »oldoldstable«.

Best Regards,
Mario

Re: Next release of manpages-l10n

[Mario Blättermann]

Hello Jean-Philippe,

Am Sa., 3. Okt. 2020 um 20:03 Uhr schrieb Jean-Philippe MENGUAL
:
>
> Hi,
>
> Le 03/10/2020 à 19:52, Mario Blättermann a écrit :
> > Hello,
> >
> > Am Sa., 3. Okt. 2020 um 16:15 Uhr schrieb Jean-Philippe MENGUAL
> > :
> >>
> >> Hi,
> >>
> >> What about the release and a Debian package? I still don't see any
> >> package in the Debian repo.
> >
> > The manpages-*_4.1.0 packages are present in Sid (but not in Buster 
> > backports):
> > https://packages.debian.org/de/source/sid/manpages-l10n
>
> hmmm. A Google search plus a apt-cache search manpages-l10n (or show)
> does not return anything. Maybe there is not binary yet? Why?
>
There's no binary package named manpages-l10n. The source package gets
split in the usual packages manpages-fr, manpages-fr-dev, manpages-de,
manpages-de-dev and so on. By choosing the existing names, we get a
proper upgrade path and avoid that users will be forced to install
lots of man pages in other languages – which would happen in an
all-in-one package of manpages-l10n.

> >
> >> We are not yet at freeze time, but probably
> >> we should try to release a package?
> >>
> >
> > Indeed, especially to do justice to the needs of our supported Rolling
> > Releases (Debian Sid, Opensuse Tumbleweed, Archlinux) we should try to
> > release every three months, and the latest release was three months
> > ago.
> >
> > Two weeks ago I wrote to Tobias Quathamer, asking him to tell me the
> > steps of a release, so that I would become able to do releases myself.
> > He didn't respond yet. As I already knew, actually he doesn't have the
> > time anymore to contribute to manpages-l10n, neither for translations
> > and the release management nor for maintaining the Debian packages. In
> > the past months, I took some administrative tasks over, like updates
> > from upstream packages, updating the authors list, testing the
> > committed .po files for formatting issues and so on. But I don't have
> > any Autotools skills, so I haven't tried to roll out a release yet.
> >
> > This means, first we need a new release manager. Someone who's willing
> > and able to handle the Autotools stack, create the release tarball,
> > and if needed, to fix things if something fails. Second, the Debian
> > part needs a new package maintainer. The German translator Helge
> > Kreutzmann already said that he would take this over, at least as a
> > co-maintainer. Packages for the other distributions are actively
> > maintained, except for Archlinux, but I maintain some (Git-based)
> > unofficial packages in the Arch Linux User Repository, this is OK so
> > far.
> >
> > That's why I call for a volunteer for this task! He would probably
> > need to get the »owner« state in the Salsa repo, but this shouldn't be
> > the problem.
>
> hmmm. Thanks for this message, raising very important information. I am
> not an uploading devloper, but I would like to search for an idea. If
> anyone in the l10n teams has an iedea too, welcome!

You don't have to be an »uploading developer« for releasing an
upstream tarball of manpages-l10n. This is only for Debian packaging.
Upstream releasing and downstream packaging do not necessarily have to
be linked to each other. Of course, this can be done by different
persons, although manpages-l10n is still to be considered as a Debian
project, but meanwhile distribution-agnostic.

Best Regards,
Mario


>
> Regards
>
>
> >
> > Thanks in advance,
> > Mario
> >
> >
> >> Regards
> >>
> >>
> >>
> >> Jean-Philippe MENGUAL
> >> Debian Developer non uploading
> >> Community team member
> >> Accessibility team member
> >> debian-l10n-french team member
> >> President of Debian France non-profit organization
> >> Le 30/05/2020 à 08:27, Jean-Philippe MENGUAL a écrit :
> >>> Le 29/05/2020 à 21:12, Helge Kreutzmann a écrit :
> >>>> Hello Tobias,
> >>>> On Sat, Apr 04, 2020 at 09:40:41PM +0200, Dr. Tobias Quathamer wrote:
> >>>>> Am 10.02.20 um 10:10 schrieb Mario Blättermann:
> >>>>>> the manpages-l10n project is now almost ready for a release. The new
> >>>>>> version 4.0 is scheduled for march 1, 2020. All commits prior to this
> >>>>>> date will be included in the tarball.
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> the new package manpages-l10n has just been accepted into Debian
> >>>>> unstable. Thanks fo

Re: Next release of manpages-l10n

[Mario Blättermann]

Hello,

Am Sa., 3. Okt. 2020 um 16:15 Uhr schrieb Jean-Philippe MENGUAL
:
>
> Hi,
>
> What about the release and a Debian package? I still don't see any
> package in the Debian repo.

The manpages-*_4.1.0 packages are present in Sid (but not in Buster backports):
https://packages.debian.org/de/source/sid/manpages-l10n

> We are not yet at freeze time, but probably
> we should try to release a package?
>

Indeed, especially to do justice to the needs of our supported Rolling
Releases (Debian Sid, Opensuse Tumbleweed, Archlinux) we should try to
release every three months, and the latest release was three months
ago.

Two weeks ago I wrote to Tobias Quathamer, asking him to tell me the
steps of a release, so that I would become able to do releases myself.
He didn't respond yet. As I already knew, actually he doesn't have the
time anymore to contribute to manpages-l10n, neither for translations
and the release management nor for maintaining the Debian packages. In
the past months, I took some administrative tasks over, like updates
from upstream packages, updating the authors list, testing the
committed .po files for formatting issues and so on. But I don't have
any Autotools skills, so I haven't tried to roll out a release yet.

This means, first we need a new release manager. Someone who's willing
and able to handle the Autotools stack, create the release tarball,
and if needed, to fix things if something fails. Second, the Debian
part needs a new package maintainer. The German translator Helge
Kreutzmann already said that he would take this over, at least as a
co-maintainer. Packages for the other distributions are actively
maintained, except for Archlinux, but I maintain some (Git-based)
unofficial packages in the Arch Linux User Repository, this is OK so
far.

That's why I call for a volunteer for this task! He would probably
need to get the »owner« state in the Salsa repo, but this shouldn't be
the problem.

Thanks in advance,
Mario


> Regards
>
>
>
> Jean-Philippe MENGUAL
> Debian Developer non uploading
> Community team member
> Accessibility team member
> debian-l10n-french team member
> President of Debian France non-profit organization
> Le 30/05/2020 à 08:27, Jean-Philippe MENGUAL a écrit :
> > Le 29/05/2020 à 21:12, Helge Kreutzmann a écrit :
> >> Hello Tobias,
> >> On Sat, Apr 04, 2020 at 09:40:41PM +0200, Dr. Tobias Quathamer wrote:
> >>> Am 10.02.20 um 10:10 schrieb Mario Blättermann:
> >>>> the manpages-l10n project is now almost ready for a release. The new
> >>>> version 4.0 is scheduled for march 1, 2020. All commits prior to this
> >>>> date will be included in the tarball.
> >>>
> >>> Hi all,
> >>>
> >>> the new package manpages-l10n has just been accepted into Debian
> >>> unstable. Thanks for all your work!
> >>
> >> Thank you very much for your work and the scripts as well.
> >>
> >> I discussed this with Mario and we think it would be a good time to
> >> target the next version, now with some more languages (I guess Mario
> >> has a better overview of the stats) maybe in about a week?
> >>
> >> I just checked with the French team, this release would close also the
> >> remaining open Debian bugs for manpages-fr.
> >>
> >> And afterwards a Debian backport would be nice.
> >
> > What would bu useful, if possible, is having a schedule of releases, to
> > know when will be the latest release before the freeze for Bullseye. We
> > still hope to finish the updating work before Bullseye. What is the
> > absolute deadline for it?
> >
> > Regards
> >
> >>
> >> Of course, the other supported (and unsupported) distribution might
> >> also use the chance to do the update, e.g. for Fedora for the very
> >> first time.
> >>
> >> Greetings
> >>
> >>  Helge
> >>
> >>

manpages-l10n: Odd change in tsort.1.po

[Mario Blättermann]

Hello all,

recently tsort.1.po has been changed as follows:

"Report tsort translation bugs to Ehttps://translationproject.org/team/;
"E"
msgstr ""
-"Signaler toute erreur de traduction de tsort à EIE"
+"Signaler toute erreur de traduction de tsort à EIE"

(committed by Jean-Philippe Mengual)

It doesn't make sense to give the users a link where they have first
to figure out the real team address. Although msgid doesn't show it
(because it's generic), the translation should contain the full link
to the team page. As far as I can remember, I had proposed this
already a few months ago.

I think this refers not only to tsort, but to other Coreutils man pages, too.

Cheers,
Mario

Re: Next release of manpages-l10n

[Mario Blättermann]

Hello,

Am Fr., 29. Mai 2020 um 21:12 Uhr schrieb Helge Kreutzmann
:
>
> Hello Tobias,
> On Sat, Apr 04, 2020 at 09:40:41PM +0200, Dr. Tobias Quathamer wrote:
> > Am 10.02.20 um 10:10 schrieb Mario Blättermann:
> > > the manpages-l10n project is now almost ready for a release. The new
> > > version 4.0 is scheduled for march 1, 2020. All commits prior to this
> > > date will be included in the tarball.
> >
> > Hi all,
> >
> > the new package manpages-l10n has just been accepted into Debian
> > unstable. Thanks for all your work!
>
> Thank you very much for your work and the scripts as well.
>
> I discussed this with Mario and we think it would be a good time to
> target the next version, now with some more languages (I guess Mario
> has a better overview of the stats) maybe in about a week?
>
Yes, let's keep the releases about every three months. This is a fair
compromise between being strictly up-to-date and a comfortable
workflow for both translators and downstream packagers.

The recently imported Italian translations should be disabled for the
time being. I've written to Marco Curreli that after completion of the
import, maybe in a few weeks, the next release then will include the
Italian translations. Until then we have to solve a problem: Although
not visible at the project page, the version 5.06 of manpages-it has
been released. It is available from Bitbucket [1], and at least Mageia
has already updated the package to this version. This means, to get a
proper upgrade path, we need to update manpages-l10n to a version
number greater than 5.06, or force downstream packagers to use »Epoch«
mechanisms.

> I just checked with the French team, this release would close also the,
> remaining open Debian bugs for manpages-fr.
>
> And afterwards a Debian backport would be nice.
>
> Of course, the other supported (and unsupported) distribution might
> also use the chance to do the update, e.g. for Fedora for the very
> first time.
>
The package manpages-l10n-4.0.0 is already in Fedora Rawhide, based on
a Git checkout. But it is far from being complete. That time, our
package list was not up-to-date, and there were some problems with
involving the Fedora man pages in the update mechanisms. Should be
solved now.

[1]  https://bitbucket.org/marco.it/man-pages-it/downloads/

Best Regards,
Mario

Re: [ITT] po4a://manpages-fr/nano/po/fr.po 25f 59u

[Mario Blättermann]

Hello,

Am Do., 28. Mai 2020 um 08:33 Uhr schrieb Jean-Pierre Giraud
:
>
> Bonjour,
>
> Le 28/05/2020 à 07:07, Jean-Philippe MENGUAL a écrit :
> > Salut Jean-Pierre,
> >
> >
> > Tu veux bien regarder cette page ou quelqu'un doit s'en charger?
> >
> > Cordialement,
> >
> Oui, je vais m'en occuper, bien qu'il y a une erreur de nom : je ne suis
> pas le traducteur initial qui s'appelle en fait Jean-Philippe Guérard...

Sorry, my mistake. Fixed in Git.

Best Regards,
Mario

Nano man page translations

[Mario Blättermann]

Hello,

some days ago I found translations of the Nano man pages [1]. Written by
Jean-Pierre Giraud in the year 2006, the files were present for a while in
the Git repo, but never really shipped with a downstream package. I've
imported the text into .po files, merged with the current templates and
committed to our Git repo.

[1] https://lists.gnu.org/archive/html/nano-devel/2006-08/msg00053.html

Best Regards,
Mario

Your last commits in manpages-l10n

[Mario Blättermann]

Hello Mattéo,

thanks for your recent submissions to the manpages-l10n project. Some
notes about them:

The French translations are maintained by the Debian French
translation team, which is responsible for quality assurance. It is
not OK that you commit your files without sending a mail to their
mailing list to enable proofreading, and anyway to inform them that
you've changed something.

Normally, translators are not responsible for upstream updates. Well,
you did it the right way, but for example, changing a shebang in one
of our scripts without discussing the change with us is *not* OK. In
general, to better coordinate upstream updates, as few contributors as
possible should do that. Normally, I do this, or Tobias Quathamer,
usually twice or three times a month. This should be enough.

Please accept our rules. Thanks for your understanding.

Best Regards,
Mario

Re: Bug#956013: Fails to install

[Mario Blättermann]

Hi David,

David Prévot  schrieb am Mo., 6. Apr. 2020, 18:51:

> Le 06/04/2020 à 02:39, Dr. Tobias Quathamer a écrit :
>
> > I think that this bug is now fixed in git. If you have the time, I'd
> > value your input if I've thought of everything before I start another
> > upload cycle.
>
> I very much doubt it is manpages-l10n task to take over
> manpages-fr-extra (especially via a transnational dummy package).
>

It *is* the task of manpages-l10n because the source tarball contains
translations which were previously maintained within manpages-fr-extra.

Well, alternatively we could disable the man pages which come from there
and keep publishing the old manpages-fr-extra package again and again, with
all the outdated stuff it contains. Doesn't make sense at all. Instead,
let's go a step ahead and switch to up-to-date man pages.

Best Regards,
Mario


Anyway, adding a manpages-fr-extra package with a version lower the one
> currently in unstable will not supersede it.
>
> Regards
>
> David
>
>

Re: git hooks for the manpages project

[Mario Blättermann]

Hello Thomas,

Thomas Vincent  schrieb am Mo., 30. März 2020, 01:06:

> Hi Mario,
>
> Following the discussion on debian-l10n-french about contributors
> pushing broken files, I quickly wrote a small git-hook to check that
> commited PO files are valid according to msgfmt.
>
> I would like to share this hook to all manpages contributors. In your
> opinion, what would be the best way to do it? I see that you created a
> CONTRIBUTING file. Would it be OK to add instructions in it to tell
> contributors how to update their hooks?
>

Would be really helpful. Anyway, the file CONTRIBUTING.md is still far from
being complete. Feel free to add additional instructions for translators.

Best Regards,
Mario

>

Re: manpages-l10n: please fix file header of xrandr.1.po

[Mario Blättermann]

Hello Jean-Philippe,

Am So., 29. März 2020 um 13:34 Uhr schrieb Jean-Philippe MENGUAL
:
>
> >>
> >> What? Sorry I dont understand.
> >>
> > Someone in your team - I thought you - maintains his own external Git
> > repo for reviews. That's why I thought the Diff artifacts come from
> > there.
>
> oh not at all. I dont have any external repo. I wonder wether
> Jean-Pierre does, but anyway he does not have the errors I created so I
> dont think it has consequences.
>
> >
> >>> really can't do without tracking changes within one single review
> >>> loop, then fork a new branch in manpages-l10n and merge the changes
> >>> back to master when finished. Or at least, be more careful please when
> >>> committing anything. Thanks in advance.
> >>
> >> Well I am "happy" to open this topic because I am not confortable with
> >> the situation just now. Here is what I experience, tell me the proper
> >> process. The origin on my problem is I dont know Git enough. Merging
> >> would be a pain for me, so ok to be careful, but then please help me
> >> with a process.
> >>
> >> So currently the situation is:
> >> - I start a page (eg. find)
> >> - the loop is long (about 1 month for such page)
> >> - before pushing, git tells me "no, please git pull first"
> >> - pull fails because between the beginning of the loop and now, find was
> >> changed (I guess an automation)
> >> - the situation becomes then completely confusing. Just like I did a few
> >> minutes ago, I have to rm the file, put my copy, add it, and push.
> >>
> >> So the problem I identify is that some changes happen while I am working
> >> on the po and I cannot identify them and handle them.
> >>
> >>
> >> What should I do then which would make sense? I feel merging will be a
> >> pain, so what care process should I use to ensure the commit is good and
> >> dont result failures and side-effects? An idea I am having: should I
> >> push any work once done, even if not reviewed in our loop? I can,
> >> indeed, push any change I do immediately and just mark the commit as
> >> definite or "WIP"? Maybe the fact to commit once the loop is finished is
> >> an error?
> >>
> >> Thanks for your help. And sorry for the mess. Git stays a pain for me
> >> but... will learn.
> >
> > I've just committed the file CONTRIBUTING.md [1]. Well, I assume it
> > doesn't cover all imagineable questions and problems, but should
> > explain most of the workflow. Please have a look at it.
>
> Thanks for this document. Some questions reading it:
> - is it OK if I consider the translators are only affected from
> "Git workflow"? I think this as I guess the first part is automatically
> performed by the package maintainers and the translator should not run
> any scripts without ensuring it is a good idea.

Yes, the »Git workflow« as described ist the core part. But you can
use any of the helper scripts in po/fr/.

> - If I understand the Git workflow, am I right if I say:
> "Update a file out of any git repo, somewhere in your local home. Then
> git pull, then cp your file, etc"
>
Yes, it's the safest way in case the review needs some time. In case
of a small change which doesn't need a review, like fixing a typo, you
can edit the file directly in the Git repo, because this ntakes only a
few minutes.

> - Before pushing, I need then to run update-po.sh right? I must not just
> cp, cehck thintegrigy with msgfmt, then push. I need first to ensure the
> push is good via the new steps you mention, all right?
>

Always run msgfmt -vc on an edited .po file to make sure it is
correct. The script update-po.sh makes additionally sure your .po file
is up-to-date (merged with the latest template) and contains all
changes which happened will you have edited the file externally. After
running the script, you should always have a look again at the file.

Best Regards,
Mario

Re: manpages-l10n: please fix file header of xrandr.1.po

[Mario Blättermann]

Hello Jean-Philippe,

Am So., 29. März 2020 um 07:41 Uhr schrieb Jean-Philippe MENGUAL
:
>
>
> Le 29/03/2020 à 00:05, Mario Blättermann a écrit :
> > Hello,
> >
> > the header of the French xrandr.1.po currently looks as follows:
> >
> > # French translation of manpages
> > # This file is distributed under the same license as the manpages-l10n 
> > package.
> > # Copyright © of this file:
> > # Common msgids
> > # Mario Blättermann , 2019.
> > msgid ""
> > msgstr ""
> > "Project-Id-Version: manpages-l10n\n"
> > "POT-Creation-Date: 2020-03-07 13:29+01:00\n"
> > "PO-Revision-Date: 2019-10-05 18:43+0200\n"
> > "Last-Translator: Mario Blättermann \n"
> > …
> >
> > Seems somebody has used one of the compendium files as a template. My
> > last commit (reformat .po files) only added the first three lines. It
>
> not me. Some automations make me fully confused. ANyway xrandr is fixed.
>
> > happened in commit #151198. While trying to update just one .po file,
> > 1000 files have been changed accidentally, and the following attempt
> > to revert this change obviously failed.
> >
> > The problem is not only that names of the involved translators are
> > missing; when regenerating the AUTHORS file, also a proper file header
> > is needed.
> >
> > As you can see in the mentioned commit, some artifacts of a formatted
> > Diff have been added to xrandr.1.po, which produces an invalid .po
> > file. But unfortunately, our helper scripts expect proper and valid
> > .po files and can destroy a file completely in some cases and later
> > regenerate from whatever; I'm not the author of the scripts and can't
> > explain them in detail.
> >
> > @Jean-Philippe, does it really make sense to maintain your own Git
> > repo and move .po files forth and back from one to another? If you
>
> What? Sorry I dont understand.
>
Someone in your team - I thought you - maintains his own external Git
repo for reviews. That's why I thought the Diff artifacts come from
there.

> > really can't do without tracking changes within one single review
> > loop, then fork a new branch in manpages-l10n and merge the changes
> > back to master when finished. Or at least, be more careful please when
> > committing anything. Thanks in advance.
>
> Well I am "happy" to open this topic because I am not confortable with
> the situation just now. Here is what I experience, tell me the proper
> process. The origin on my problem is I dont know Git enough. Merging
> would be a pain for me, so ok to be careful, but then please help me
> with a process.
>
> So currently the situation is:
> - I start a page (eg. find)
> - the loop is long (about 1 month for such page)
> - before pushing, git tells me "no, please git pull first"
> - pull fails because between the beginning of the loop and now, find was
> changed (I guess an automation)
> - the situation becomes then completely confusing. Just like I did a few
> minutes ago, I have to rm the file, put my copy, add it, and push.
>
> So the problem I identify is that some changes happen while I am working
> on the po and I cannot identify them and handle them.
>
>
> What should I do then which would make sense? I feel merging will be a
> pain, so what care process should I use to ensure the commit is good and
> dont result failures and side-effects? An idea I am having: should I
> push any work once done, even if not reviewed in our loop? I can,
> indeed, push any change I do immediately and just mark the commit as
> definite or "WIP"? Maybe the fact to commit once the loop is finished is
> an error?
>
> Thanks for your help. And sorry for the mess. Git stays a pain for me
> but... will learn.

I've just committed the file CONTRIBUTING.md [1]. Well, I assume it
doesn't cover all imagineable questions and problems, but should
explain most of the workflow. Please have a look at it.

[1] 
https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/blob/master/CONTRIBUTING.md

Best Regards,
Mario

manpages-l10n: please fix file header of xrandr.1.po

[Mario Blättermann]

Hello,

the header of the French xrandr.1.po currently looks as follows:

# French translation of manpages
# This file is distributed under the same license as the manpages-l10n package.
# Copyright © of this file:
# Common msgids
# Mario Blättermann , 2019.
msgid ""
msgstr ""
"Project-Id-Version: manpages-l10n\n"
"POT-Creation-Date: 2020-03-07 13:29+01:00\n"
"PO-Revision-Date: 2019-10-05 18:43+0200\n"
"Last-Translator: Mario Blättermann \n"
…

Seems somebody has used one of the compendium files as a template. My
last commit (reformat .po files) only added the first three lines. It
happened in commit #151198. While trying to update just one .po file,
1000 files have been changed accidentally, and the following attempt
to revert this change obviously failed.

The problem is not only that names of the involved translators are
missing; when regenerating the AUTHORS file, also a proper file header
is needed.

As you can see in the mentioned commit, some artifacts of a formatted
Diff have been added to xrandr.1.po, which produces an invalid .po
file. But unfortunately, our helper scripts expect proper and valid
.po files and can destroy a file completely in some cases and later
regenerate from whatever; I'm not the author of the scripts and can't
explain them in detail.

@Jean-Philippe, does it really make sense to maintain your own Git
repo and move .po files forth and back from one to another? If you
really can't do without tracking changes within one single review
loop, then fork a new branch in manpages-l10n and merge the changes
back to master when finished. Or at least, be more careful please when
committing anything. Thanks in advance.

Best Regards,
Mario

manpages-l10n: please review pow.3.po

[Mario Blättermann]

Hello,

the file pow.3.po in our Git repo is broken:

[mariobl@t450 man3]$ msgfmt -vc pow.3.po
pow.3.po:1:2: syntax error
pow.3.po:1: keyword "HEAD" unknown
pow.3.po:91: missing 'msgstr' section
pow.3.po:92:2: syntax error
pow.3.po:92: keyword "HEAD" unknown
pow.3.po:96: keyword "f26000c4586a0234603f2bd4b780fa9e8de690e1" unknown
pow.3.po:119:2: syntax error
pow.3.po:119: keyword "HEAD" unknown
pow.3.po:127: keyword "f26000c4586a0234603f2bd4b780fa9e8de690e1" unknown
pow.3.po:392:2: syntax error
pow.3.po:392: keyword "HEAD" unknown
pow.3.po:398: keyword "f26000c4586a0234603f2bd4b780fa9e8de690e1" unknown
pow.3.po:457:2: syntax error
pow.3.po:457: keyword "HEAD" unknown
pow.3.po:461: keyword "f26000c4586a0234603f2bd4b780fa9e8de690e1" unknown
pow.3.po:497: missing 'msgstr' section
pow.3.po:498:2: syntax error
pow.3.po:498: keyword "HEAD" unknown
pow.3.po:502: keyword "f26000c4586a0234603f2bd4b780fa9e8de690e1" unknown
pow.3.po:525:2: syntax error
msgfmt: too many errors, aborting

It contains some artifacts from a Diff. Please review the file and
remove the superfluous lines.

In general, you should run »msgfmt -vc« before committing, as I did
above. So you can make sure the Gettext syntax of that file is
correct.

Best Regards,
Mario

Re: [RFR2] po4a://manpages-fr/free/po/fr.po 29f 14u

[Mario Blättermann]

Hello Jean-Philippe,

Am Fr., 27. März 2020 um 19:39 Uhr schrieb Jean-Philippe MENGUAL
:
>
>
>
>
> Jean-Philippe MENGUAL
> Le 26/03/2020 à 19:03, Baptiste Jammet a écrit :
> > Bonjour,
> >
> > Dixit Jean-Philippe MENGUAL, le 26/03/2020 :
> >> Voici une mise à jour de page de man.
> >>
> >> Merci pour vos relectures.
> >
> > Relecture indépendante de celle de bubu.
> >
> > Baptiste
>
> Merci bien, voici le résultat de vos deux retours.
>
> Amicalement,
>
Just for information: The man page of free(1) is part of the procps
Debian package (procps-ng in most other distributions). Actually the
man page translations of procps are provided by GNU TP [1]. I had
proposed to maintain the translations there some time ago [2], but
even more than six years later, the translated man pages - although
now shipped with the latest tarball v3.3.16 - still don't appear
anywhere in a distribution package. Even the Debian package,
maintained by the procps main developer Craig Small, doesn't ship
them. See the appropriating bug reports [3][4][5][6].

How does this affect manpages-l10n? Once the distribution packages of
procps(-ng) ship the translations (hopefully soon), we will stop to
translate the appropriate man pages here:

free.1.po
pgrep.1.po
pidof.1.po
pkill.1.po
pmap.1.po
procps.1.po
ps.1.po
pwdx.1.po
slabtop.1.po
tload.1.po
top.1.po
uptime.1.po
w.1.po
watch.1.po
openproc.3.po
readproc.3.po
readproctab.3.po
sysctl.conf.5.po
sysctl.8.po
vmstat.8.po

To mention, ps.1 and top.1 are not yet part of the translation
template provided by GNU TP, so we need to keep them here a bit
longer. But one day we will get rid of the mentioned .po files,
irrevocably.

[1] http://translationproject.org/domain/procps-ng-man.html
[2] https://www.freelists.org/post/procps/Translations-for-man-pages
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953743
[4] https://bugs.archlinux.org/task/62034
[5] https://gitlab.com/procps-ng/procps/issues/157
[6] https://bugs.mageia.org/show_bug.cgi?id=26133

Best Regards,
Mario

Re: Languages in manpages-l10n

[Mario Blättermann]

Hello Jean-Philippe,

Am Sa., 29. Feb. 2020 um 22:47 Uhr schrieb Jean-Philippe MENGUAL
:
> […]
>
> >
> >>>
> >>> BTW, would it make sense to create a mailing list for the
> >>> manpages-l10n project, where we could discuss such things?
> >>
> >> I think we should use debian-i18n for this.
> >>
> > I don't think so. Although manpages-l10n resides on a Debian server,
> > it is distribution-agnostic. We support four distros, and depending on
> > the packaging efforts, it is imagineable to support some more soon.
> > Bad idea in my opinion to force the current and the possible future
> > translators to subscribe to a pure Debian mailing list with lots of
> > garbage for people who don't use Debian or one of its derivatives.
>
> Then a specific mailing list would be a good idea. But where, no idea.
>
I've no problem to subscribe to a mailing list within the Debian
ecosystem, but the general and Debian-specific i18n list would be a
bad idea; we need a new one. For possible contributors out there, it
would give the impression that manpages-l10n is a Debian project, but
it isn't.

Best Regards,
Mario

Re: Languages in manpages-l10n

[Mario Blättermann]

Hello Jean-Philippe,

Am Sa., 29. Feb. 2020 um 22:28 Uhr schrieb Jean-Philippe MENGUAL
:
>
>
>
> Jean-Philippe MENGUAL
> Le 29/02/2020 à 20:12, Mario Blättermann a écrit :
> > Hello Jean-Philippe,
> >
> > Am Sa., 29. Feb. 2020 um 17:46 Uhr schrieb Jean-Philippe MENGUAL
> > :
> >> […]
> >> ok. This is clear. So in the description of the package, I suggest
> >> Tobian to mention this: the package contains the up-to-date manpages in
> >> their respective languages. It replaces manpages-fr, de, etc; the
> >> languages not replaced are probably deprecated.
> >
> > … and out of date.
> >
> >> Thus it is clear for the end-user. And maybe someone will want to ship
> >> his language manpages in manpages-l10n?
> >>
> >
> > Yes, maybe… But the current state of the other manpages-* project is
> > the worst possible starting point for new teams: All, or at least
> > almost all translations are terribly outdated. The plain text files
> > are from the pre-po4a period and need to be imported into *.po files
> > first. Well, it is not impossible, but is a lot of work, though. I did
> > it already for the current Dutch translations. First, one need to
> > determine which original man page version the translation is based on
> > - and if the translators don't have mentioned a version number at that
> > time, you can only guess… Then, after merging with the latest
> > translation templates, in many cases almost nothing from the imported
> > stuff remains. This is not very attractive for both newbies and
> > experienced translators.
> >
> > Anyway, if someone is willing to contact the various translation teams
> > (not only the Debian translators), I would support it with my
> > experience in importing plain text files. Besides the known manpages-*
> > packages from Debian, there are two other abandoned man page
> > translation projects, for Danish and Finnish, see [1].
>
> Ok so useless to do such efforts. However perhaps we could try to make
> the manpages-l10n birth a public news (Debian project news, micronews).
> It may some persons react?
>
Maybe…

> >
> > BTW, would it make sense to create a mailing list for the
> > manpages-l10n project, where we could discuss such things?
>
> I think we should use debian-i18n for this.
>
I don't think so. Although manpages-l10n resides on a Debian server,
it is distribution-agnostic. We support four distros, and depending on
the packaging efforts, it is imagineable to support some more soon.
Bad idea in my opinion to force the current and the possible future
translators to subscribe to a pure Debian mailing list with lots of
garbage for people who don't use Debian or one of its derivatives.

Best Regards,
Mario

Re: Languages in manpages-l10n

[Mario Blättermann]

Hello Jean-Philippe,

Am Sa., 29. Feb. 2020 um 17:46 Uhr schrieb Jean-Philippe MENGUAL
:
> […]
> ok. This is clear. So in the description of the package, I suggest
> Tobian to mention this: the package contains the up-to-date manpages in
> their respective languages. It replaces manpages-fr, de, etc; the
> languages not replaced are probably deprecated.

… and out of date.

> Thus it is clear for the end-user. And maybe someone will want to ship
> his language manpages in manpages-l10n?
>

Yes, maybe… But the current state of the other manpages-* project is
the worst possible starting point for new teams: All, or at least
almost all translations are terribly outdated. The plain text files
are from the pre-po4a period and need to be imported into *.po files
first. Well, it is not impossible, but is a lot of work, though. I did
it already for the current Dutch translations. First, one need to
determine which original man page version the translation is based on
- and if the translators don't have mentioned a version number at that
time, you can only guess… Then, after merging with the latest
translation templates, in many cases almost nothing from the imported
stuff remains. This is not very attractive for both newbies and
experienced translators.

Anyway, if someone is willing to contact the various translation teams
(not only the Debian translators), I would support it with my
experience in importing plain text files. Besides the known manpages-*
packages from Debian, there are two other abandoned man page
translation projects, for Danish and Finnish, see [1].

BTW, would it make sense to create a mailing list for the
manpages-l10n project, where we could discuss such things?

[1] https://www.win.tue.nl/~aeb/linux/man/index.html

Best Regards,
Mario

Languages in manpages-l10n

[Mario Blättermann]

Hello,

recently someone of you asked me about the languages in manpages-l10n,
but I can't find the mail back... Nevertheless, here's some
explanations about:

The current manpages-l10n has been merged originally from manpages-de,
manpages-fr and manpages-fr-extra. Some time later I've imported some
old plain text translations from Polish and (abandoned) Romanian and
Dutch translation projects. Finally, a Brazilian Portuguese translator
wrote to me and asked for addition of a framework for his language. So
we support now six languages, while Dutch is currently unmaintained.

Let's have a look at other manpages-* projects (someone of you had
asked for Italian...): Most of the projects don't exist anymore. The
tarballs which Debian uses for the packages are mostly more than 10,
even 20 years old. But as long as no one is willing to reanimate a
certain language and update the translations with our latest
templates, we can't do anything. Regarding Italian, I've written to
the ILDP mailing list and got an answer (can't link to the mail, the
list archive hasn't been updated anymore since april 2019):

 Am Sa., 4. Jan. 2020 um 13:28 Uhr schrieb Silvano Sallese
:
>
> Hi Mario,
>
> Thank you to contact us and for your interest.
>
> The last translated Italian version of the man pages is 4.16, but not yet 
> published on the PLUTO servers.
>
> Let us check the changes you are talking about in your email.
>
> Thank you again.
>
> Saluti,
>
> Silvano
>
> Il sab 4 gen 2020, 10:46 Mario Blättermann  ha 
> scritto:
>>
>> Hello,
>>
>> having a look at the current state of manpages-it, it seems that the
>> project has been abandoned. I don't recognize any activity since 2016,
>> and even the latest release 4.08 hasn't been packaged for any
>> distribution.
>>
>> Regarding the translated man pages itself, the texts are not
>> up-to-date in most cases. Of course, it is quite difficult to update
>> such textual translations. Using po4a [1] makes it much easier through
>> using normal po files in a gettext based workflow.
>>
>> Recently we (the developers of manpages-de) have merged the existing
>> German and French translations into a new project named manpages-l10n
>> [2]. After that, we have added Polish po files and imported some old
>> Dutch and Romanian translations. What about to also add the Italian
>> manpages there…?
>>
>> The workflow of manpages-l10n is as follows:
>>
>> Currently we support four distributions, Archlinux, Mageia Cauldron,
>> Debian Sid and Debian Buster (the latter will probably be replaced
>> with Debian Bullseye soon). We download packages according to our
>> lists in upstream/*/packages.txt. The manpages will be extracted from
>> the packages and po4a generates translation templates. The templates
>> will be merged with the existing po files. Because this usually
>> happens once or twice a month, the po files are almost in sync with
>> the original manpages from the distribution packages. After this, the
>> po files can be updated by the translators, and we roll out a new
>> release usually four or five times a year.
>>
>> To limit the effort, we maintain some helper scripts and a compendium
>> for each language. The scripts can create new po files and fill them
>> with common strings from the compendium, format the po files and
>> remove some artifacts from older upstream versions, write changes from
>> a recently proofread po file to the compendium and write the changes
>> back to the other files, generate an addendum with the translator
>> names and license informations, and much more.
>>
>> Have a look at the attachment. The tarball contains eight imported po
>> files, one for each manpage section. In »original« you see the
>> imported files as written from the last translator, and in »updated«
>> you see what you get after merging with the latest template. As far it
>> is was possible without speaking Italian, I have fixed some things,
>> like trivial formatting changes or some strings which appear in po
>> files but actually can be copied directly and don't have to be
>> translated.
>>
>> Maybe you are wondering how it was possible to import all the texts
>> without speaking Italian at all: The existing textual translations
>> contain hints about the original text which translation it has been
>> derived from. So it was quite easy to download the appropriate package
>> (for example, manpages-3.53.tar.xz), unpack the manpages and create a
>> temporary translation template with po4a. As I already did with the
>> first eight files, I would do this for all existing files, so you
>> don't have to bothe

Re: [RFR] po4a://manpages-fr/echo/po/fr.po 5f

[Mario Blättermann]

Hello,

Am Di., 25. Feb. 2020 um 10:48 Uhr schrieb JP Guillonneau
:
>
> Bonjour,
>
> la ligne :
>
> #: archlinux debian-buster debian-unstable mageia-cauldron
> indique apparemment dans quelles distributions les lignes qui suivent
> s’appliquent. Par exemple pour dmesg, l’option :
>
> #: archlinux mageia-cauldron
> #, no-wrap
> msgid "B<--noescape>"
> msgstr "B<--noescape>"
>
> n’apparait pas dans la construction de la page.
>
> Supprimer les doubles contre-obliques pourrait
> peut-être avoir une conséquence sur l’affichage dans d’autres distributions 
> que
> Debian ?

The various supported distributions don't affect each other. As you
can see above the message, it appears only in Archlinux and Mageia
Cauldron. As a general rule, all formattings of the original message
should appear in the translation as they are. In doubt, you can always
run generate-manpages.sh to see whether your translation produces the
correct formatting.

Best Regards,
Mario

Re: [LCFC] po4a://manpages-l10n/po/fr/common/min-010-occurences.po 9f 116u

[Mario Blättermann]

Hello Grégoire,

Am Mo., 24. Feb. 2020 um 10:35 Uhr schrieb Grégoire Scano
:
>
> Hello Mario,
>
> thanks for the explanation on this, it is much clearer now.
>
> I have integrated the changes for min-100-occurences in a branch [1] of
> my personal copy of the repo and would like to know if you agree with
> the following flow before pushing it to the public repo:
>
> [1] https://salsa.debian.org/gscano-guest/manpages-l10n/tree/tmp
>
> 1) update the common/* files since you made some changes to them as you
> warned us before;
> 2) apply use-for-compendium for files pushed by Jean-Philippe,
> Jean-Pierre and any other translator, so that I would spot differences
> and rule between conflicts based on the fact that the compendium would
> precede the translation itself for homogeneity purposes;
> 3) merge with my branch of translated and proofread min-100-occurences,
> and resolve conflicts here if any;
> 4) apply update-translations;
>
> and proceed as such for the rest of the occurences files that have been
> translated, integrating updated translations into the common files
> first before apply them to the entire tree.
>

Because you've already edited the common files directly, you should
commit the changed files first. Then, run use-for-compendium for
already pushed files, and finally commit and push all. If you would
run use-for-compendium first, it could happen that the changes
partially get overwritten by committing the changed common files.

Some additional note about the compendium: In some cases it could
happen that gettext messages are somewhat ambiguous. This means, they
cannot be added to the compendium because it would produce a unique
translation although the gettext message has different meanings in
different *.po files. in such cases, add the message to the file
templates/exclude.pot (with an empty »msgstrg ""«. Next time the
compendium files get updated, this message will disappear from all
compendium files in all languages.

Best Regards,
Mario

Re: Bug#952112: manpages-fr-extra: Typos in xrandr french manpage

[Mario Blättermann]

Hello Baptiste,

Baptiste Jammet  schrieb am Mi., 26. Feb. 2020,
19:54:

> Hi,
>
> Dixit Mario Blättermann, le 25/02/2020 :
>
> >> D'autres questions techniques :
> >> - est ce que le nouveau paquet sera identifié « replace:
> >>   manpages-fr{,-extra} » ?
> >> - il faudra penser à faire supprimer les paquets
> >> manpages-fr{,-extra}, ou les remplacer par des factices qui
> >> dépendent du nouveau paquet ?
> >
> >Indeed, the upcoming v4.0 of manpages-l10n will replace manpages-fr,
> >manpages-fr-dev and manpages-fr-extra (and moreover:  manpages-de,
> >manpages-de-dev, manpages-pl and manpages-pl-dev).
> >
> >I don't know how this will be handled regarding Debian's packaging and
> >upgrading policies - I'm using Archlinux. But I'm quite sure the new
> >manpages-fr will provide manpages-fr-extra virtually, because we don't
> >distinguish anymore between "normal" and somewhat "extra" man pages.
> >CC'ing Tobias Quathamer, he is the maintainer of the current
> >manpages-de package; maybe he can better explain the upgrade process.
>
> (Keeping Tobias in Cc)
> I think the new manpages-l10n-fr should have something like
> replace: manpages-fr, manpages-fr-extra, manpages-fr-dev
> (or maybe provide: ?)
> Then, maybe a new upload of these 3 olds to change them as leaf
> packages depending on manpages-l10n-fr ?
>
> Moreover, it could then be added as depends in task-l10n-fr (to be
> automatically installed in new install).
>

I don't know what Tobias plans for the packaging. But I assume there won't
be any binary packages named manpages-l10n-*. The easiest way to get a
proper upgrade path and to avoid confusing the users would be to split the
source package manpages-l10n into binary packages named manpages-de,
manpages-fr, manpages-pl and so on. Generally I would recommend this way of
packaging, also for other distributions.

And moreover, in that case nothing needs to be changed regarding the
task-l10n-fr dependency, because manpages-fr still exist as such; only
manpages-fr-extra should then appear as a "provides" of manpages-fr.

Best Regards,
Mario

>

Re: Fw: Bug#952112: manpages-fr-extra: Typos in xrandr french manpage

[Mario Blättermann]

Hello Baptiste,

Baptiste Jammet  schrieb am Di., 25. Feb. 2020,
21:12:

> [...]
>
> D'autres questions techniques :
> - est ce que le nouveau paquet sera identifié « replace:
>   manpages-fr{,-extra} » ?
> - il faudra penser à faire supprimer les paquets manpages-fr{,-extra},
>   ou les remplacer par des factices qui dépendent du nouveau paquet ?
>

Indeed, the upcoming v4.0 of manpages-l10n will replace manpages-fr,
manpages-fr-dev and manpages-fr-extra (and moreover:  manpages-de,
manpages-de-dev, manpages-pl and manpages-pl-dev).

I don't know how this will be handled regarding Debian's packaging and
upgrading policies - I'm using Archlinux. But I'm quite sure the new
manpages-fr will provide manpages-fr-extra virtually, because we don't
distinguish anymore between "normal" and somewhat "extra" man pages. CC'ing
Tobias Quathamer, he is the maintainer of the current manpages-de package;
maybe he can better explain the upgrade process.

Best Regards,
Mario

>

Re: [DONE] po4a://manpages-fr/catchsegv/po/fr.po 1f

[Mario Blättermann]

Am So., 23. Feb. 2020 um 20:21 Uhr schrieb Mario Blättermann
:
>
> HelloJean-Philippe,
>
> Am So., 23. Feb. 2020 um 15:21 Uhr schrieb Jean-Philippe MENGUAL
> :
> >
> >
> >
> >
> > Jean-Philippe MENGUAL
> > Le 16/02/2020 à 01:50, Jean-Philippe MENGUAL a écrit :
> > >
> > >
> > >
> > > Jean-Philippe MENGUAL
> > > Le 16/02/2020 à 01:06, Jean-Pierre Giraud a écrit :
> > >> Bonjour,
> > >>
> > >> Le 15/02/2020 à 10:01, Jean-Philippe MENGUAL a écrit :
> > >>>
> > >>>
> > >>>
> > >>> Jean-Philippe MENGUAL
> > >>> Le 15/02/2020 à 09:40, JP Guillonneau a écrit :
> > >>>> Bonjour,
> > >>>>
> > >>>> suggestions.
> > >>>>
> > >>>> Amicalement.
> > >>>>
> > >>>> --
> > >>>> Jean-Paul
> > >>>
> > >>> Merci. Voilà la version actualisée.
> > >>>
> > >>> Amicalement,
> > >> Juste  une suppression d'un fuzzy qui restait et une remise à 80
> > >> caractère d'un paragraphe.
> > >> Amicalement,
> > >> jipege
> > >
> > > Merci, voici.
> >
> > En ligne.
>
> I don't see any commit which changes man1/catchsegv.1.po. Well, after
> »git push« failed because your local Git copy wasn't up-to-date, you
> called »git pull« to merge the changes. But then you have to run »git
> push« again to push your changes really.
>

Sorry, I haven't seen that your local commits were already some days
ago and appear as such in the Git repo.

Best Regards,
Mario

Re: [DONE] po4a://manpages-fr/catchsegv/po/fr.po 1f

[Mario Blättermann]

HelloJean-Philippe,

Am So., 23. Feb. 2020 um 15:21 Uhr schrieb Jean-Philippe MENGUAL
:
>
>
>
>
> Jean-Philippe MENGUAL
> Le 16/02/2020 à 01:50, Jean-Philippe MENGUAL a écrit :
> >
> >
> >
> > Jean-Philippe MENGUAL
> > Le 16/02/2020 à 01:06, Jean-Pierre Giraud a écrit :
> >> Bonjour,
> >>
> >> Le 15/02/2020 à 10:01, Jean-Philippe MENGUAL a écrit :
> >>>
> >>>
> >>>
> >>> Jean-Philippe MENGUAL
> >>> Le 15/02/2020 à 09:40, JP Guillonneau a écrit :
>  Bonjour,
> 
>  suggestions.
> 
>  Amicalement.
> 
>  --
>  Jean-Paul
> >>>
> >>> Merci. Voilà la version actualisée.
> >>>
> >>> Amicalement,
> >> Juste  une suppression d'un fuzzy qui restait et une remise à 80
> >> caractère d'un paragraphe.
> >> Amicalement,
> >> jipege
> >
> > Merci, voici.
>
> En ligne.

I don't see any commit which changes man1/catchsegv.1.po. Well, after
»git push« failed because your local Git copy wasn't up-to-date, you
called »git pull« to merge the changes. But then you have to run »git
push« again to push your changes really.

Best Regards,
Mario

Re: Next release of manpages-l10n

[Mario Blättermann]

Hello Jean-Philippe,

Jean-Philippe MENGUAL  schrieb am Fr., 14. Feb. 2020,
00:02:

> Hi,
>
> Le 11/02/2020 à 02:48, Mario Blättermann a écrit :
> > Hello Jean-Philippe,
> >
> > Jean-Philippe MENGUAL  > <mailto:jpmeng...@debian.org>> schrieb am Di., 11. Feb. 2020, 01:15:
> >
> > Hi,
> >
> > Great news, congrats! I am happy to see this package alive.
> >
> > Who can push in the fr subdir of the tree? Can we add people
> manually,
> > even if not DDs? Some of the most important French translators are
> not
> > DDs, but would make sense they can push the translations to fr.
> >
> >
> > No problem, people without a DD account can simply create a guest
> > developer account at [1] and then apply for membership at [2]. All
> > project members registered as "maintainer" (you too) are then allowed to
> > accept the new translators.
>
> Ok perfect, the relevant persons were added.
>

Are you sure you did it right...? I don't see any new members in
manpages-l10n.

Best Regards,
Mario



> >
> > But note: Never commit anything outside of your own directory (po/fr/ in
> > your case) without discussing the change with us, unless our scripts
> > change something in templates/ or wherever else. Another exception are
> > the localized files in public/ (which feed the status pages), if you
> > found some wrong translation there.
>
> ok no problem, I will follow what the French team will say from their
> experience and in case of doubt, will ask here
>
> Sincerely
>
> >
> > [1] https://signup.salsa.debian.org/ <https://signup.salsa.debian.org/>
> > [2] https://salsa.debian.org/manpages-l10n-team/manpages-l10n
> > <https://salsa.debian.org/manpages-l10n-team/manpages-l10n>
> >
> > Best Regards,
> > Mario
> >
> >
> >
> > Regards
> >
> >
> >
> > Jean-Philippe MENGUAL
> >
> > Le 10/02/2020 à 10:10, Mario Blättermann a écrit :
> >  > Hello,
> >  >
> >  > the manpages-l10n project is now almost ready for a release. The
> new
> >  > version 4.0 is scheduled for march 1, 2020. All commits prior to
> this
> >  > date will be included in the tarball.
> >  >
> >  > This means, you should now complete all the work you are already
> >  > started with. In the meantime, we will update the translation
> >  > templates and the existing *.po files as usual. Due to some
> version
> >  > changes in our supported packages, such updates can happen more
> often
> >  > than expected. For example, the original »manpages« package has
> been
> >  > recently updated to v5.05. Once the distribution packages have
> been
> >  > arrived, we will do an extra update. Please always work on the
> latest
> >  > *.po files from the Git repository, sorry for the inconvenience.
> >  > Because we support lots of distribution packages whose updates we
> >  > can't influence, we are unable to declare a »string freeze« in
> common
> >  > sense.
> >  >
> >  > In case of the *.po file you are working on is older than the
> latest
> >  > template from the Git repository, you can easily update it as
> follows
> >  > (regardless of it's really older):
> >  >
> >  > Copy your *.po file to the right place in your local copy of the
> Git
> >  > repo. Committing is not needed for the time being.
> >  >
> >  > Run the following script in the po/ directory of your language:
> >  >
> >  > ./update-po.sh relative/path/to/your/po/file
> >  >
> >  > For example:
> >  >
> >  > ./update-po.sh man1/chroot.1.po
> >  >
> >  > The script merges your *.po file with both the latest template
> (*.pot
> >  > file) and the compendium files (common/*.po). Besides that, it
> > removes
> >  > unused gettext messages at the end of the file and deletes old
> msgid
> >  > comments (starting with #|), as long as the appropriate gettext
> >  > message is no longer marked as »fuzzy«.
> >  >
> >  > Happy translating!
> >  >
> >  > Best Regards,
> >  > Mario
> >  >
> >
>
>

Re: [RFR3] po4a://manpages-l10n/po/fr/common/min-100-occurences.po 1f 7u

[Mario Blättermann]

Hello,

Grégoire Scano  schrieb am Do., 13. Feb. 2020,
09:47:

> Bonjour,
>
> On 2/12/20 9:16 PM, Jean-Pierre Giraud wrote:
> > Le 12/02/2020 à 10:44, Grégoire Scano a écrit :
> >> On 2/12/20 12:09 AM, Baptiste Jammet wrote:
> >>> Dixit Grégoire Scano, le 11/02/2020 :
>  Merci d'avance pour vos relectures,
> >>>
> >>> « Signaler toute erreur de traduction à
> >>>   Ehttps://translationproject.org/ »
> >>> Si c'est ici que l'on traduit, je pense qu'il faut remplacer l'adresse
> >>> par debian-l10n-french@lists.debian.org.
> >>
>

This gettext message refers to the UI translation, which is maintained at
GNU TP. Regarding the man page translation, the script generate-manpage.sh
creates a hint about where to report bugs about the man page translation
(using generate-addendum.sh and license.add).

Best Regards,
Mario

>

Re: Next release of manpages-l10n

[Mario Blättermann]

Hello Jean-Philippe,

Jean-Philippe MENGUAL  schrieb am Di., 11. Feb. 2020,
01:15:

> Hi,
>
> Great news, congrats! I am happy to see this package alive.
>
> Who can push in the fr subdir of the tree? Can we add people manually,
> even if not DDs? Some of the most important French translators are not
> DDs, but would make sense they can push the translations to fr.
>

No problem, people without a DD account can simply create a guest developer
account at [1] and then apply for membership at [2]. All project members
registered as "maintainer" (you too) are then allowed to accept the new
translators.

But note: Never commit anything outside of your own directory (po/fr/ in
your case) without discussing the change with us, unless our scripts change
something in templates/ or wherever else. Another exception are the
localized files in public/ (which feed the status pages), if you found some
wrong translation there.

[1] https://signup.salsa.debian.org/
[2] https://salsa.debian.org/manpages-l10n-team/manpages-l10n

Best Regards,
Mario



> Regards
>
>
>
> Jean-Philippe MENGUAL
>
> Le 10/02/2020 à 10:10, Mario Blättermann a écrit :
> > Hello,
> >
> > the manpages-l10n project is now almost ready for a release. The new
> > version 4.0 is scheduled for march 1, 2020. All commits prior to this
> > date will be included in the tarball.
> >
> > This means, you should now complete all the work you are already
> > started with. In the meantime, we will update the translation
> > templates and the existing *.po files as usual. Due to some version
> > changes in our supported packages, such updates can happen more often
> > than expected. For example, the original »manpages« package has been
> > recently updated to v5.05. Once the distribution packages have been
> > arrived, we will do an extra update. Please always work on the latest
> > *.po files from the Git repository, sorry for the inconvenience.
> > Because we support lots of distribution packages whose updates we
> > can't influence, we are unable to declare a »string freeze« in common
> > sense.
> >
> > In case of the *.po file you are working on is older than the latest
> > template from the Git repository, you can easily update it as follows
> > (regardless of it's really older):
> >
> > Copy your *.po file to the right place in your local copy of the Git
> > repo. Committing is not needed for the time being.
> >
> > Run the following script in the po/ directory of your language:
> >
> > ./update-po.sh relative/path/to/your/po/file
> >
> > For example:
> >
> > ./update-po.sh man1/chroot.1.po
> >
> > The script merges your *.po file with both the latest template (*.pot
> > file) and the compendium files (common/*.po). Besides that, it removes
> > unused gettext messages at the end of the file and deletes old msgid
> > comments (starting with #|), as long as the appropriate gettext
> > message is no longer marked as »fuzzy«.
> >
> > Happy translating!
> >
> > Best Regards,
> > Mario
> >
>
>

Next release of manpages-l10n

[Mario Blättermann]

Hello,

the manpages-l10n project is now almost ready for a release. The new
version 4.0 is scheduled for march 1, 2020. All commits prior to this
date will be included in the tarball.

This means, you should now complete all the work you are already
started with. In the meantime, we will update the translation
templates and the existing *.po files as usual. Due to some version
changes in our supported packages, such updates can happen more often
than expected. For example, the original »manpages« package has been
recently updated to v5.05. Once the distribution packages have been
arrived, we will do an extra update. Please always work on the latest
*.po files from the Git repository, sorry for the inconvenience.
Because we support lots of distribution packages whose updates we
can't influence, we are unable to declare a »string freeze« in common
sense.

In case of the *.po file you are working on is older than the latest
template from the Git repository, you can easily update it as follows
(regardless of it's really older):

Copy your *.po file to the right place in your local copy of the Git
repo. Committing is not needed for the time being.

Run the following script in the po/ directory of your language:

./update-po.sh relative/path/to/your/po/file

For example:

./update-po.sh man1/chroot.1.po

The script merges your *.po file with both the latest template (*.pot
file) and the compendium files (common/*.po). Besides that, it removes
unused gettext messages at the end of the file and deletes old msgid
comments (starting with #|), as long as the appropriate gettext
message is no longer marked as »fuzzy«.

Happy translating!

Best Regards,
Mario

Re: Status of manpages-fr -- help needed?

[Mario Blättermann]

Am So., 6. Okt. 2019 um 14:02 Uhr schrieb Jean-Philippe MENGUAL
:
>
>
> Le 06/10/2019 à 13:46, Mario Blättermann a écrit :
> > Hello Jean-Philippe,
> > […]
> > While copying the strings into the script and testing, I found some
> > more translatable parts. Updated po file is attached.
>
> Forgotten it seems :)
>
OK, now with attachment.

Best Regards,
Mario
# French translation of the manpages-l10n scripts
# Copyright © of this file:
# This file is distributed under the same license as the manpages-l10n package.
# Jean-Philippe Mengual , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: manpages-l10n\n"
"POT-Creation-Date: 2019-10-06 13:39+02:00\n"
"PO-Revision-Date: 2019-10-06 12:41+0200\n"
"Last-Translator: Jean-Philippe Mengual \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 1.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. TRANSLATORS: %s is the timestamp of the status page.
#: public/generate-stats-page.sh:47
msgid "Time: %s"
msgstr ""

#. TRANSLATORS: Replace »English« with the name of your language. This line
#. becomes the first header line in *.po files.
#: po/create-new-translation.sh:50
msgid "# English translation of manpages"
msgstr "# Traduction en français des pages de manuel"

#. TRANSLATORS: Replace »LANGUAGE« with the name of your language and add the
#. address of the language team which is responsible for comments, proposals,
#. bug reports etc. 
#: po/create-new-translation.sh:59
msgid "Language-Team: LANGUAGE "
msgstr "French "

#. TRANSLATORS: Replace »English« with the name of your language.
#. %d will be substituted by the translator name and his/her mail address.
#: po/generate-addendum.sh:42
msgid "The English translation of this man page has been created by %d."
msgstr "La traduction française de cette page de manuel a été créée par %d."

#. TRANSLATORS: Replace »English« with the name of your language.
#. %d and %s will be substituted by the translator names and his/her mail
#. addresses. This will be applied in case of two translators. 
#: po/generate-addendum.sh:43
msgid "The English translation of this man page has been created by %d and %s."
msgstr ""
"La traduction française de cette page de manuel a été créée par %d et %s."

#. TRANSLATORS: Replace »English« with the name of your language.
#. %d and %s will be substituted by the translator names and his/her mail
#. addresses. This will be applied in case of three or more translators. 
#: po/generate-addendum.sh:43
msgid ""
"The English translation of this man page has been created by %d, %s and %z."
msgstr ""
"La traduction française de cette page de manuel a été créée par %d, %s et %z."

#. TRANSLATORS: %s is the timestamp of the status page.
#: public/generate-stats-page.sh:95
msgid "Overview"
msgstr ""

#: public/generate-stats-page.sh:98
msgid "View Git Repository"
msgstr ""

#: public/generate-stats-page.sh:151
msgid "Name"
msgstr ""

#: public/generate-stats-page.sh:152
msgid "Percentage"
msgstr ""

#: public/generate-stats-page.sh:153
msgid "Translations until 80%"
msgstr ""

#: public/generate-stats-page.sh:154
msgid "Statistics"
msgstr ""

#. TRANSLATORS: This is the section title for an addendum, which will be added
#. to each translated man page.
#: license.add:1
msgid "TRANSLATION"
msgstr "TRADUCTION"

#. TRANSLATORS: This disclaimer is the license declaration, added to each
#. translated man page. Make sure you use the correct mail address of the team
#. which is responsible for bug reports.
#: license.add:2
msgid ""
"This translation is free documentation; please refer to the GNU General "
"Public License version 3 or later regarding the conditions for copying and "
"distribution. There is no LEGAL RESPONSIBILITY.\n"
"\n"
"If you find a bug in the translation of this manual page, please write to "
"."
msgstr ""
"Cette traduction est une documentation libre ; veuillez vous reporter à la "
"GNU General Public License version 3 concernant les conditions de copie et "
"de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.\n"
"\n"
"Si vous découvrez un bogue dans la traduction de cette page de manuel, "
"veuillez envoyer un message à ."

#. TRANSLATORS: Replace »English« with the name of your language.
#. This is the header line of the status pages.
#: public/generate-stats-page.sh:

Re: Status of manpages-fr -- help needed?

[Mario Blättermann]

Hello Jean-Philippe,

Am So., 6. Okt. 2019 um 13:35 Uhr schrieb Jean-Philippe MENGUAL
:
>
> Hi,
>
> Thanks Jean-Pierre for the review. Mario, here is the definitive version
> of the translation.
>
While copying the strings into the script and testing, I found some
more translatable parts. Updated po file is attached.

After checking out our Git repo, you can test the creation of the
status pages by running the script public/generate-stats-page-fr.sh.
Please have a look at this and tell me about any mistakes or
peculiarities.

There is a mistake in one of the translated strings:

#. TRANSLATORS:  %s expands to a number.
#: public/generate-stats-page.sh:164
msgid "%s file is incompletely translated"
msgid_plural "%s files are incompletely translated"
msgstr[0] "%s fichiers ne sont pas complètement traduits"
msgstr[1] "%s fichier n'est pas complètement traduit"

Singular and plural forms are swapped.

Best Regards,
Mario

Re: Status of manpages-fr -- help needed?

[Mario Blättermann]

Hello Jean-Philippe,

> […]
> I attach a gzip file to avoid the charset problems
>
> Regards

One of the translations is incomplete:

#. TRANSLATORS: This disclaimer is the license declaration, added to each
#. translated man page. Make sure you use the correct mail address of the team
#. which is responsible for bug reports.
#: license.add:2
msgid ""
"This translation is free documentation; please refer to the GNU General "
"Public License version 3 or later regarding the conditions for copying and "
"distribution. There is no LEGAL RESPONSIBILITY.\n"
"\n"
"If you find a bug in the translation of this manual page, please write to "
"."
msgstr ""
"Cette traduction est une documentation libre ; veuillez vous reporter à la "
"GNU General Public License version 3 concernant les conditions de copie et "
"de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE."

I'm missing the last sentence (If you find a bug…)

Best Regards,
Mario

Re: Status of manpages-fr -- help needed?

[Mario Blättermann]

Hello Jean-Philippe,

Am So., 6. Okt. 2019 um 11:36 Uhr schrieb Jean-Philippe MENGUAL
:
>
> >>>
> >>> Now we have 1385 po files, but 560 of them cannot be built to
> >>> translated man pages because they don't reach the 80% threshold of
> >>> Po4a. I've done all I could do, now it is up to real French
> >>> translators to update the po files accordingly.
> >>
> >> Thanks, that is great! I requested to join manpages-l10n-team in case I
> >> can help
> >
> > Thanks for the quick response! Please translate the attached
> > scripts.pot first. It is needed to generate a proper addendum and
> > status pages. Currently, the French status pages are not yet available
>
> hmmm I am not an expert of the tools, but should I translate the .pot
> directly? Usually I translate po files, then the pot generation is done
> via gettext (makefile or whatever). Is it a particular case where I
> should translate the pot directly, or some additional steps to translate
> a po file then regenerate the pot?
>
Don't bother with that. I've generated the *.pot file manually, it is
not based a Gettext workflow. But I think it is the easiest way to get
the translated parts of the scripts, because translators are familiar
with such files. Find a stub French *.po file in the attachment.
>
> > online. Run the script public/generate-stats-page-fr.sh to get the
> > HTML files locally (in »public«) and view them in your favorite
> > browser.
> >
> > The translation workflow is as follows: Pick a .po file, write an
> > [ITT] mail to the list, then update the translation, send it with
> > [RFR], and once the review is done, send a [DONE] and attach the
> > reviewed po file. I'm subscribed to this list, and when encountering
> > such a [DONE] mail, I will commit this file and add their contents to
> > the compendium. Ideally, the subject line of the mail should follow
> > this scheme:
> >
> > […] man://manpages-l10n/fr/manpage.1.po
> >
> > This makes sure that it can be parsed properly by the robot and it is
> > easier to filter out [DONE] mails which are not relevant for me.
> > Regarding write access to the Git repo, it is up to Tobias as the
> > owner of the repo to grant access.
>
> Should I follow this workflow for the script? I understand that no, I
> should send it to you, but I prefer to ask confirmation

No, not for this script, but later any *.po file submission for man
pages should follow this workflow.

Best Regards,
Mario
# French translation of the manpages-l10n scripts
# Copyright © of this file:
# This file is distributed under the same license as the manpages-l10n package.
# Jean-Philippe Mengual , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: manpages-l10n\n"
"POT-Creation-Date: 2019-10-03 11:56+02:00\n"
"PO-Revision-Date: 2019-10-06 11:55+0200\n"
"Last-Translator: Jean-Philippe Mengual \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 1.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. TRANSLATORS: Replace »English« with the name of your language. This line
#. becomes the first header line in *.po files.
#: po/create-new-translation.sh:50
msgid "# English translation of manpages"
msgstr ""

#. TRANSLATORS: Replace »LANGUAGE« with the name of your language and add the
#. address of the language team which is responsible for comments, proposals,
#. bug reports etc.
#: po/create-new-translation.sh:59
msgid "Language-Team: LANGUAGE "
msgstr ""

#. TRANSLATORS: Replace »English« with the name of your language.
#. %d will be substituted by the translator name and his/her mail address.
#: po/generate-addendum.sh:42
msgid "The English translation of this man page has been created by %d."
msgstr ""

#. TRANSLATORS: Replace »English« with the name of your language.
#. %d and %s will be substituted by the translator names and his/her mail
#. addresses. This will be applied in case of two translators.
#: po/generate-addendum.sh:43
msgid "The English translation of this man page has been created by %d and %s."
msgstr ""

#. TRANSLATORS: Replace »English« with the name of your language.
#. %d and %s will be substituted by the translator names and his/her mail
#. addresses. This will be applied in case of three or more translators.
#: po/generate-addendum.sh:43
msgid ""
"The English translation of this man page has been created by %d, %s and %z."
msgstr ""

#. TRANSLATORS: This is the section title for an addendum, which will be added
#. to each translated man page.
#: license.add:1
msgid "TRANSLATION"
msgstr ""

#. TRANSLATORS: This disclaimer is the license declaration, added to each
#. translated man page. Make sure you use the correct mail address of the team
#. which is responsible for bug reports.
#: license.add:2
msgid ""
"This translation is free documentation; please refer to the GNU General "
"Public License version 3 or later regarding the conditions for copying and "
"distribution. There is no LEGAL 

Re: Status of manpages-fr -- help needed?

[Mario Blättermann]

Hello Jean-Philippe,

Am Sa., 5. Okt. 2019 um 23:42 Uhr schrieb Jean-Philippe MENGUAL
:
>
>
>
> > Now the import of the French man pages has been finished and a new
> > project has been created:
> >
> > https://salsa.debian.org/manpages-l10n-team/manpages-l10n
> >
> > The French po files are in po/fr/. The original files from manpages-fr
> > and mapages-fr-extra have been merged into one pool. After the import,
> > I've created the compendium files in po/fr/common/, filled them with
> > translations (as far it was possible for a non-French speaker) and
> > synchronized the compendium with the po files.
> >
> > Now we have 1385 po files, but 560 of them cannot be built to
> > translated man pages because they don't reach the 80% threshold of
> > Po4a. I've done all I could do, now it is up to real French
> > translators to update the po files accordingly.
>
> Thanks, that is great! I requested to join manpages-l10n-team in case I
> can help

Thanks for the quick response! Please translate the attached
scripts.pot first. It is needed to generate a proper addendum and
status pages. Currently, the French status pages are not yet available
online. Run the script public/generate-stats-page-fr.sh to get the
HTML files locally (in »public«) and view them in your favorite
browser.

The translation workflow is as follows: Pick a .po file, write an
[ITT] mail to the list, then update the translation, send it with
[RFR], and once the review is done, send a [DONE] and attach the
reviewed po file. I'm subscribed to this list, and when encountering
such a [DONE] mail, I will commit this file and add their contents to
the compendium. Ideally, the subject line of the mail should follow
this scheme:

[…] man://manpages-l10n/fr/manpage.1.po

This makes sure that it can be parsed properly by the robot and it is
easier to filter out [DONE] mails which are not relevant for me.
Regarding write access to the Git repo, it is up to Tobias as the
owner of the repo to grant access.

Best Regards,
Mario


scripts.pot
Description: MS-Powerpoint presentation

Re: Status of manpages-fr -- help needed?

[Mario Blättermann]

Hello all,

Am So., 22. Sept. 2019 um 16:23 Uhr schrieb Mario Blättermann
:
>
> Hello all,
>
> Am So., 8. Sept. 2019 um 11:16 Uhr schrieb Baptiste Jammet
> :
>
> > Hello Helge, et al.
>
> > First of all thanks for your offer, and sorry for my late (and maybe too 
> > long) answer.
>
> > I don't have any "let's do this" solution but I can quickly explain how 
> > french translation was
> > handled.
>
> > The perkamon/man-pages project [1] is used to handle the infrastructure, 
> > sharable with
> > any language. Next, the perkamon/man-pages-fr [2] is used to translate the 
> > manpages,
> > distro-agnostic.
>
> > Finally comes Debian packaging, using perkamon as upstream.
>
> > [1] https://gitlab.com/perkamon/man-pages
> > [2] https://gitlab.com/perkamon/man-pages-fr
>
> The first steps towards up-to-date French manpages are done. I've
> imported all the existing
> translations (almost all, see below) from the Perkamon repo and
> manpages-fr-extra from the latest Debian source package. See [1].
>
> I've split the merged po files into single ones, one po file per
> source file. Well, this disables synergy effects introduced by keeping
> multiple source files together, but we maintain »common« files [2]
> which contain a compendium of all gettext messages which occur more
> than once in all po files. This way we can edit the compendium files
> after any change in the upstream packages and merge the changes back
> to the po files.
>
> Currently the imported po files are in three directories:
>
> In »fr« we have the po files which have been imported from the Perkamon repo.
>
> In »fr-extra« we have the po files which have been imported from the
> already mentioned latest Debian source package. It would be nice if
> you are OK with merging both directories into one. It would be easier
> to maintain.
>
> In »fr-openssl« are some po files from manpages-fr-extra, which are
> based on pod sources instead of Groff or Mdoc. This leads to almost
> empty po files after importing. I'm in doubt if it makes sense at all
> to do the import. The same applies to some of the Lilo manpages, which
> are already in fr-extra.
>
> In general, I would welcome a new project named »manpages-i18n« as the
> successor of manpages-de and manpages-fr. Regarding distribution
> packaging, it would work like the GUI translations in KDE, which are
> all come from a single tarball. This means in particular, we release a
> tarball manpages-i18n-x.x.x. and distribution packagers split it into
> the langauge-specific parts (manpages-i18n-de, manpages-i18n-fr and so
> on for eventually more languages in the future). Moreover, where
> applicable, the language packages can be split into »base« and »dev«
> packages. By renaming to manpages-i18n, future distribution packages
> needs to be declared as updates of the current manpages-de and
> manpages-fr/manpages-fr-extra.
>
> Don't expect too much for the time being. Besides the import itself
> I've only added some scripts for handling the updates, and maybe some
> pot files are still missing. But the »common« translations are already
> present, so if anyone is willing to contribute, please have a look at
> the common files first [2].
>
> (Please keep Tobias and Helge in CC)
>
> [1] https://salsa.debian.org/manpages-de-team/manpages-de/tree/import_fr/po/fr
> [2] 
> https://salsa.debian.org/manpages-de-team/manpages-de/tree/import_fr/po/fr/common
>

Now the import of the French man pages has been finished and a new
project has been created:

https://salsa.debian.org/manpages-l10n-team/manpages-l10n

The French po files are in po/fr/. The original files from manpages-fr
and mapages-fr-extra have been merged into one pool. After the import,
I've created the compendium files in po/fr/common/, filled them with
translations (as far it was possible for a non-French speaker) and
synchronized the compendium with the po files.

Now we have 1385 po files, but 560 of them cannot be built to
translated man pages because they don't reach the 80% threshold of
Po4a. I've done all I could do, now it is up to real French
translators to update the po files accordingly.

The infrastructure inside po/fr/ already works; after checking out the
Git repo you can use the scripts for interaction with the compendium,
reformatting the po files and so on. The script
public/generate-stats-page-fr.sh generates HTML files with a status
table for all supported distribution. Sorry, currently it is still
German, but it should be self-explaining. When editing po files,
please keep the file headers intact. The current structure above the
translatro names is needed for a proper addendum for the Groff-Mdoc
files.

Moreover, I need some additional help with cre

Re: Status of manpages-fr -- help needed?

[Mario Blättermann]

Hello all,

Am So., 8. Sept. 2019 um 11:16 Uhr schrieb Baptiste Jammet
:

> Hello Helge, et al.

> First of all thanks for your offer, and sorry for my late (and maybe too 
> long) answer.

> I don't have any "let's do this" solution but I can quickly explain how 
> french translation was
> handled.

> The perkamon/man-pages project [1] is used to handle the infrastructure, 
> sharable with
> any language. Next, the perkamon/man-pages-fr [2] is used to translate the 
> manpages,
> distro-agnostic.

> Finally comes Debian packaging, using perkamon as upstream.

> [1] https://gitlab.com/perkamon/man-pages
> [2] https://gitlab.com/perkamon/man-pages-fr

The first steps towards up-to-date French manpages are done. I've
imported all the existing
translations (almost all, see below) from the Perkamon repo and
manpages-fr-extra from the latest Debian source package. See [1].

I've split the merged po files into single ones, one po file per
source file. Well, this disables synergy effects introduced by keeping
multiple source files together, but we maintain »common« files [2]
which contain a compendium of all gettext messages which occur more
than once in all po files. This way we can edit the compendium files
after any change in the upstream packages and merge the changes back
to the po files.

Currently the imported po files are in three directories:

In »fr« we have the po files which have been imported from the Perkamon repo.

In »fr-extra« we have the po files which have been imported from the
already mentioned latest Debian source package. It would be nice if
you are OK with merging both directories into one. It would be easier
to maintain.

In »fr-openssl« are some po files from manpages-fr-extra, which are
based on pod sources instead of Groff or Mdoc. This leads to almost
empty po files after importing. I'm in doubt if it makes sense at all
to do the import. The same applies to some of the Lilo manpages, which
are already in fr-extra.

In general, I would welcome a new project named »manpages-i18n« as the
successor of manpages-de and manpages-fr. Regarding distribution
packaging, it would work like the GUI translations in KDE, which are
all come from a single tarball. This means in particular, we release a
tarball manpages-i18n-x.x.x. and distribution packagers split it into
the langauge-specific parts (manpages-i18n-de, manpages-i18n-fr and so
on for eventually more languages in the future). Moreover, where
applicable, the language packages can be split into »base« and »dev«
packages. By renaming to manpages-i18n, future distribution packages
needs to be declared as updates of the current manpages-de and
manpages-fr/manpages-fr-extra.

Don't expect too much for the time being. Besides the import itself
I've only added some scripts for handling the updates, and maybe some
pot files are still missing. But the »common« translations are already
present, so if anyone is willing to contribute, please have a look at
the common files first [2].

(Please keep Tobias and Helge in CC)

[1] https://salsa.debian.org/manpages-de-team/manpages-de/tree/import_fr/po/fr
[2] 
https://salsa.debian.org/manpages-de-team/manpages-de/tree/import_fr/po/fr/common

Best Regards,
Mario