[PATCH] Improve consistency of that which dates are marked for localization

[Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>]

Hello,

subversion/libsvn_subr/time.c contains in lines 80-81:
/* Human explanatory part, generated by apr_strftime as "Sat, 01 Jan 2000" */
#define human_timestamp_format_suffix _(" (%a, %d %b %Y)")

But e. g. subversion/svn/list-cmd.c contains in lines 82-96:
      /* svn_time_to_human_cstring gives us something *way* too long
         to use for this, so we have to roll our own.  We include
         the year if the entry's time is not within half a year. */
      apr_time_exp_lt(&exp_time, dirent->time);
      if (apr_time_sec(now - dirent->time) < (365 * 86400 / 2)
          && apr_time_sec(dirent->time - now) < (365 * 86400 / 2))
        {
          apr_err = apr_strftime(timestr, &size, sizeof(timestr),
                                 "%b %d %H:%M", &exp_time);
        }
      else
        {
          apr_err = apr_strftime(timestr, &size, sizeof(timestr),
                                 "%b %d  %Y", &exp_time);
        }

As you can see, in the second case dates aren't marked for localization.
It would be more consistent if dates in both cases are marked for localization.

[[[
Mark dates for localization.

* subversion/libsvn_diff/diff_file.c
  (output_unified_default_hdr): Mark a date for localization.
* subversion/svn/list-cmd.c
  (print_dirent): Mark dates for localization.

Patch by: Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>
]]]

-- 
Arfrever Frehtes Taifersar Arahesis

Re: [PATCH] Improve consistency of that which dates are marked for localization

[Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

2007-09-05 18:04:47 Malcolm Rowe napisał(a):
> On Wed, Sep 05, 2007 at 05:01:44PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> > * subversion/libsvn_diff/diff_file.c
> >   (output_unified_default_hdr): Mark a date for localization.
> 
> This is presumably consistent with the behaviour of GNU diff and patch
> -- does GNU diff localise the dates? (and does patch take any notice of
> the date?).

Dates (and every other data after file name) are completely ignored (treated as comments) by `patch`.

> Actually, it looks like the core tools only ever use this directly in one
> place -- in the new conflict callback's diff command.  Elsewhere (in
> 'svn diff' and 'svnlook diff') we provide our own (different) labelling.
> 
> (I wonder if the conflict callbacks should be consistent with 'svn
> diff'?)

Current conflict callback's diff format is good, although additional revision number would be useful...
But application of my patch doesn't have any side effects :) .

- -- 
Arfrever Frehtes Taifersar Arahesis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)

iD8DBQFG3tul/axNJ4Xo/ZERAqlCAJ901itLXaEtxVr3hEmyT8ooLITySgCggq9c
Ag/lmssp0VX8yYs0n+2fnF8=
=QxYp
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [PATCH] Improve consistency of that which dates are marked for localization

[Malcolm Rowe <ma...@farside.org.uk>]

On Wed, Sep 05, 2007 at 05:01:44PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> * subversion/libsvn_diff/diff_file.c
>   (output_unified_default_hdr): Mark a date for localization.

This is presumably consistent with the behaviour of GNU diff and patch
-- does GNU diff localise the dates? (and does patch take any notice of
the date?).  It's possible that we need to stick with this specific
format.

...

Actually, it looks like the core tools only ever use this directly in one
place -- in the new conflict callback's diff command.  Elsewhere (in
'svn diff' and 'svnlook diff') we provide our own (different) labelling.

(I wonder if the conflict callbacks should be consistent with 'svn
diff'?)

> * subversion/svn/list-cmd.c
>   (print_dirent): Mark dates for localization.
> 

This one is presumably supposed to be consistent with 'ls -l', which does
change its output format according to locale -- so I think this is okay.

Regards,
Malcolm