Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #411 (closed enhancement: fixed)

Opened 13 years ago

Last modified 13 years ago

I18N for CalendarDatePicker widget

Reported by: Jorge Godoy <jgodoy@…> Owned by: anonymous
Priority: high Milestone: 0.9
Component: TG Widgets Version:
Severity: normal Keywords:
Cc:

Description

This patch allos passing the following new parameter to the CalendarDatePicker? widget:

  • button_text: defaults to 'Choose'

The text that will be shown in the button will be presented to the user

  • lang: defaults to whatever turbogears.i18n.utils.get_locale() returns

The language of the calendar javascript, for example 'pt-utf8' to choose the file calendar-pt-utf8.js.

With this patch, this widget is more functional to users that need I18N on their applications.

Attachments

widgets-base-calendardatepicker-i18n.patch Download (2.1 KB) - added by Jorge Godoy <jgodoy@…> 13 years ago.
Patch to I18N CalendarDatePicker?
widgets-base-calendardatepicker-i18n.2.patch Download (2.1 KB) - added by alberto@… 13 years ago.

Change History

Changed 13 years ago by Jorge Godoy <jgodoy@…>

Patch to I18N CalendarDatePicker?

comment:1 Changed 13 years ago by alberto@…

  • Summary changed from I18N for CalendarDatePicker widget to [PATCH] I18N for CalendarDatePicker widget

Man, you should put [PATCH] in the summary so commiters get to see it ;)

comment:2 Changed 13 years ago by Jorge Godoy <jgodoy@…>

Thanks Alberto.

I usually do that, this one missed it. Thanks for adding it to me.

comment:3 Changed 13 years ago by anonymous

  • Milestone set to 0.9

comment:4 Changed 13 years ago by kevin

  • Summary changed from [PATCH] I18N for CalendarDatePicker widget to I18N for CalendarDatePicker widget

As talked about on the mailing list, the patch included here doesn't allow widgets to operate "statelessly". That is, these widgets will be sharing the localization file when they really shouldn't. I'm removing the [PATCH] tag.

Changed 13 years ago by alberto@…

comment:5 Changed 13 years ago by alberto@…

Hi Jorge,

I've written an adaptation of your patch for the Calendar in the new API (which sets the language at initialization time for each instance independently of each other) but I can't quite get it to work. See, it looks like the default locale for English is 'en_US' (in my system), but that language file doesn't exist:

127.0.0.1 - - [06/Feb/2006:16:17:22] "GET /tg_widgets/turbogears.widgets/lang/calendar-en_US.js HTTP/1.1" 404 1396

If you can think of something we can do about it...

Another problem is that the langage would be fixed at the instance's creation time so you'd have the same language for every request regardless of the content negotiation (maybe this is not a problem on some apps... though)

comment:6 Changed 13 years ago by alberto@…

Maybe forgetting about the get_locale stuff and defaulting to "en" ?

comment:7 Changed 13 years ago by Jorge Godoy <jgodoy@…>

Hi Alberto.

As I've posted, you'll need a different reference for language or renaming files at the JavaScript? directory. Another problem arises for languages with an ISO-8859-1/plain ASCII file and an UTF-8 alternative file (i.e., you have to have some mean to choose which one you want).

I thought about using get_locale just to try providing something useful that might one day give the correct result. The default on my (broken) patch was just 'en' -- as it is with get_locale.

But you have to have some way to point which file you want to use: pt, pt-utf8, etc. are valid values.

comment:8 Changed 13 years ago by alberto@…

  • Status changed from new to closed
  • Resolution set to fixed

I've commited at r661 something that can be used to change the language of the javascript though it doesn't do automatically based on the value returned from get_locale. This would be very nice but as get_locale can return values for which no language file exists and it's ugly to rename all the language files, this is the best compromise I could think of.

To summarize, now you can do:

calendar = W.CalendarDateTimePicker(calendar_lang="pt")

To make the calendar use the language file at lang/calendar-pt.js.

Note: See TracTickets for help on using tickets.