<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Chris Umphress wrote:
<blockquote
cite="mid1f29b8940510312141q65edad5cj2ee4e8e98df46cc9@mail.gmail.com"
type="cite">
<pre wrap="">On 10/31/05, Yiguang Hu <a class="moz-txt-link-rfc2396E" href="mailto:yighu@yahoo.com"><yighu@yahoo.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">About the encoding/book names. I am just wondering why
the standard java resource bundle is not used ?
For encoding, UTF-8 should be able to cover all the
languages. I knew it covers MBCS like Japanese,
Chinese and Korean (Usually KJC for short) well. It
should not be a issue with any of the western
characters, most of them just single byte chars.
</pre>
</blockquote>
<pre wrap=""><!---->
Perhaps not everyone uses Java ;-)
</pre>
</blockquote>
So true. However, Java's resource bundle can be thought of as a design
pattern. Its basic design is worthy of consideration for any language.
C++ does not support internationalization or localization. It is an
afterthought at best. However, this is part of the design of Java from
the start. I have implemented most of this design in Perl.<br>
<br>
The only advantage that I see in implementing ResourceBundles for C++
is that the same files can be used by both Java and C++. I bet that
there is C++ code out there that can use Java ResourceBundles.<br>
<br>
Here is the specific design:<br>
A resource bundle consists of a set of property files (or classes, but
I'm not going into that) that follow a naming convention. A property
file consists of blank lines, comment lines and data lines of the form:
key=value. Every property file has the extension (aka suffix)
'.properties'.<br>
<br>
The base or default property file for Bible book names might be
something like booknames.properties. For each localization of the set
of properties there is a file whose name is of the form,
booknames_xx.properties or booknames_xx_YY.properties, where xx is the
2-character, lower case, language code and YY is the 2-character, upper
case, country code. The resource bundle is merely known as "booknames".
For a user in a given locale, say German speaking Switzerland, the
lookup would proceed as follows: See if the key exists in
booknames_de_CH.properties. If that fails (either because the file did
not exist or the key was not present), then look for it in
booknames_de.properties. Failing that look in booknames.properties.
Failing that throw an exception. When found, return the value.<br>
<br>
>From this it can be seen that booknames_de_CH.properties does not need
to have every key in it. It only needs to do it differently when the
entry is different from what is in booknames_de.properties.<br>
<br>
A design aspect of property files is that they must be encoded in
ISO-8859-1 (not cp1252 or UTF-8). Any character not in Latin-1 needs to
be represented with a Unicode escape of the form \udddd where dddd is
the 4 digit UTF-8 code point. It almost requires an UI to manage the
file's contents.<br>
<br>
Another aspect of resource bundles is its mechanism for locating the
files themselves. The assumption is that the properties belong to a
class. So the properties are looked up in the same path as the class.
This means that it searches the classpath (which gives the root
directories in which to look for the path) for the file. The file can
either be in subdirectories down from a root or the file can be named
with '.' instead of '/' and be physically located in a classpath
directory. And the mechanism will look in zip files (and jars) and
uncompress found property files as needed. For JSword, we have extended
this mechanism to add additional directories to the ones in the
classpath.<br>
<br>
All in all, I see that the design of ResourceBundles is well-defined
and fairly complete. My biggest complaint is that a default locale's
ResourceBundle can only be read once in a program. That is each
"creation" of a ResourceBundle will get the internally cached copy.
This means that it is not possible to change default locales inside of
the program without restarting the program to have it take effect. Also
I find that the implementation in Sun's Java is heavy and wanting.<br>
<br>
<br>
<blockquote
cite="mid1f29b8940510312141q65edad5cj2ee4e8e98df46cc9@mail.gmail.com"
type="cite">
<pre wrap="">
C/C++ still requires significantly fewer resources, and is more widely
used from what I have seen. Java is more portable, and is a big hit in
colleges right now, but also requires more resources and a slightly
faster processor to achieve the same speed.
</pre>
</blockquote>
I beg to differ on the speed issue. At my previous company, we took a C
program that was taking 4 hours to run and re-wrote it in Java. The end
result was that it took 1 hour to run on the same hardware. We then
moved it from a Sun 4-way multi-processor with gobs of memory to a
single cpu desktop and the time dropped to 1/2 hour.<br>
<br>
I rewrote a C++ program into Perl and went from 24+ hours worst case to
1 hour worst case and from 2 hours normal case to 1/2 hour normal case.
The memory footprint was 1/10 in Perl. Again, on the same hardware.<br>
<br>
In both cases the difference was that the programs were re-written to
take advantage of the language's architecture and strengths. And of
course, the pitfalls of the earlier designs were avoided.<br>
<br>
IMHO, it is usually dumb to port from one language to another. It is
better to re-write to a better design.<br>
<blockquote
cite="mid1f29b8940510312141q65edad5cj2ee4e8e98df46cc9@mail.gmail.com"
type="cite">
<pre wrap="">
On the other hand, you are right -- UTF-8 is the way to go :-)
--
Chris Umphress <a class="moz-txt-link-rfc2396E" href="http://daga.dyndns.org/"><http://daga.dyndns.org/></a>
_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
</body>
</html>