Localization of strings

[GoogleCodeExporter]

Most of the string of the widget are not localized (names of days and
months, hours in dayview).

The AgendaView is localized but use "DateTimeFormat.getFormat("EEE MMM
d");" to format dates, where IMO "DateTimeFormat.getLongDateFormat()" would
be a better fit.

I used something like this, for a time picker:

for (int h =0; h<24; h++){
  for (int m : new int[]{0, 30}){
    tmpList[pos] = new Date(2009, 1, 1, h, m);
    pos++;
  }
}

If everybody is ok with the idea, I can provide a patch that will take care
of this across gwt-cal.

Original issue reported on code.google.com by bertrand...@gmail.com on 9 Dec 2009 at 3:31

[GoogleCodeExporter]

Added locale-sensitive formatting to the DayView and MonthView as of r221. 

AgendaView will not be included in gwt-cal 0.9.0. It won't be merged with the 
trunk and 
AGENDA will be removed as a CalendarViews enum value. I am postponing work on 
the 
AgendaView in favor of DayView DragDrop.

Original comment by Brad.Ryd...@gmail.com on 21 Dec 2009 at 12:20

• Changed state: Fixed
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Works for me even if the small modification on the bottom of this post makes 
things
looks better. I think it's good enough for the 0.9, but I was pondering on the 
issue
and maybe the ideal solution would be to let the calling code provide custom 
time
formats (for example the shortTimeFormat looks better in english than in 
french).

Index: CalendarModel.java
===================================================================
--- CalendarModel.java  (révision 221)
+++ CalendarModel.java  (copie de travail)
@@ -78,10 +78,10 @@
        String hourFormat = "h";

        if(!hour.equals("12:00 PM")) {

-           NOON = "12";

+           NOON = hour;

            AM = "";

            PM = "";

-           hourFormat = "HH";

+           hourFormat = shortTimeFormat.getPattern();

        }

        shortTimeFormat =

Original comment by bertrand...@gmail.com on 21 Dec 2009 at 9:18

[GoogleCodeExporter]

ok, enfin je comprends le problem. j'ai modifié le code comme tu as 
recommendé, mais tu 
as raison, on peut trouver une meilleure solution.

Carlitos - maybe you can help here also? as an american i'm a bit challenged w/ 
internationalization :)

Original comment by Brad.Ryd...@gmail.com on 21 Dec 2009 at 5:26

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Traduction : "Ok, I understand the problem. I've modified the code as you asked 
it.
But you're right, we can find a better solution"
My english is not good as well but i hope you will understand :-)

Original comment by dinou.di...@gmail.com on 21 Dec 2009 at 5:45

[GoogleCodeExporter]

All the DateTimeFormat patterns are now driven from the 
CalendarConstants.properties 
files, which get loaded into the CalendarModel class.

You can override the formats (for example the hour format) with this call:

CalendarModel.INSTANCE.hourFormatter = DateTimeFormat.getFormat("your custom 
format");

Note: this class will change (like names being re-factored) but i'll keep the 
ability 
to modify the format

Some values are calculated and cached... we'll need the ability to refresh the 
cache. 
I'll make a note to myself to add this functionality

Original comment by Brad.Ryd...@gmail.com on 4 Feb 2010 at 6:21

[GoogleCodeExporter]

Original comment by Brad.Ryd...@gmail.com on 15 Feb 2010 at 2:26

• Changed state: Fixed

[GoogleCodeExporter]

Hi guys,

I don't known if I'm missing something, but the current structure in the 0.9 
branch
is not flexible enough to change the hourFormatter. For example, I need to show 
the
hour format as H:00, but the whole AMPM is getting harder to do it.

Attached you can find a patch that seems to solve the whole issue. I'm sure it 
will
need some extra work, but seems like a better starting point.

I really hope to see it included in the final 0.9 version :)

Cheers,

Original comment by ctasada on 23 Feb 2010 at 10:31

Attachments:

• 24HFormatter.patch

[GoogleCodeExporter]

We currently modify the hour format using gwt's i18n feature. It is 
customizable based on locale, and specified in 
properties files. Right now we only have 3 locales, EN, FR and ES

In the default (EN) version of CalendarConstants.properties you see:
noon=Noon
more=+{0} more
timeFormat=h:mm
dateFormat=EEE, MMM d
weekdayFormat=EEE
am=AM
pm=PM

In the version francaise we do the following:
noon=12:00
more=+{0} en plus
timeFormat=HH:00
dateFormat=EEE, d MMM
weekdayFormat=EEE
am=
pm=

You will see the French version is pretty similar to what you are asking for, 
just with an extra "H". Are you sure you 
just don't need us to add your regions locale, instead of patching code?

If formatting for your specific locale does not solve the problem, let me ask 
the following questions, if you don't mind
1) What locale are you programming for
2) What theme are you using? 
3) What is the use case for deviating from the standard ways ical and google 
display their time formats

Original comment by Brad.Ryd...@gmail.com on 23 Feb 2010 at 10:46

[GoogleCodeExporter]

Hi Brad,

The main reason is that I've a case in which I simply want to ignore the locale 
and
give the user the possibility to choose between a 24h format and an am/pm 
format.
Also seems that the proper place to configure this behavior is in the
CalendarSettings class.

I'm sure you'll agree with me that flexibility is always a good thing and that,
sometimes, the defaults are not what the user wants :(

I hope the patch I send is good enough to cover this issue.

Regards,
Carlos.

Original comment by ctasada on 4 Mar 2010 at 8:09

[GoogleCodeExporter]

Issue 36 has been merged into this issue.

Original comment by Brad.Ryd...@gmail.com on 10 Mar 2010 at 4:20

[GoogleCodeExporter]

Hello!

I would appreciate to have a norwegian property file too (google theme). The 
content
should be:

noon=12:00
more=+{0} til
timeFormat=HH:00
dateFormat=EEE d. MMM
weekdayFormat=EEE
am=
pm=

Regards,
Terje

Original comment by terje...@hotmail.com on 11 Mar 2010 at 6:22

[GoogleCodeExporter]

Original comment by Brad.Ryd...@gmail.com on 12 May 2010 at 7:10

• Added labels: Release0.9