Re: Some observations regarding manpage translations
Hello Jean-Philippe,
Am Di., 19. Apr. 2022 um 00:41 Uhr schrieb Jean-Philippe MENGUAL
<jpmengual@debian.org>:
>
> 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 this migration, and I've fixed lots of misformatting and many
more.
> > 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.
>
>
See above. Make more use of the compendium, this reduces your workload
significantly. But remember, the manpages-fr project was actually dead
for a few years, and it is normal that it takes more time to get it in
an up-to-date shape again.
Best Regards,
Mario
> >
> > I hope the above might give you some ideas how to improve the quality
> > and number of translated pages into French; again, if any (or all) of
> > this is not applicable, please ignore.
>
> Many thanks!
>
> Regards
>
> >
> > Greetings
> >
> > Helge
> >
> > Here is the current list (as of this morning) of pages which are close
> > to reach 80%:
> > argz_add.3
> > basename.3
> > blkdiscard.8
> > capabilities.7
> > core.5
> > ctime.3
> > daemon.3
> > drand48_r.3
> > dumpe2fs.8
> > ecvt.3
> > envz_add.3
> > filesystems.5
> > finite.3
> > fnmatch.3
> > fsck.minix.8
> > fsfreeze.8
> > fstrim.8
> > ftw.3
> > getauxval.3
> > getcontext.3
> > getfsent.3
> > getgrent_r.3
> > gethostbyname.3
> > getlogin.3
> > getmntent.3
> > getnetent.3
> > getprotoent.3
> > getpwent_r.3
> > getservent.3
> > host.conf.5
> > intro.5
> > isosize.8
> > j0.3
> > kill.1
> > ldattach.8
> > libblkid.3
> > locale.5
> > lseek64.3
> > mbstowcs.3
> > mem.4
> > mke2fs.8
> > mke2fs.conf.5
> > mkfs.8
> > mkfs.minix.8
> > motd.5
> > nfsidmap.5
> > openpty.3
> > pacman-conf.8
> > pivot_root.8
> > popen.3
> > pow10.3
> > pthread_create.3
> > ptsname.3
> > qecvt.3
> > random.3
> > rcmd.3
> > regex.3
> > resize2fs.8
> > rtnetlink.3
> > securetty.5
> > setarch.8
> > setnetgrent.3
> > setterm.1
> > sigprocmask.2
> > sigsetops.3
> > sk98lin.4
> > splice.2
> > statfs.2
> > statvfs.3
> > syslog.2
> > syslog.3
> > system.3
> > tcp.7
> > timegm.3
> > timer_create.2
> > timerfd_create.2
> > ttyname.3
> > tune2fs.8
> > undocumented.3
> > vmsplice.2
> > wait.2
> > wait4.2
> > wdctl.8
> > write.2
> > zdump.8
> >
> >
Reply to: