Globalization files

[globalizejs]

Globalization files

[InfinitiesLoop]

Some of the files do have code, actually. They are the ones which require specialized date conversion due to a non-gregorian calendar. Take a look at the AR ones for example.

If the only benefit to making them plain JSON is that they don't depend on a particular namespace, I'm not sure it's worth the added complexity of requiring a new API to load them and being unable to include them statically like (I think) you'd expect to. Also note that the files aren't really stand alone -- they only contain the difference between that culture and the default culture. Doing that really reduces the redundancy since a lot of cultures only differ slightly. To go with JSON files, they'd either need to drop that and be fully self describing, and therefore larger, or they'd require 'processing' by the host library to merge them.

[kflorence]

Hmm, I don't see how the merging would be any different. The merges are basically JSON object merges as it is now, anyways. The only real extra step would be having to load files instead of including them statically, which is also the only major drawback. I agree that it would add extra complexity that perhaps isn't needed, though.

But anyways, I now see that there are in fact functions stored within the language definitions, so as it is now it would be impossible to implement the same thing in JSON. There must be a better way of starting out the definition blocks, though, instead of having to do this in every one:

var cultures = $.cultures,
    en = cultures.en,
    standard = en.calendars.standard,
    culture = cultures["ar-AE"] = $.extend(true, {}, en, {

You could just extend the cultures object with an object with the key of the culture as a wrapper around the information (thus creating the namespace within cultures) like:

{ "ar-AE": { ... } }

Perhaps not that big of a deal, though... just looks a bit clunky as is.

[InfinitiesLoop]

That code is caching a few references for better minification. It can't just assign the object to the culture, it has to $.extend it with the standard culture, since it is only a diff of it. It also has to assign the current calendar after they are all defined.

There could be an API in glob.js that it called instead, but this would mean exposing a new public API for just this purpose.

[kflorence]

I see. What would be the downside to exposing a public function such as:

Globalization.addCulture({ ... });

that would automatically handle merging definitions into the default (en) and assigning the current calendar for you?

[InfinitiesLoop]

As Globalization it isn't an issue. But in the jQuery dependent version that'd be jQuery.addCulture - a new top level jQuery function. jQuery likes to keep it clean :)

[kflorence]

As it should, I think this plugin is already polluting a bit too much for jQuery's liking. Why can't everything just be namespaced under jQuery.global (or "glob")? (jQuery.global.cultures, jQuery.global.localize, etc)

[InfinitiesLoop]

It could. Some have suggested that. On the other hand, it makes it pretty verbose, and you could think of this as a horizontal feature that aught to appear more integrated. Either way it will likely change...

[kflorence]

I suppose. Yeah can't think of any other way to do it at the moment, but if it becomes more integrated into jQuery I guess it would work itself out. After a quick glimpse through the code, the whole jQuery integration aspect still needs quite a bit of work. It looks like it was developed as a framework independent project and then quickly patched to make it fit under the jQuery namespace as an afterthought (which seemed a bit odd to me considering it now resides under the jQuery repository).

Anyways, I understand this is still a very young project, just thought I would give my two cents. Oh, and thanks for the civil conversation! Appreciated.

[InfinitiesLoop]

Just the opposite actually. It was exclusively jQuery, but in the end, it didn't really depend on jQuery for much of anything. Many felt it should be stand-alone, so we added that as an option.

As for deeper integration, there are lots of things we can do. Young project, yes :) Thanks for your feedback.

[jzaefferer]

Closing this ticket as there's really no reason to change the file formats.