(2012年03月20日 21:04), Stefan Sperling wrote:
On Tue, Mar 20, 2012 at 04:24:11PM +0900, Berin Babcock-McConnell wrote:
Hello,

I have a question regarding the format of the date displayed in the
log of a repository when using a Japanese locale.  Specifically, the
format of the "human timestamp format suffix" (as it is described in
libsvn_subr/time.c) doesn't seem to be quite right and I'm wondering
if there is a reason for the format as it is.

For example, if you were to execute

$ svn log http://svn.apache.org/repos/asf/subversion

in English you would see date lines such as

"r1302758 | hwright | 2012-03-20 11:34:26 +0900 (Tue, 20 Mar 2012) |
14 lines"

The "(Tue, 20 Mar 2012)" part is dictated by the "human timestamp
format suffix" in libsvn_subr/time.c and in Japanese if you execute
the same command you get,

"r1302758 | hwright | 2012-03-20 11:34:26 +0900 (火, 20  3月 2012) |
14 lines"

This doesn't seem to be right because the order is the exact
opposite of what one would expect (normally this would be ordered as
year, month, day, day of week) and only the month has the character
for month (whereas the day and year do not have the characters for
day and year so there is a lack of consistency).

In other words, I would expect that in Japanese I would get something like,

"r1302758 | hwright | 2012-03-20 11:34:26 +0900 (2012年3月20日 (火))
| 14 lines"

I have adjusted this on my system by changing the msgstr for msgid "
(%a, %d %b %Y)" from " (%a, %d %b %Y)" to " (%x (%a))".

This feels like a bug to me and I looked at the latest version of
the Japanese po file (revision 1302772, line 6238) and I see that
the format is still " (%a, %d %b %Y)".  I have googled around a bit
and looked in through the issue list, etc, and I haven't found any
discussion on this and I'm wondering if there is a particular reason
for this format or is it just that nobody has said anything yet
or...?

Did you see this part of the comment above the human-readable date
format string?

  * [..] The
  * human explanatory part is generated by apr_strftime, which means
  * that its generation can be affected by locale, it can fail and it
  * doesn't need to be constant in size. In other words, perfect to be
  * converted to a configuration option later on.

IOW, there are many strftime() format flags people might want to use.
The correct date format can be based on the locale. But it might just
as well be based on personal preferences.

So the strftime() format string for the human-readable part of the date
is hardcoded in the code right now and it is unfortunate that this looks
bad in some locales.

Is there an alternative strftime() format string that would produce
the desired result in English, Japanese and any other language?
If so, we could use that instead.

Or we could add a new feature to make the format string configurable.
As the comment suggests, there could be a client-side configuration
option that allows users to specify an strftime() compatible format
string that Subversion should use here, with the current format
string as default.

Would you like to submit a patch that implements either of these approaches?

Yes, I did notice that comment. I also noticed the following comment in the po file,

  TRANSLATION-FIXME: If APR supported reordering of
  format indicators.... Human explanatory part, generated
  by apr_strftime as "Sat, 01 Jan 2000"

To be honest neither made much sense to me because my understanding is that the locale dependent string is getting printed out. In other words, Subversion takes human_timestamp_format_suffix and asks for the format string that is appropriate for the current locale.

If there were an alternate strftime() format string that produces the correct result in all languages that would be great. But it seems that there is not and that is why there is a localization string in the po file, right?

I can see why it might be nice to give people a slightly more flexible method for overriding the format string than updating their local mo file and in googling this I got the feeling some client (maybe Turtoise?) allows you to do this with properties (although I'm not sure since I didn't pursue this)...

But I'm suggesting that the current string for human_timestamp_format_suffix in the ja.po file isn't the best.

I've noticed that many other languages have human_timestamp_format_suffix strings that differ from the default and I'm wondering why this is not the case with Japanese?

Reply via email to