642537 - Twitterparty tweet dates not translatable

Status: VERIFIED WONTFIX

(www.mozilla.org :: General, defect)

Description

[Rebecca Billings [:rbillings]]

Dates in /he locale tweets are displaying timezone info. Per comment 7 in bug 642233, this is not supported- nor is translating the month. 

If this fix is not workable for the release, please mark as 'won't fix'.

Comment 1

[Andre Torgal]

We're really sorry it wasn't detected earlier. There's a possible workaround but it's not realistic to try and fix it now.

Comment 2

[Staś Małolepszy :stas]

Pasting Andre's comment from the other bug:

«Just noticed that the hebraic translation is using timezone in the date
format.

This is not supported by our date formatting function (sorry, we did not point
out which features of the PHP formatting syntax
http://pt.php.net/manual/en/function.date.php are not supported, but we never
timezone was going to be used).

Also, I've noticed that month names won't be translated. 

If it's still acceptable to work this (given the code "freeze" urgency) we can
still try some workaround for this. Off course, month names will have to be in
all translations. We can manually force these with a key such as _('month1');
... through 12 and then pass on the localization of all months to the
javascript.»

Comment 3

[Staś Małolepszy :stas]

(In reply to comment #2)

> This is not supported by our date formatting function (sorry, we did not point
> out which features of the PHP formatting syntax
> http://pt.php.net/manual/en/function.date.php are not supported, but we never
> timezone was going to be used).

Timezone does seem strange, I'll ask Tomer why he used that.

> Also, I've noticed that month names won't be translated. 

Should I recommend to the localizers that they use a numeric value for the months then?

Comment 4

[Staś Małolepszy :stas]

(In reply to comment #3)
> (In reply to comment #2)
> 
> > This is not supported by our date formatting function (sorry, we did not point
> > out which features of the PHP formatting syntax
> > http://pt.php.net/manual/en/function.date.php are not supported, but we never
> > timezone was going to be used).
> 
> Timezone does seem strange, I'll ask Tomer why he used that.

Tomer changed the date format string, so it should be OK now.

He asks, however, how we can tell the user that the times are not in his own timezone?  I don't think we can change the design right now to accommodate this feedback, but it's something we should thing about next time.

Comment 5

[Andre Torgal]

Definitely. There were a lot of lessons learned already and also some puzzles left unsolved. Projects like these don't come often, but when we have another go at it, we'll be taking measures since day one.

Comment 6

[Leo Xavier]

What about adding the same time on the title of the date and add "UTC" or "GMT" to it? So when a user leaves the mouse on the date, the title will show with that info.

Comment 7

[Staś Małolepszy :stas]

That would be a nice solution that seems clean in that it doesn't add to the visible UI.

However, this isn't a high priority right now, and if we're code frozen, I think it's fine to leave it as it is right now.

Are all tweets in UTC?

Comment 8

[Leo Xavier]

Yes, all tweets are in UTC. Which doesn't make any sense for someone living outside of the GMT+0 timezone (everyone except us portuguese and the brits).

I only now remembered that we should have converted all dates to the clients timezone (using the getTimezoneOffset() function, http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp ).

I'm going to check with André & co to see if this can still be pushed.

Comment 9

[Leo Xavier]

Turns out the function we're using is already showing the date converted to the client's timezone (using the OS time). So no need to tell what timezone they're being showed in, since it's already in the user's timezone.