Re: Translation issues with strftime

[Ole Laursen <olau hardworking dk>]

Danilo Segan <danilo@gnome.org> writes:

> Ole Laursen <olau@hardworking.dk> writes:
>>
>> Unfortunately, %e is a bad solution. I don't need an extra space:
>>
>>   tir 02. dec
>>   tir  2. dec
>>
>> I just want "tir 2. dec".
>
> I think that provided formats use space padding because of alignment:
> dates and times have previously been used in table listings (like 'ls
> -l') where it is very important that all the dates align the same.

Yeah, that is clearly the case. The facilities in strftime are
inadequate to deal with the situation today. We've known that for some
time. I've complained about it to Keld Simonsen who is part of the ISO
group responsible for the standard, but I don't know whether things
will ever change.

Another related problem is that it is not possible to get the date
capitalised in a specific way. I've heard of a problem with KMail (I
think) that the standard email introduction

  Monday, November 13, Zorglub wrote:

is impossible to get right because the Danish dates spell the weekday
uncapitalised:

  mandag, 13. november skrev Zorglub:

There's no way to tell strftime that the weekday should be
capitalised.


> As for your other comment (when does anyone use zero padding), I
> myself don't ever write the names of the days as first three-letters 
> only.  So, these formats are not a mirror of how we do it in real
> life, but rather, suited for particular purposes of usage in the 
> operating system.

I can see your point, but I don't think it's right. :-) The reason why
it says "tir" instead of "tirsdag" is that it is an abbreviation. So
maybe you never had to abbreviate "tirsdag" before in real life, but
if you had to you would choose "tir". That's not the case for the zero
padding.


>From your other letter:

> Just to make it clear: there's really a lot to making this approach
> work (because %e won't be at the beginning, or won't be in at all in
> some translations), I just wanted to point out that this can only be
> cleaned up in code, and it would still be a hack.
> 
> Any kind of solution which wouldn't change strftime definition (like
> those GNU extensions) is going to look as hack; and any extensions
> are bound to be not portable.

It is in fact portable if we bundle a better strftime with Gnome. And
that seems to be the case (at least judging from the bug I
referenced). So I'm simply advocating we use our own strftime. It's
probably not a lot of code so I don't see why it would be a problem.

-- 
Ole Laursen
http://www.cs.auc.dk/~olau/