Re: Debian Policy 3.8.3.0 released: localized manpages

[Christian Perrier]

Before people "blindly" update their Standards-Version, I deeply
suggest looking at this item:

>   * Localized man pages should either be kept up-to-date with the
> original version or warn that they're not up-to-date, either with
> warning text or by showing missing or changed portions in the
> original language.[12.1]


*many* packages do provide localized manpages where l10n is handled
"manually" (the translated manpages are just a copy of the original
oneswhere English is manually replaced by the said language). With
such setup, it is nearly impossible to guarantee that the localized
manpage is in sync with the original one.

As such, this "should" prevents *many* packages to meet 3.8.3 for
Standards-Version. You may thus want to check things carefully..:)

(thankfully for our release date, this "should" is not a "must"...:-))





signature.asc
Description: Digital signature

Re: Debian Policy 3.8.3.0 released: localized manpages

[Paul Wise]

On Sun, Aug 16, 2009 at 3:49 PM, Christian Perrier wrote:

> Before people "blindly" update their Standards-Version, I deeply
> suggest looking at this item:
>
>>   * Localized man pages should either be kept up-to-date with the
>>     original version or warn that they're not up-to-date, either with
>>     warning text or by showing missing or changed portions in the
>>     original language.                                        [12.1]
>
> *many* packages do provide localized manpages where l10n is handled
> "manually" (the translated manpages are just a copy of the original
> oneswhere English is manually replaced by the said language). With
> such setup, it is nearly impossible to guarantee that the localized
> manpage is in sync with the original one.

Could the i18n team write something about the technical details of
doing translated manual pages the "right way" that could be shown to
upstreams and promoted via lwn.net, blogs and similar? I wanted to do
translated manual pages for chromium-bsu upstream but not knowing how
to do it properly prevented me from doing it at all.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#541771: ITP: tegaki-tools -- tools for tegaki project

[LI Daobing]

Package: wnpp
Severity: wishlist
Owner: LI Daobing 

* Package name: tegaki-tools
  Version : 0.2
  Upstream Author : Mathieu Blondel 
* URL : http://www.tegaki.org/
* License : GPLv2
  Programming Lang: Python
  Description : tools for tegaki project
 Tegaki is an ongoing project which aims to develop a free and open-source
 modern implementation of handwriting recognition software, that is suitable
 for both the desktop and mobile devices, and that is designed from the ground
 up to work well with Chinese and Japanese.
 .
 This package provides tools for tegaki.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian Policy 3.8.3.0 released: localized manpages

[Neil Williams]

On Sun, 16 Aug 2009 16:31:09 +0800
Paul Wise  wrote:

> On Sun, Aug 16, 2009 at 3:49 PM, Christian Perrier wrote:
> 
> > Before people "blindly" update their Standards-Version, I deeply
> > suggest looking at this item:
> >
> >>   * Localized man pages should either be kept up-to-date with the
> >>     original version or warn that they're not up-to-date, either with
> >>     warning text or by showing missing or changed portions in the
> >>     original language.                                        [12.1]
> >
> > *many* packages do provide localized manpages where l10n is handled
> > "manually" (the translated manpages are just a copy of the original
> > oneswhere English is manually replaced by the said language). With
> > such setup, it is nearly impossible to guarantee that the localized
> > manpage is in sync with the original one.
> 
> Could the i18n team write something about the technical details of
> doing translated manual pages the "right way" that could be shown to
> upstreams and promoted via lwn.net, blogs and similar? I wanted to do
> translated manual pages for chromium-bsu upstream but not knowing how
> to do it properly prevented me from doing it at all.

po4a

I did start such a guide via my blog during DebConf8

http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/129-po4a-translation-support-from-any-format.html

The key is to generate the manpages from whichever format you prefer
and then use po4a to arrange that the format bears the translation. The
generation of the manpages is then independent of the language of that
translation and the translated content itself comes from typical PO
files with which translators are already familiar.

This makes it much the same method as other translations:
1. Upstream changes the English text for a new release
2. Build system processes the English and generates a POT file
containing the updated strings, merges those strings with any existing
PO files and creates an output format of a type chosen by upstream that
contains those strings that can be translated along with any modified
strings that are awaiting translation. i.e. a mixed document that
clearly complies with Policy. This is basically scripting po4a to work
with the paths to the files containing the strings for translation.
3. The (temporary) generated files are then processed by po4a within the
normal build system to generate not only the English manpages but also
whichever translations carry enough translated strings to exceed some
threshold value - often 70%. The actual value is configurable. Note
that each string is quite long - I can't remember if it is 70% of the
number of strings independent of length or 70% of the total length of
the strings.
4. The modified POT file and any existing PO file is sent for
translation updates - necessarily, this process needs to be allowed
more time than a string freeze for debconf or program string
translation due to the number and length of the strings. e.g.
emdebian-tools manpages created a POT file with 3,500 strings at one
point, each string being maybe 50 words. Translations that fail to
exceed the threshold will not have any translated manpages generated.
Translations that are between the threshold and 100% will have some
sentences in English and only unchanged sentences translated.
5. Updated PO files are put into the relevant po/ directory upstream,
the final release tarball is built and/or po/ files are patched with
updates etc..

That being said, translating manpages is a different issue to
translating debconf strings or even program translations - the sheer
size of each string and the number of strings in total makes updating
and maintaining those translations into quite a burden.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpO8z9oQ7bPT.pgp
Description: PGP signature

Re: Debian Policy 3.8.3.0 released: localized manpages

[Michal Čihař]

Hi

Dne Sun, 16 Aug 2009 16:31:09 +0800
Paul Wise  napsal(a):

> Could the i18n team write something about the technical details of
> doing translated manual pages the "right way" that could be shown to
> upstreams and promoted via lwn.net, blogs and similar? I wanted to do
> translated manual pages for chromium-bsu upstream but not knowing how
> to do it properly prevented me from doing it at all.

Probably using po4a is the easiest way to handle man pages.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Bug#541777: ITP: tegaki-train -- training program of tegaki project

[LI Daobing]

Package: wnpp
Severity: wishlist
Owner: LI Daobing 

* Package name: tegaki-train
  Version : 0.2
  Upstream Author : Mathieu Blondel 
* URL : http://www.tegaki.org/
* License : GPLv2
  Programming Lang: Python
  Description : training program of tegaki project
 Tegaki is an ongoing project which aims to develop a free and open-source
 modern implementation of handwriting recognition software, that is suitable
 for both the desktop and mobile devices, and that is designed from the ground
 up to work well with Chinese and Japanese.
 .
 This package provide the training program of tegaki project



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Future of mole-generated symbols files, maintainer needed

[Raphael Hertzog]

Hello,

I'm looking for someone to take over the maintenance of the mole
worker that generates symbols files, example:
http://qa.debian.org/cgi-bin/mole/seedsymbols?pkgname=libx11-6

It's not much code and it's all in the qa SVN but it requires a better
place to run (currently it runs on alioth:~hertzog/mole/). Doing it on
merkel within the qa team (with the rest of the mole stuff) is certainly
a good option. It requires installation of binutils-multiarch but
otherwise should run on lenny. Most of the work is just ensuring that it
keeps running/working.

http://svn.debian.org/viewsvn/qa/trunk/mole/worker/ (all symbols* files)

Sometimes it needs an update to keep up with mole changes but it's fairly
low maintainance and Christoph Berg has always been helpful to fix things
up when needed.

You should also deal with related bug reports submitted against
qa.debian.org but they are relatively rare. I just opened one since
Julien Cristau reported me a problem:
http://bugs.debian.org/541776

There are new features in symbols files that it would be interesting to
exploit, in particular the arch restriction tagging feature[1]. It would
require some coding but generating a single symbols file that works
for all architectures would be a nice feature, isn't it?

I will of course respond to any question that you might have since I really
want to give this project to someone else.

Cheers,

[1] If you don't know what it is, check man dpkg-gensymbols, you can have
stuff like that in symbols files now:
 (arch=alpha amd64 kfreebsd-amd64 ia64)a_64bit_specific_sym...@base 1.0
 (arch=!armel)symbol_armel_does_not_h...@base 1.0
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

add me link exchang

[Rok Jhon]

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian Policy 3.8.3.0 released: localized manpages

[Helge Kreutzmann]

Hello Christian,
as the one originally suggesting this I guess I might add something.

On Sun, Aug 16, 2009 at 09:49:13AM +0200, Christian Perrier wrote:
> Before people "blindly" update their Standards-Version, I deeply
> suggest looking at this item:
> 
> >   * Localized man pages should either be kept up-to-date with the
> > original version or warn that they're not up-to-date, either with
> > warning text or by showing missing or changed portions in the
> > original language.[12.1]
> 
> 
> *many* packages do provide localized manpages where l10n is handled
> "manually" (the translated manpages are just a copy of the original
> oneswhere English is manually replaced by the said language). With
> such setup, it is nearly impossible to guarantee that the localized
> manpage is in sync with the original one.

The background is rather simple: Those man pages can cause quite a bit
of a problem. At least for German there are lots of man pages which
are clearly outdated, some are not even a translation at all, because
at some point someone wanted a German man page (or the customers
wanted one) and a brief version was written, without any indication of
the status. So users who are happy to read the German version have no
indication that they read an outdated or incomplete text. I've heard
(and experienced) several occasions where the users looked for help in
a man page, read the German version, did not find it and assumed it
won't work (and asked me/online for alternatives just to be told, to
use the switch -XYZ which simply was not explained in the German
version).

And the text is IMHO sufficient. With such an manual setup the
maintainer should talk to upstream to get something like the
following in the beginning of each translated man page (of course, in
the target language where possible):

This man page is updated infrequently|manually. Thus it might be out
of date. In doubt, also refer to the original English version which
you can read by issuing
LANG=C man foobar

Maybe on debian-i18n we could issue a call for translation of this
text (once we agreed on a phrase) such that maintainers using a patch
system could add it already until a solution with upstream is found.

> As such, this "should" prevents *many* packages to meet 3.8.3 for
> Standards-Version. You may thus want to check things carefully..:)

> (thankfully for our release date, this "should" is not a "must"...:-))

I (maybe wrongly) assumed a »should« to be: Do it if possible and be
ready to explain if not. A shall/must is something mandatory. But if
policy is different, then the verb "should" be adjusted. But I would
not use something like "may" or "can" as this would defeat the
purpose.

The intend really should be that maintainers start checking the status
of their man page translations and talk to their upstream about
them[¹].
Maybe upstream thinks about switching to po4a or something similar
already? Otherwise upstream could contact the translators
of the man pages and ask them to add a note or something similar to
the man page. I'm quite aware that this probably will take years. But
we have to start somewhen.

Greetings

  Helge

[1] That is, if upstream maintains a man page. Otherwise the
maintainer could consider i18n the Debian provided man page using,
e.g. po4a.
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Re: Debian Policy 3.8.3.0 released: localized manpages

[Helge Kreutzmann]

Hello,
On Sun, Aug 16, 2009 at 10:44:33AM +0200, Michal ??iha?? wrote:
> Dne Sun, 16 Aug 2009 16:31:09 +0800
> Paul Wise  napsal(a):
> 
> > Could the i18n team write something about the technical details of
> > doing translated manual pages the "right way" that could be shown to
> > upstreams and promoted via lwn.net, blogs and similar? I wanted to do
> > translated manual pages for chromium-bsu upstream but not knowing how
> > to do it properly prevented me from doing it at all.
> 
> Probably using po4a is the easiest way to handle man pages.

You might refer upstream to working examples like dpkg which have
quite a substantive use of i18n, including po4a for man pages. And of
course po4a is well documented in - you guessed it - its man pages,
which are even translated in some languages.

Greetings

   Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Re: GnuPG 1.4.10 RC1 available from Debian Experimental

[Daniel Leidert]

Forwarding to debian-devel too.

> Hi,
> 
> The recent release candidate 1 for GnuPG 1.4.10 has been packaged and 
> uploaded 
> to Debian's "experimental" distribution, in order to facilitate testing. If 
> you wish, please try it out and of course report bugs found. All cautions 
> around release candidates and the experimental distribution of course apply.
> 
> See: http://packages.debian.org/experimental/gnupg

With this (pre-)release, almost all patches applied to the Debian
package have been integrated upstream and a *lot* of bugs and issues
have been fixed (closing >25 Debian/Ubuntu bug reports). This release
further comes with hkps support (HKP over SSL) [1,2]. So please help
testing [3] the upcoming GnuPG 1.4.10 release and send us an report, if
you observe issues.

[1] http://lists.gnupg.org/pipermail/gnupg-devel/2009-August/025289.html
[2] http://bugs.debian.org/519333
[3] https://bugs.g10code.com/gnupg/issue931 (for example)

Regards, Daniel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

development plans for the squeeze cycle

[Marc Brockschmidt]

Heya,

As announced on dda [RT1], we want to get an impression when releasing
Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
2009, and some developers have noted that their planned changes wouldn't be
possible in this time frame. 
So, to find out when releasing would work for most people, I've just
send out a heap of mails to some specific teams who maintain larger
packages, but I would also love to hear answers from other developers:

Do you have any big changes planned? How much time would they take, and
what consequences are there for the rest of the project?

How many "big" transitions will the upcoming changes cause? When should those
happen? Can we do something to make them easier?

Thanks,
Marc

[RT1] http://lists.debian.org/debian-devel-announce/2009/07/msg1.html


pgpMt1sGDBp1l.pgp
Description: PGP signature

Re: Debian Policy 3.8.3.0 released: localized manpages

[gregor herrmann]

On Sun, 16 Aug 2009 12:44:18 +0200, Helge Kreutzmann wrote:

> > >   * Localized man pages should either be kept up-to-date with the
> > > original version or warn that they're not up-to-date, either with
> > > warning text or by showing missing or changed portions in the
> > > original language.[12.1]

> Maybe on debian-i18n we could issue a call for translation of this
> text (once we agreed on a phrase) such that maintainers using a patch
> system could add it already until a solution with upstream is found.

That might indeed be helpful.
 
> > As such, this "should" prevents *many* packages to meet 3.8.3 for
> > Standards-Version. You may thus want to check things carefully..:)

An interesting question is how to detect outdated translated
manpages; if they are only half the size or miss some options in an
item list it's simple but if the text is just outdated and/or wrong I
fear I'll have some problems in several languages ...

Cheers,
gregor (not subscribed to debian-i18n)
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Supertramp: It's Raining Again


signature.asc
Description: Digital signature

Re: Bits from the release team and request for discussion

[Philipp Kern]

On 2009-08-04, Anthony Towns  wrote:
> So make it easy to maintain... Attached is an example converting it to
> yaml with python table generation, coping with waivers.

I deployed that now.  Result available on [1], still quite some question
marks, though.

Kind regards,
Philipp Kern

[1] http://release.debian.org/squeeze/arch_qualify.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian Policy 3.8.3.0 released: localized manpages

[Paul Wise]

On Sun, Aug 16, 2009 at 5:05 PM, Neil Williams  wrote:

> po4a
>
> I did start such a guide via my blog during DebConf8
>
> http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/129-po4a-translation-support-from-any-format.html

Would you (or anyone else) be willing to turn this into an article for
the development section of LWN to promote the use of po4a outside of
Debian? In case you need an incentive, LWN pay their writers.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian Policy 3.8.3.0 released: localized manpages

[Helge Kreutzmann]

Hello Gregor,
On Sun, Aug 16, 2009 at 03:22:26PM +0200, gregor herrmann wrote:
> On Sun, 16 Aug 2009 12:44:18 +0200, Helge Kreutzmann wrote:
> > > As such, this "should" prevents *many* packages to meet 3.8.3 for
> > > Standards-Version. You may thus want to check things carefully..:)
> 
> An interesting question is how to detect outdated translated
> manpages; if they are only half the size or miss some options in an
> item list it's simple but if the text is just outdated and/or wrong I
> fear I'll have some problems in several languages ...

I guess you either know from upstream or another source (say, a
translator) that they are current, or you could look at the date of
the last modification (possibly of the source of the man page if it is
generated). Otherwise it is probably best to add the note anyway,
so that readers in doubt know where to look.

Greetings

  Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Re: Debian Policy 3.8.3.0 released: localized manpages

[Neil Williams]

On Sun, 16 Aug 2009 15:22:26 +0200
gregor herrmann  wrote:

> > > As such, this "should" prevents *many* packages to meet 3.8.3 for
> > > Standards-Version. You may thus want to check things carefully..:)
> 
> An interesting question is how to detect outdated translated
> manpages; if they are only half the size or miss some options in an
> item list it's simple but if the text is just outdated and/or wrong I
> fear I'll have some problems in several languages ...

Use po4a and PO files and simple gettext utilities like msgfmt will
tell you exactly how many strings are outdated (these gettext will
replace with the current English versions) and those that are missing
(again, English substituted). Just as how gettext works for binaries.

145 strings translated, 43 fuzzy 12 missing
etc.

Using PO also makes it easier to detect problems with the final
manpages as well as from the source package - just grep for a component
of an English string introduced in the most recent update.

po4a and gettext ensure that you don't have completely missing sections
or outdated content like missing or obsolete command line options - if
the strings are not up to date, English is always used to fill the
gaps. It leads to mixed manpages, yes, but some English paragraphs is
better than either the outdated translation or a gap.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpccvP5rbrlT.pgp
Description: PGP signature

Re: Debian Policy 3.8.3.0 released: localized manpages

[Neil Williams]

On Sun, 16 Aug 2009 21:51:32 +0800
Paul Wise  wrote:

> > I did start such a guide via my blog during DebConf8
> >
> > http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/129-po4a-translation-support-from-any-format.html
> 
> Would you (or anyone else) be willing to turn this into an article for
> the development section of LWN to promote the use of po4a outside of
> Debian? In case you need an incentive, LWN pay their writers.

It's certainly appealing - however, there is a reason why this blog
article didn't turn into the series of articles that I anticipated
during DebConf8 - I haven't got suitable translations for the packages
concerned, therefore the code suffers from a lack of real testing.
(Payment is not an incentive for me - indeed it tends to complicate
things more than anything else.)

I was initially looking at revising and expanding on that article as a
direct result of working with translations of the emdebian-tools
manpages but there were simply too many strings for initial translator
(who is part of the Emdebian project) to handle. I've since split the
source package into 4 so maybe now is a good time to seek out
translators for some of these manpages. (The content of the manpages
has settled somewhat over the intervening time as well, which will
help.) I'll start the process on debian-i18n. (1 of the 4 has no
translatable content - emdebian-archive-keyring.)

I can then use the process of improving and adapting the build system
for these packages according to complete the documentation, file bugs
against po4a etc.

In that respect, Policy is ahead of my available time.
:-(

If there is a different package already using po4a with an established
build system hook, let me know.

OTOH if people here think that the blog itself is sufficient for an
LWN article, once reworded and rephrased, then I might consider doing the
LWN article in stages too - however I do think it is worth having some
translations to work with before claiming that the code snippets
included in the original blog entry are sufficiently robust for a more
authoritative document like LWN.

The three source packages with po4a support already are:
emdebian-tools  (1743 entries) 385kb POT file
emdebian-rootfs  (384 entries)  65kb POT file
emdebian-grip(531 entries) 115kb POT file

I think I'll start with emdebian-rootfs - the strings haven't changed
much in recent releases. The time needed for translations to be made
means that I should be off VAC before I need to do much with the code.

There is also the proviso that although po4a is very good at what it
does, issues remain that are difficult to fix but which jar when
compared to how the same issues are handled in program or debconf
translations. e.g. skipping some strings and adding comments for
translators that do not show up in the generated manpages. I should
have filed bug reports about these things ages ago but ran out of time.
With real translators and real translations at hand, these things
should be easier to describe in bugs and easier to test potential fixes.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpfucOj4hQNJ.pgp
Description: PGP signature

Re: Debian Policy 3.8.3.0 released: localized manpages

[Russ Allbery]

Christian Perrier  writes:

> Before people "blindly" update their Standards-Version, I deeply
> suggest looking at this item:

>>   * Localized man pages should either be kept up-to-date with the
>> original version or warn that they're not up-to-date, either with
>> warning text or by showing missing or changed portions in the
>> original language.[12.1]


> *many* packages do provide localized manpages where l10n is handled
> "manually" (the translated manpages are just a copy of the original
> oneswhere English is manually replaced by the said language). With
> such setup, it is nearly impossible to guarantee that the localized
> manpage is in sync with the original one.

The intention in those cases is for the maintainer to add a warning to the
page saying that it may not be up-to-date (preferrably after doing some
analysis based on when they know the English manpage last changed).

> (thankfully for our release date, this "should" is not a "must"...:-))

Yes, very intentional.  :)

The rationale in the Policy discussion about this is that out-of-date man
page translations without any warning is *already* a bug, so putting it in
Policy saying that it's a bug doesn't make any packages more buggy than
they already are.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian Policy 3.8.3.0 released: localized manpages

[Ben Finney]

gregor herrmann  writes:

> An interesting question is how to detect outdated translated manpages;

According to ‘man-pages(7)’, the TH command in the man page should have
the date of the latest version of the document:

   The first command in a man page should be a TH command:

  .TH title section date source manual

   where:
[…]

  date  The date of the last revision — remember to
change this every time a change is made to the
man page, since this is the most  general way of
doing version control.
Dates should be written in the form -MM-DD.

I assume we expect man pages to conform to the conventions in
‘man-pages(7)’.

So surely the best way to tell if a translated page is out of date is to
compare these dates in the two documents, no?

-- 
 \  “An expert is a man who has made all the mistakes which can be |
  `\ made in a very narrow field.” —Niels Bohr |
_o__)  |
Ben Finney


pgpQy4j8ZCcZq.pgp
Description: PGP signature