Proposal to add International Date/Time/Number Formatting/Parsing feature to Gadgets

[Shaopeng]

Hi,

We have drafted a proposal to add International Date/Time/Number
Formatting/Parsing feature to Gadgets. You can find the details of
this proposal at the link below:

http://docs.google.com/Doc?id=d94ngww_188hh2vc6fb

Please let us know by June 20th if you have any feedback.

Thanks,

Shaopeng

[Kevin Brown]

Hi,

At first glance, parts of this library seem unnecessary.

For example:

gadgets.setLocale

The locale is already set at render time, as is required by the spec. Changing the locale at runtime for a gadget is impractical -- the locale of the entire site needs to change. This seems like something for developers who are testing locale-dependent code rather than something for end users (who generally will pick a locale and stick with it.)

gadgets.getLocale

This is unnecessary as we already have getCountry and getLanguage

It's not clear what getResource / registerResource would actually be used for. It seems like duplicated functionality of message bundles (with objects instead of strings, though in the wire format everything is a string anyway so this difference is irrelevant).

The interesting parts here are the formatting routines. This is a good start, but it also seems like the number of routines is overkill, and a simpler API might be preferred. Something like:

gadgets.i18n.formatDate(timestamp);
gadgets.i18n.formatInteger(value);
gadgets.i18n.formatDecimal(value);
gadgets.i18n.formatCurrency(value);

The 3 parsing routines seem confusing. Why would you need to parse "strict" vs just "parse"? Why would you need the parser objects? The parsing and formatting can easily be made into trivial constant time functions -- having a routine create an object which does the formatting makes the library harder to use.

Many libraries have already been built for these purposes -- for example, the dojo project has done extensive work:

http://api.dojotoolkit.org/jsdoc/dojo/HEAD/dojo.cldr

[Zhen Wang]

"gadgets" is not an appropriate namespace for this library. Please
consider "gadgets.locale" or "gadgets.i18n".

As Kevin pointed out, the gadget spec only supports one locale per
gadget instance. getLocale()/setLocale()'s usefulness is therefore
questionable.

Datetime/number format patterns are an implementation detail. I don't
think you need to expose them. If you do, please document their
differences from Java/ICU/CLDR's pattern spec.

parseDateTime, strictParseDateTime, and standardParseDateTime are not
well defined. Please consider merging them into one function. You may
add an optional parameter if the parsing mode ("standard" vs.
"strict") is truly important -- which I feel very doubtful.

Time zone, currency etc. are also important components of an i18n
library. Why are they left out?

On Sun, Jun 15, 2008 at 7:07 AM, Shaopeng <jia.sh...@gmail.com> wrote:
>

[shanjian]

setLocale/getLocale exist for the purpose of multi-locale support.
They are optional. If multi-locale support is not part of the goal,
this should be removed.

getResource / registerResource are for internal implementation.
registerResource make a resource avaiable and getResource retrieve
the resource. In the original design, single locale support will be
the dominant usage, but resource for multiple locales can be made
available if necessary. Thus we have this 2 funcions. They are very
simple and shouldn't add much overhead.

If what provided by your simple APIs is all gadget users' need, that's
what you should do. The original design need to support multiple
formats, including user customized ones. I don't have much experience
with gadgets. I feel support like "formatDate(timestamp)" could be too
limited.

shanjian

[shanjian]

yes, timezone and currency support are important. I suggested shaopeng
to skip this part for now. Existing API provided a limited support
already. We are testing out a new currency formatting model. The issue
with time zone is huge data size. We try not to push work back to
server, since that will make the API harder to use. I am
experienmenting with google app engine to provide time data in runtime
now . Will that work for gadgets? Or gadgets might want to host its
own time zone data server?

shanjian

On Jun 15, 4:15 pm, "Zhen Wang" <wa...@google.com> wrote:
> "gadgets" is not an appropriate namespace for this library. Please
> consider "gadgets.locale" or "gadgets.i18n".
>
> As Kevin pointed out, the gadget spec only supports one locale per
> gadget instance. getLocale()/setLocale()'s usefulness is therefore
> questionable.
>
> Datetime/number format patterns are an implementation detail. I don't
> think you need to expose them. If you do, please document their
> differences from Java/ICU/CLDR's pattern spec.
>
> parseDateTime, strictParseDateTime, and standardParseDateTime are not
> well defined. Please consider merging them into one function. You may
> add an optional parameter if the parsing mode ("standard" vs.
> "strict") is truly important -- which I feel very doubtful.
>
> Time zone, currency etc. are also important components of an i18n
> library. Why are they left out?
>

[Kevin Brown]

On Tue, Jun 17, 2008 at 1:56 PM, shanjian <shanj...@gmail.com> wrote:

setLocale/getLocale exist for the purpose of multi-locale support.
They are optional. If multi-locale support is not part of the goal,
this should be removed.

We do support multiple locales already. I'd suggest reading the existing specification for details on how locales are handled within opensocial.
 

getResource / registerResource are for internal implementation.
registerResource  make a resource avaiable and getResource retrieve
the resource. In the original design, single locale support will be
the dominant usage, but resource for multiple locales can be made
available if necessary. Thus we have this 2 funcions. They are very
simple and shouldn't add much overhead.

This is exactly what message bundles are for. This is an unnecessary addition.
 

[Zhen Wang]

On Tue, Jun 17, 2008 at 1:56 PM, shanjian <shanj...@gmail.com> wrote:
>

> setLocale/getLocale exist for the purpose of multi-locale support.
> They are optional. If multi-locale support is not part of the goal,
> this should be removed.

Please do.

>
> getResource / registerResource are for internal implementation.
> registerResource make a resource avaiable and getResource retrieve
> the resource. In the original design, single locale support will be
> the dominant usage, but resource for multiple locales can be made
> available if necessary. Thus we have this 2 funcions. They are very
> simple and shouldn't add much overhead.

Internal implementation details should not be exposed to the public interface.

[Zhen Wang]

On Tue, Jun 17, 2008 at 2:04 PM, shanjian <shanj...@gmail.com> wrote:
>
> yes, timezone and currency support are important. I suggested shaopeng
> to skip this part for now. Existing API provided a limited support
> already. We are testing out a new currency formatting model. The issue
> with time zone is huge data size. We try not to push work back to
> server, since that will make the API harder to use. I am
> experienmenting with google app engine to provide time data in runtime
> now . Will that work for gadgets? Or gadgets might want to host its
> own time zone data server?

I'm confused: You don't want "to push work back to server", yet you
suggest the use of GAE to host time zone data. What's the rationale
behind the decision?

[shanjian]

Oh, that part is not stated clearly. Here is what I trying to say. Our
goal is to remove static linked data from code. So the data has to be
put on some servers and should be loaded dynamically in run time as
need. But the burden shouldn't be put on client developers. For
Closure, we will make general data retrieving code on client ready
and a backend server support in GAE. Closure application can at least
use GAE in prototyping. In production, they may choose to host those
data on their own server.

shanjian

On Jun 17, 2:40 pm, "Zhen Wang" <wa...@google.com> wrote:

[shanjian]

To further clarify, here "multi-locale support" means multiple locales
in single session. The assumption is that for general JS application,
they will stay in one locale for one session. Switching locale
involves a server reload, and thus starts a new session. But for some
applications, they may need to have access to resource from several
locales in one session. For example, an application may choose to
display date in both Japanaese and English on the same page. Such
usage is very rare. It is perfectly fine for Gadgets not to support
such usage. setLocale exists for such usages.

Gadges may already have existing API equivalent to "getLocale", which
is used to retrieve the currency locale being used. If so, not
problem. If not, I strongly suggest we have something here.

Message bundle can be used to make date/time and number format related
resources available to client, but it might not be the most efficient
way. Resources for date/time formatting are mostly string arrays. If
gadges allows code to be conditionally "linked" based on locale
choice, it might work better to let locale related resource file (js
file) be used directly. Anyway, those 2 functions are never intended
to be public API. It is purely implementation detail and shouldn't
appear in "specification". Shaopeng's proposal is a design doc
including "specification" and some implementation choices.

shanjian

On Jun 17, 2:19 pm, "Kevin Brown" <e...@google.com> wrote:

[Kevin Brown]

Again, this is what message bundles are for. Have you read the message bundle specification?

[Zhen Wang]

On Wed, Jun 18, 2008 at 12:12 PM, shanjian <shanj...@gmail.com> wrote:
>
> To further clarify, here "multi-locale support" means multiple locales
> in single session. The assumption is that for general JS application,
> they will stay in one locale for one session. Switching locale
> involves a server reload, and thus starts a new session. But for some
> applications, they may need to have access to resource from several
> locales in one session. For example, an application may choose to
> display date in both Japanaese and English on the same page. Such
> usage is very rare. It is perfectly fine for Gadgets not to support
> such usage. setLocale exists for such usages.
>
> Gadges may already have existing API equivalent to "getLocale", which
> is used to retrieve the currency locale being used. If so, not
> problem. If not, I strongly suggest we have something here.

Gadgets API has support for getLang() and getCountry() since the very beginning.
http://code.google.com/apis/opensocial/docs/0.8/reference/gadgets/#gadgets.Prefs

[Kevin Brown]

On Wed, Jun 18, 2008 at 12:12 PM, shanjian <shanj...@gmail.com> wrote:

To further clarify, here "multi-locale support" means multiple locales
in single session. The assumption is that for general JS application,
they will stay in one locale for one session. Switching locale
involves a server reload, and thus starts a new session. But for some
applications, they may need to have access to resource from several
locales in one session. For example, an application may choose to
display date in both Japanaese and English on the same page. Such
usage is very rare. It is perfectly fine for Gadgets not to support
such usage. setLocale exists for such usages.

This requires a server reload regardless, because changing the locale is a container event, not a gadget event. Simply changing the locale for the date or currency seems very targeted towards a specific case (if not just contrived entirely) -- the developer can always include an external file with the formatting strings for special cases like this.
 

Message bundle can be used to make date/time and number format related
resources available to client, but it might not be the most efficient
way. Resources for date/time formatting are mostly string arrays. If
gadges allows code to be conditionally "linked" based on locale
choice, it might work better to let locale related resource file (js
file) be used directly.

That's what gadgets.json is for.
 

 Anyway, those 2 functions are never intended
to be public API. It is purely implementation detail and shouldn't
appear in "specification". Shaopeng's proposal is a design doc
including "specification" and some implementation choices.

This is a mailing list for discussing changes to the opensocial standard (as seen on http://opensocial.org). Implementation details are beyond the scope of the discussion for the most part.

From what I'm getting here, it seems like the only change actually proposed are some libraries for date, number, and currency formatting. That seems reasonable, but that's only a small subset of what's in the doc you sent. Would you like to simplify this to the actual proposed spec changes so that we can isolate the discussion to those details?
 

[shanjian]

Shaopeng, would you mind removing those "design" discussion and
simplify the doc to be a spec?

thanks

shanjian

On Jun 18, 12:28 pm, "Kevin Brown" <e...@google.com> wrote:

> seen onhttp://opensocial.org). Implementation details are beyond the scope

[Shaopeng]

Sure! I have revised the document. The new spec incorporates some of
the feedback from this thread, and includes many code snippets to show
how the API could be used. More documentation on the syntax for
patterns are also included.

Please take a look at the link below and let me know if there is any
question:

http://docs.google.com/Doc?id=d94ngww_188hh2vc6fb

Thanks,

Shaopeng

[Bob]

shanjian> Shaopeng, would you mind removing those "design" discussion
and
shanjian> simplify the doc to be a spec?

I'd like to capture the design discussion somewhere so we remember how
we made the decisions...

[Shaopeng]

I have just added a section at the beginning of the Spec Proposal. It
is basically a summary to capture the design decisions made during our
discussion here. We could always find the details in this forum, so I
guess the summary is sufficient.

Thanks,

Shaopeng

[Zhen Wang]

The revised doc is much better!

Suggestions:
- Remove standardFormatDateTime; accept predefined patterns as the
first parameter of formatDateTime;
- Merge standardParseDateTime and parseDateTime;
- Merge standardFormatNumber and formatNumber;
- Remove all get*Formatter, get*Parser functions. I find them
unnecessary and confusing (e.g. Should developers call parseDateTime
to parse date or get a parser first?)
- Please elaborate on how errors are handled. For example, what
happens when you call
gadgets.i18n.standardParseNumber(gadgets.i18n.CURRENCY_PATTERN, "0,20
€"); if the locale is en-US?

[Shaopeng]

See my comments inlined.

On Jun 26, 9:47 pm, "Zhen Wang" <wa...@google.com> wrote:
> The revised doc is much better!

Thanks!

>
> Suggestions:
> - Remove standardFormatDateTime; accept predefined patterns as the
> first parameter of formatDateTime;
> - Merge standardParseDateTime and parseDateTime;
> - Merge standardFormatNumber and formatNumber;

Predefined patterns are often good for average users(of our API, that
is, gadgets developers), but they only cover very limited cases. We
need to give users flexibility to construct patterns when they want to
deal with cases that are not covered by the predefined pattern. For
example, formatting/parsing the date "Jun. 27" is not possible with
predefined date patterns (Year field will always be part of the date
in predefined patterns); this is also true for number formatting.

What I could do is to merge the functions as you suggested, but accept
both predefined patterns and user-constructed patterns as the first
parameter. In this case average users could use the simple API as you
suggested, but power users could construct patterns if they need to.
What do you think?

> - Remove all get*Formatter, get*Parser functions. I find them
> unnecessary and confusing (e.g. Should developers call parseDateTime
> to parse date or get a parser first?)

I am sorry if the documentation is not clear enough, let me try to
clarify here: For one time formatting(which is the majority of the
cases), users just need to use formatDateTime (which creates a
formatter internally to carry out the formatting). For the few cases
where users need to format many dates, repeatedly calling
formatDateTime is very inefficient. What they could do is to create a
formatter by calling getDateTimeFormatter, then use the formatter to
format date/time by invoking its format() function. The same logic
applies to the parser.

> - Please elaborate on how errors are handled. For example, what
> happens when you call
> gadgets.i18n.standardParseNumber(gadgets.i18n.CURRENCY_PATTERN, "0,20
> €"); if the locale is en-US?

0 will be returned for error cases - I have put this into the API
proposal.

[Kevin Brown]

On Fri, Jun 27, 2008 at 11:09 AM, Shaopeng <jia.sh...@gmail.com> wrote:

See my comments inlined.

On Jun 26, 9:47 pm, "Zhen Wang" <wa...@google.com> wrote:
> The revised doc is much better!

Thanks!

>
> Suggestions:
> - Remove standardFormatDateTime; accept predefined patterns as the
> first parameter of formatDateTime;
> - Merge standardParseDateTime and parseDateTime;
> - Merge standardFormatNumber and formatNumber;

Predefined patterns are often good for average users(of our API, that
is, gadgets developers), but they only cover very limited cases. We
need to give users flexibility to construct patterns when they want to
deal with cases that are not covered by the predefined pattern. For
example, formatting/parsing the date "Jun. 27" is not possible with
predefined date patterns (Year field will always be part of the date
in predefined patterns); this is also true for number formatting.

What I could do is to merge the functions as you suggested, but accept
both predefined patterns and user-constructed patterns as the first
parameter. In this case average users could use the simple API as you
suggested, but power users could construct patterns if they need to.
What do you think?

That's what he's suggesting -- the "predefined patterns" are just strings, so you don't need two functions here.
 

> - Remove all get*Formatter, get*Parser functions. I find them
> unnecessary and confusing (e.g. Should developers call parseDateTime
> to parse date or get a parser first?)

I am sorry if the documentation is not clear enough, let me try to
clarify here: For one time formatting(which is the majority of the
cases), users just need to use formatDateTime (which creates a
formatter internally to carry out the formatting). For the few cases
where users need to format many dates, repeatedly calling
formatDateTime is very inefficient.

Why is it inefficient? That sounds like an implementation bug, not an intentional design choice.
 

What they could do is to create a
formatter by calling getDateTimeFormatter, then use the formatter to
format date/time by invoking its format() function. The same logic
applies to the parser.

> - Please elaborate on how errors are handled. For example, what
> happens when you call
> gadgets.i18n.standardParseNumber(gadgets.i18n.CURRENCY_PATTERN, "0,20
> €"); if the locale is en-US?

0 will be returned for error cases - I have put this into the API
proposal.

How do you know that 0,20  € is an error case?

For that matter -- how does currency parsing make any sense at all? 20 € is definitely not the same as $20 :)

[Zhen Wang]

On Fri, Jun 27, 2008 at 11:09 AM, Shaopeng <jia.sh...@gmail.com> wrote:

> See my comments inlined.
>
> On Jun 26, 9:47 pm, "Zhen Wang" <wa...@google.com> wrote:
>> The revised doc is much better!
>
> Thanks!
>
>>
>> Suggestions:
>> - Remove standardFormatDateTime; accept predefined patterns as the
>> first parameter of formatDateTime;
>> - Merge standardParseDateTime and parseDateTime;
>> - Merge standardFormatNumber and formatNumber;
>
> Predefined patterns are often good for average users(of our API, that
> is, gadgets developers), but they only cover very limited cases. We
> need to give users flexibility to construct patterns when they want to
> deal with cases that are not covered by the predefined pattern. For
> example, formatting/parsing the date "Jun. 27" is not possible with
> predefined date patterns (Year field will always be part of the date
> in predefined patterns); this is also true for number formatting.
>
> What I could do is to merge the functions as you suggested, but accept
> both predefined patterns and user-constructed patterns as the first
> parameter. In this case average users could use the simple API as you
> suggested, but power users could construct patterns if they need to.
> What do you think?

That's what I suggested :)

>
>> - Remove all get*Formatter, get*Parser functions. I find them
>> unnecessary and confusing (e.g. Should developers call parseDateTime
>> to parse date or get a parser first?)
>
> I am sorry if the documentation is not clear enough, let me try to
> clarify here: For one time formatting(which is the majority of the
> cases), users just need to use formatDateTime (which creates a
> formatter internally to carry out the formatting). For the few cases
> where users need to format many dates, repeatedly calling
> formatDateTime is very inefficient. What they could do is to create a
> formatter by calling getDateTimeFormatter, then use the formatter to
> format date/time by invoking its format() function. The same logic
> applies to the parser.

If formatDateTime is inefficient, try to improve it, probably by
caching a repeatedly called parser internally.

[Shaopeng]

Thanks for the great suggestions Kevin and Zhen! I have made changes
to the code to cache formater and parser internally, and now our
interface is much simpler without much compromise on performance. I
have also eliminated those standardFormat*/standardParse* functions by
accepting both string patterns and pre-defined patterns as first
parameter. You could find the details in the original doc:

http://docs.google.com/Doc?id=d94ngww_188hh2vc6fb

For the error case we discussed, I added a section (section 5) in the
doc to explain this in detail.

Please let me know if you have any further concerns. After you are ok
with the proposal, I will submit the code as a patch to Shindig, so
that gadget developers could benefit from our libraries.

Thanks for your time and effort reviewing this doc guys!

Shaopeng

On Jun 27, 8:53 pm, "Zhen Wang" <wa...@google.com> wrote:

> ...
>
> read more »

[Kevin Brown]

On Fri, Jul 11, 2008 at 6:46 AM, Shaopeng <jia.sh...@gmail.com> wrote:

Thanks for the great suggestions Kevin and Zhen! I have made changes
to the code to cache formater and parser internally, and now our
interface is much simpler without much compromise on performance. I
have also eliminated those standardFormat*/standardParse* functions by
accepting both string patterns and pre-defined patterns as first

parameter. You could find the details in the original doc:

 http://docs.google.com/Doc?id=d94ngww_188hh2vc6fb

For the error case we discussed, I added a section (section 5) in the
doc to explain this in detail.

Please let me know if you have any further concerns. After you are ok
with the proposal, I will submit the code as a patch to Shindig, so
that gadget developers could benefit from our libraries.

That's not how this process works. Adding a new library to shindig doesn't make it a part of opensocial. Shindig intentionally avoids features that aren't already a part of the standard, or close to being adopted without much contention.
 

[Shaopeng]

I see. We had some email discussions before with Zhen and agreed Shindig is the place to go. If the proposal looks ok, shall we submit it to Shindig first? Then we could work together to resolove potential contentions if there is any, so that it could be part of OpenSocial and benefits gadget developers in the near future. Sounds resonable? ;)

Thanks,

Shaopeng  

[Chris Chabot]

What you should do is send it as a proposal to this list, and when
it's time to vote for the 0.9 spec, people can vote for it.
Unfortunately the 0.8 spec is already baked, and support for it is
almost completed, so it's a to late to slipstream a feature into it.

Come 0.9, if it gets at least 5 +1 votes and no -1's, it'll become an
official part of the specification, and -then- you can submit a patch
for shindig.

Shindig's goal is to support / implement the open social
specification, so putting it in shindig before it's part of the spec
would be putting the proverbial cart in front of the horse.

Keep in mind that next to shindig there are other Open Social
implementation(s) too, and if we don't all follow the same spec we'd
make life for gadget developers a lot more difficult .. so everything
like this always starts in the spec first, and then we worry about
implementing it :)

-- Chris

[Shaopeng]

Thanks for the detailed explanation Chris! Then we will just wait for
the time to vote for the 0.9 spec. (Any idea when is that going to
be? )

Meanwhile, if there is any question or further comments about this
proposal, please feel free to let me know :)

Thanks!

Shaopeng

[Chris Chabot]

Ps there is nothing wrong with trying to gather support, bake and
maturing the idea now and further developing & documenting it to
prepare for the 0.9 time frame and ensuring max traction for it so
it'll go in smoothly :)

Seeing that we're still hard at work trying to get 0.8 out there i
think 0.9 will probably take a little bit of time, i think it might
take somewhere between 1 to 4 months (was it every half a year?
quarter? Others on the list can probably give you a better overview of
the timeline then i me)

-- Chris

[Shaopeng]

I would like to mention this is a proposal for inclusion in 0.9. It was proposed 3 months ago and has gone through extensive discussion (see below). It didn't make into 0.8 because when it was proposed 0.8 was almost baked. Please vote on it when it is time to vote for 0.9 proposals.

Thanks,

Shaopeng

[Scott Seely]

An internationalization library was proposed. Because of the unique
formatting of the proposal (it uses special symbols that may not
appear correctly in all email readers), please review the proposal at
http://docs.google.com/View?docid=d94ngww_188hh2vc6fb. Please direct
any questions back to this thread.

On Oct 13, 10:55 am, Shaopeng <jia.shao.p...@gmail.com> wrote:
> I would like to mention this is a proposal for inclusion in 0.9. It was
> proposed 3 months ago and has gone through extensive discussion (see below).
> It didn't make into 0.8 because when it was proposed 0.8 was almost baked.
> Please vote on it when it is time to vote for 0.9 proposals.
>
> Thanks,
>
> Shaopeng
>

[Scott Seely]

Shaopeng,
This proposal looks great. Can you post a link to the JS?

[Scott Seely]

Shaopeng-- can you post a link to the JS? If not, can someone
contribute the accompanying JS?

I will call this thread dead by Wednesday AM, 11-5, if we see no
further activity. I really like the idea and would like to vote for it
if I could see the implementation (which appears to already exist).

On Oct 28, 1:49 pm, Scott Seely <sSe...@myspace.com> wrote:
> Shaopeng,
> This proposal looks great. Can you post a link to the JS?
>
> -----Original Message-----
> From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Scott Seely
> Sent: Monday, October 27, 2008 12:54 PM
> To: OpenSocial - OpenSocial and Gadgets Specification Discussion
> Subject: [opensocial-and-gadgets-spec] Re: Proposal to add InternationalDate/Time/Number Formatting/Parsing feature to Gadgets
>
> An internationalization library was proposed. Because of the unique
> formatting of the proposal (it uses special symbols that may not

> appear correctly in all email readers), please review the proposal athttp://docs.google.com/View?docid=d94ngww_188hh2vc6fb. Please direct

[Shaopeng]

Thanks Scott! I have the JS ready (it was done 2 months ago, so things
might have changed in Opensocial, and I might need to some quick test
to make sure everything is still working fine - this shouldn't take
much time and could be completed in the next week or two). I could
post the JS file I have right now while doing the final testing to
make sure everything still works fine.

By the way, it seems since the reorganization of the OpenSocial Google
Group 2-3 months ago, I no longer belongs to the group; and whenever I
click "Join this group", i will get a Null Pointer Exception. Is there
anything that could be done to resolve this? Because of this I am not
receiving any update on my post, which explains my unresponsiveness
for your post. Also it seems although I could post message here, I am
not able to add any attachment.

Thanks,

Shaopeng

On Oct 28, 1:49 pm, Scott Seely <sSe...@myspace.com> wrote:

> Shaopeng,
> This proposal looks great. Can you post a link to the JS?
>
> -----Original Message-----
> From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Scott Seely
> Sent: Monday, October 27, 2008 12:54 PM
> To: OpenSocial - OpenSocial and Gadgets Specification Discussion
> Subject: [opensocial-and-gadgets-spec] Re: Proposal to add InternationalDate/Time/Number Formatting/Parsing feature to Gadgets
>
> An internationalization library was proposed. Because of the unique
> formatting of the proposal (it uses special symbols that may not

> appear correctly in all email readers), please review the proposal athttp://docs.google.com/View?docid=d94ngww_188hh2vc6fb. Please direct

> any questions back to this thread.
>
> On Oct 13, 10:55 am, Shaopeng <jia.shao.p...@gmail.com> wrote:
> > I would like to mention this is a proposal for inclusion in 0.9. It was
> > proposed 3 months ago and has gone through extensive discussion (see below).
> > It didn't make into 0.8 because when it was proposed 0.8 was almost baked.

> > Please vote on it when it istimeto vote for 0.9 proposals.

>
> > Thanks,
>
> > Shaopeng
>
> > On Tue, Jul 15, 2008 at 7:02 AM, Chris Chabot <chab...@xs4all.nl> wrote:
>
> > > Ps there is nothing wrong with trying to gather support, bake and
> > > maturing the idea now and further developing & documenting it to

> > > prepare for the 0.9timeframe and ensuring max traction for it so

> > > it'll go in smoothly :)
>
> > > Seeing that we're still hard at work trying to get 0.8 out there i

> > > think 0.9 will probably take a little bit oftime, i think it might

> > > take somewhere between 1 to 4 months (was it every half a year?
> > > quarter? Others on the list can probably give you a better overview of
> > > the timeline then i me)
>
> > >        -- Chris
>
> > > On Jul 15, 2008, at 1:53 PM, Shaopeng wrote:
>
> > > > Thanks for the detailed explanation Chris! Then we will just wait for

> > > > thetimeto vote for the 0.9 spec. (Any idea when is that going to

> > > > be? )
>
> > > > Meanwhile, if there is any question or further comments about this
> > > > proposal, please feel free to let me know :)
>
> > > > Thanks!
>
> > > > Shaopeng
>
> > > > On Jul 12, 6:42 pm, Chris Chabot <chab...@xs4all.nl> wrote:
> > > >> What you should do is send it as a proposal to this list, and when

> > > >> it'stimeto vote for the 0.9 spec, people can vote for it.

[Shaopeng]

Hi Scott,

I will post the JS by EOD in this thread. I have waited for 3 months to get this into Opensocial and I am really glad to see progress is being made to achieve that goal.

There is a bug in Google Group and I didn't receive any update on posting to this thread. Please keep my email CCed if you post any message in this thread.

Thanks,

Shaopeng

[Shaopeng]

Here is a draft on how the core pieces would look like. Any function that is not in the spec is private.

I also have unittest for each file. There are also a bunch of data files I would like to check in (for each locale: 1 file for datetime and 1 file for number). These data files are automatically generated by reading the public Unicode CLDR (Common Locale Data Repository).

Please feel free to let me know if there is any question. If these look acceptable, please vote as appropriate.

Thanks,

Shaopeng

[Shaopeng]

Here is the patch. It includes the source and unittest. I have tested the patch on my local shindig client and everything is working fine.

If everything looks ok, could we start to vote on this proposal? If there is any concern, please do raise it. I would love to make fixes rather now than later.

Thanks,

[Shaopeng]

Oops, the attachment was dropped off by gmail. I am re-attaching the patch.

[Zhen Wang]

The copyright info looks wrong to me.

[Shaopeng]

Thanks Zhen, I have update the patch and attached the new one.

[Zhen Wang]

+1

The API looks good, although the reference implementation seems to be bloated.

[Shaopeng]

Thanks for voting positively for the proposal Zhen! We will have plenty of chances to improve/trim down the implementation during the later code-review stage.

[Scott Seely]

+1

[Shaopeng]

＋1 （I am the submitter)

[Bob]

+1 (I work with Shaopeng)

On Nov 11, 1:27 pm, Shaopeng <jia.shao.p...@gmail.com> wrote:
> ＋1 （I am the submitter)
>
> On Tue, Nov 11, 2008 at 11:56 AM, Scott Seely <sSe...@myspace.com> wrote:
> > +1
>

> > *From:* Shaopeng [mailto:jia.shao.p...@gmail.com]
> > *Sent:* Tuesday, November 11, 2008 11:23 AM
> > *To:* Zhen Wang
> > *Cc:* Scott Seely; OpenSocial - OpenSocial and Gadgets Specification
> > Discussion; uid...@google.com; Dan Peterson; e...@google.com;
> > shanjia...@gmail.com; markus....@gmail.com; Vladimir Weinstein
> > *Subject:* Re: Proposal to add International Date/Time/Number

> > Formatting/Parsing feature to Gadgets
>
> > Thanks for voting positively for the proposal Zhen! We will have plenty of
> > chances to improve/trim down the implementation during the later code-review
> > stage.
>
> > On Tue, Nov 11, 2008 at 11:02 AM, Zhen Wang <wa...@google.com> wrote:
>
> > +1
>
> > The API looks good, although the reference implementation seems to be
> > bloated.
>

> > On Thu, Nov 6, 2008 at 6:06 PM, Shaopeng <jia.shao.p...@gmail.com> wrote:
>
> > Thanks Zhen, I have update the patch and attached the new one.
>
> > On Thu, Nov 6, 2008 at 5:54 PM, Zhen Wang <wa...@google.com> wrote:
>
> > The copyright info looks wrong to me.
>

> > On Thu, Nov 6, 2008 at 5:50 PM, Shaopeng <jia.shao.p...@gmail.com> wrote:
>
> > Oops, the attachment was dropped off by gmail. I am re-attaching the patch.
>

> > On Thu, Nov 6, 2008 at 5:39 PM, Shaopeng <jia.shao.p...@gmail.com> wrote:
>
> > Here is the patch. It includes the source and unittest. I have tested the
> > patch on my local shindig client and everything is working fine.
>
> > If everything looks ok, could we start to vote on this proposal? If there
> > is any concern, please do raise it. I would love to make fixes rather now
> > than later.
>
> > Thanks,
>

> > On Mon, Nov 3, 2008 at 11:47 AM, Shaopeng <jia.shao.p...@gmail.com> wrote:
>
> > Here is a draft on how the core pieces would look like. Any function that
> > is not in the spec is private.
>
> > I also have unittest for each file. There are also a bunch of data files I
> > would like to check in (for each locale: 1 file for datetime and 1 file for
> > number). These data files are automatically generated by reading the public
> > Unicode CLDR (Common Locale Data Repository).
>
> > Please feel free to let me know if there is any question. If these look
> > acceptable, please vote as appropriate.
>
> > Thanks,
>
> > Shaopeng
>

[Evan Gilbert]

+1

2008/11/12 Bob <bob...@gmail.com>

[Markus]

+1
I work with Shaopeng, and I helped him a little with his API.

Markus Scherer

[Bess Ho]

+1

Cross platform support will have to support international date/time/number/currency format outside US like Europe and Asia for non-US containers.