Completely mimic the Java Resource Bundle

[GoogleCodeExporter]

From Matthew Lohbihler: 

Note that the behaviour of this plug-in is not quite like resource bundles in 
Java. (I’m assuming that this is the goal.) In particular, single quotes are 
used to escape { and }. Also, double quotes end up with a preceding “\” 
character. For example, if your properties are:

{{{
test.t1=asdf ”{0}”
test.t2=asdf ‘{0}’
test.t5=This is “a quote”
}}}

… Java will produce:

{{{
asdf ‘p1′
asdf {0}
This is “a quote”
}}}
… while this plugin will produce:
{{{
asdf ”p1”
asdf ‘p1′
This is \”a quote\”
}}}

This plugin is so very useful when used with a Java server, so it would be 
wonderful if these discrepancies could be resolved.

Original issue reported on code.google.com by nfgr...@gmail.com on 22 May 2011 at 11:37

[GoogleCodeExporter]

Original comment by nfgr...@gmail.com on 22 May 2011 at 11:41

[GoogleCodeExporter]

I went ahead and made a bunch of code changes to this since i needed them for a 
current project. I can make edits in an SVN or post the code somewhere, 
whatever is convenient.

Original comment by mlohbih...@numenta.com on 24 May 2011 at 2:42

[GoogleCodeExporter]

Hi Matthew!

Yes, please go ahead and edit in svn directly!

Thanks,
Nuno

Original comment by nfgr...@gmail.com on 24 May 2011 at 6:26

[GoogleCodeExporter]

Hi Nuno,

I've committed my changes to SVN. Some notes about what was done:

1) The main effort was in making the code work in a more consistent way to how 
property resource bundles are parsed in Java, and how MessageFormat works for 
parameterization. My main concern was with the "map" mode. (Please note that i 
have not properly tested the effects of my changes on "vars" node; the intent 
was for that to be unchanged.) Due to problems with escaping "{" and "}" 
characters, i had to fundamentally change the way the package works. Much of 
the file parsing is the same. The the result of loadAndParseFile is still to 
create a map of keys and strings, but the strings are relatively unprocessed. 
These strings are lazily converted into lists of strings and integers upon 
first reference, where the strings are literal parts and the integers are 
references to parameters. Parsing is done by scanning through the string 
(twice) rather than using regex.

2) I added a "cache" parameter to the settings, so issue #4 should be resolved.

3) The $.i18n.prop function no longer accepts a list of placeholders. This is a 
non-backward compatible change, which i was reluctant to commit, but i believe 
also helps in making the package more Java-like. So, instead of t("myKey", [p1, 
p2, p3]), you now use t("myKey", p1, p2, p3). The "arguments" variable is used 
to find the parameters.

4) I added "encoding" to the settings as well, since by spec property resource 
bundles are supposed to be in IOS-8859-1 format. The server should, i suppose, 
return the proper encoding anyway, so maybe this is unnecessary.

Original comment by m...@serotoninsoftware.com on 25 May 2011 at 2:18

[GoogleCodeExporter]

Original comment by m...@serotoninsoftware.com on 25 May 2011 at 2:21

• Changed state: Fixed

[GoogleCodeExporter]

Hi Matthew!

Your changes looks pretty good!

I have checked out and made some tests, but couldn't make it work for 
multi-placeholder keys (tested on IE and FF). I have adapted the examples code 
(index.html) on trunk so you can also check: only the last placeholder is 
actually replaced! Could you please check this?

Also, for the 3) change, I wonder if it would be possible to check if the 2nd 
argument is actually a string array (instead of a string) and, on this case, 
process it like before (for backwards-compatibility)?

Thank you very much for your huge commit!
Nuno

Original comment by nfgr...@gmail.com on 26 May 2011 at 8:46

[GoogleCodeExporter]

Hi Nuno,

The {0} placeholder is not replaced because it is considered to be in a quoted 
string. Note that the apostrophes in "it's" and "let's" do not appear either. 
Apostrophes are not escaped with "\", but rather with "''". (I ran this in a 
Java-based test, and the results were the same.) I've added a corrected version 
of the message value to index.html and checked it in. I agree that it is 
strange that "\" would not escape quotes.

Regarding 3), yes, that is possible. The only issue is that if you wanted to 
provide an array as a single placeholder parameter, you would only see the 
first element. This should be a rare occurence though. Alternatively, we could 
add a backward compatibility flag to the settings which would have the package 
expect an array of parameters. That might be cleaner.

Regards,
Matthew

Original comment by m...@serotoninsoftware.com on 26 May 2011 at 2:17