Due to lack of resources, the plugin has received little or no attention lately… If you would like to volunteer by helping on the plugin development, please contact me to become a project committer!

The page below is now locked for editing and commenting, and will be kept here only for historic purposes. Please use the new project page for creating issues, providing feedback, etc…

About

jQuery.i18n.properties is a lightweight jQuery plugin for providing internationalization to javascript from ‘.properties’ files, just like in Java Resource Bundles. It loads and parses resource bundles (.properties) based on provided language and country codes (ISO-639 and ISO-3166) or language reported by browser.

Resource bundles are ‘.properties‘ files containing locale specific key-value pairs. The use of ‘.properties‘ files for translation is specially useful when sharing i18n files between Java and JavaScript projects. This plugin loads the default file (eg, Messages.properties) first and then locale specific files (Messages_pt.properties, then Messages_pt_PT.properties), so that a default value is always available when there is no translation provided. Translation keys will be available to developer as javascript variables/functions (functions, if translated value contains substitutions (eg, {0}) or as a map.

This plugin was inspired on the Localisation assistance for jQuery from Keith Wood, and is made available under a dual license (GPL and MIT).

Features

• Use Java standard ‘.properties‘ files for translations
• Use standard ISO-639 for language code and ISO-3166 for country code
• Sequential loading of resource bundles from base language to user-specified/browser-specified so there is always a default value for an untranslated string (eg: msg.properties, msg_pt.properties, msg_pt_PT.properties)
• Use browser reported language if no language was specified
• Placeholder substitution in resource bundle strings (eg, msg_hello = Hello {0}!!)
• Suport for namespaces in keys (eg, com.company.msgs.hello = Hello!)
• Support for multi-line property values
• Resource bundle keys available as Javascript vars/functions or as a map

Example

Take as an example the following Messages.properties, Messages_pt.properties and Messages_pt_PT.properties:

Messages.properties

Messages_pt.properties

Messages_pt_PT.properties

Now, suppose these files are located on the ‘bundle/‘ folder. One can invoke the plugin like below:

This will initialize the plugin (loading bundle files and parsing them) and show a dialog box with the text “Olá World” and other with “Good morning John!”. The english word “World” is shown because we didn’t provide a translation for the msg_world key. Also notice that keys are available as a map and also as javascript variables (for simple strings) and javascript functions (for strings with placeholders for substitution).

Usage

Options

Including and invoking the plugin

1. Load the script:

   1 2	<script type="text/javascript" language="JavaScript"   src="js/jquery.i18n.properties-min.js"></script>

2. Initialize the plugin (minimal usage, will use language reported by browser), and access a translated value (assuming a key named ‘org.somekey‘ exists):

   1 2 3 4

   jQuery.i18n.properties({   name: 'Messages',   callback: function(){ alert( org.somekey ); } });

Demo

See a small demonstration

Download

1.0.8  [2010-07-09]

• jquery.i18n.properties.js (13 KB)
• jquery.i18n.properties-min.js (3.3 KB)

Change Log

1.0.8  [2010-07-09]

• Fixed IE bug caused by the MS buggy implementation of String.split() method

1.0.7  [2010-06-09]

• Added support for multi-line properties
• Prevent browser caching of old property files

1.0.6  [2010-03-28]

• Fixed checkKeyNamespace issue (FF only)
• Fixed issue that truncated values when containing ‘=’ symbol
• Added demo page

1.0.4  [2009-12-29]

• When using the map approach to retrieve bundle values, unicode chars may not be properly unescaped

1.0.3  [2009-10-06]

• When using the map approach to retrieve bundle values, if there’s no value for a specified key, key is returned (previously, null was returned)
• Fixed lot of errors accordingly to JSLint

1.0.2  [2009-09-18]

• Option to have resource bundle keys available as Javascript vars/functions AND/OR as a map. The later is mandatory if your bundle keys contain Javascript reserved words

1.0.1  [2009-09-14]

• Keys with namespaces doesn’t work
• Values with quotation mark (“) break the code

Known issues

• Cross-site requests not allowed (see Same Origin policy).
• Local file requests (file://) may fail in some browsers (Chrome Issue 40787)
• Having HTML elements with IDs equal to key values in .properties files will fail on some browsers (IE, Chrome) when values are not accessed through jQuery.i18n.prop() method.
  Example:

  1 2 3 4

  <!-- on HTML file: -->   <div id="test123">ola</div>   # on .properties file:   test123 = qwerty

  Executing “alert(test123);” will output the div object with id “ola” and not the “qwerty” string!

For more information, please consult the SiteStats official page.

SiteStats 2.0 release information:

• List of features
• Screenshots
• Installation guide
• Configuration options

This approach consists in checking for the existence of the sakai kernel-deploy/ module, only available on K1 builds. Basically, instead of checking for the ../kernel-deploy/pom.xml file (which fails for cases where optional tools are not downloaded to the Sakai source folder) we will be checking for ../master/../kernel-deploy/pom.xml. This works for standard and non-standard source folder layouts (where linking to pom.xml and master/ is required) because the way the OS follow symlinks:

So, in your pom.xml files, you implement profile auto-activation as follows:

… et voilá! You may want to read through Steve Swinsburg blog entry to implement the set of dependencies for each profile! Alternatively, you may want to read Steve’s post about this profile auto activation approach!

The workaround

A simple workaround is to partition this parameter list in smaller lists with a maximum of 1000 elements (the oracle limit). Example, using HQL syntax (the Hibernate Query Language):

The workaround: Java implementation

If you’re programming in Java, you can build the HQL query and pass its parameters as described below:

Watch Code Swarm: Sakai Contrib-UFP  |  View More Free Videos Online at Veoh.com

Changes

• Improved SiteStats API (for 3rd party tools);
• New presentation framework: Apache Wicket instead of JSF;
• Automatic event registration for tools implementing the new Statisticable capability of EntityBroker – this allows SiteStats to pick up interesting events to get statistics on, as well as localized event descriptions provided by the tool developer and/or provided by SiteStats;
• Ability to save report definitions per site for posterior execution;
• Ability to provide predefined report definitions through the admin version of the tool – these will be listed on every site’s SiteStats instance;
• More powerful and customizable reports: ability to select columns to group by results (which allows, for example, to list most opened files or students who have done only a particular action);
• Redesigned reports page to accomodate new reporting parameters;
• Added possibility of presenting reports data in table and/or chart format;
• Preliminary support for sakai-wide reports: ability to report agains all sites in sitestats admin version (like “Top 10 most accessed resources across sites” or, “Most used tools across site”);
• Completely redesigned start page with compact view, offering a lot of usefull information over the current version (STAT-126) – most instructor/site maintainer questions will be answered on this page;
• And more…

Screenshots

HTML

CSS

However, there is a problem with this command: new files won’t be added to generated patch! This happens because we often forget to execute a very simple command prior to ‘svn diff’ – svn add!