Each package should have a singleton package-private message catalog + * + *
Each package should have a singleton package-private message catalog * class. This ensures that the correct class loader will always be used to - * access message resources, and minimizes use of memory:
+ * access message resources, and minimizes use of memory:+ * + ** package some.package; - * + * * // "foo" might be public * class foo { * ... @@ -59,14 +59,14 @@ * } * ... * } - *- * - *Messages for a known client could be generated using code - * something like this:
+ *+ * + *Messages for a known client could be generated using code + * something like this:
* String clientLanguages []; * Locale clientLocale; * String clientMessage; - * + * * // client languages will probably be provided by client, * // e.g. by an HTTP/1.1 "Accept-Language" header. * clientLanguages = new String [] { "en-ca", "fr-ca", "ja", "zh" }; @@ -75,27 +75,27 @@ * "fileCount", * new Object [] { new Integer (numberOfFiles) } * ); - *- * - *At this time, this class does not include functionality permitting + *
At this time, this class does not include functionality permitting * messages to be passed around and localized after-the-fact. The consequence * of this is that the locale for messages must be passed down through layers * which have no normal reason to support such passdown, or else the system - * default locale must be used instead of the one the client needs. - *
- *
The following guidelines should be used when constructiong + * multi-language applications:
+ *getMessage call. This lets your
* applications use IETF standard locale names, and avoids needless
- * use of system defaults.
- *
- * java.util.ListResourceBundle.
- *
- * java.util.ListResourceBundle.The "resources" sub-package can be treated separately from the + * as eliminating or improving messages) to break another package.
The "resources" sub-package can be treated separately from the * package with which it is associated. That main package may be sealed * and possibly signed, preventing other software from adding classes to * the package which would be able to access methods and data which are @@ -127,7 +126,7 @@ * (text and class files) need to be added to some package. Since they * should not be added to the main package, the "resources" subpackage is * used without risking the security or integrity of that main package - * as distributed in its JAR file. + * as distributed in its JAR file.
* * @author David Brownell * @version 1.1, 00/08/05 @@ -281,11 +280,11 @@ * languages is supported, a null value is returned. Such a list of * languages might be provided in an HTTP/1.1 "Accept-Language" header * field, or through some other content negotiation mechanism. - * - *The language specifiers recognized are RFC 1766 style ("fr" for + * + *
The language specifiers recognized are RFC 1766 style ("fr" for * all French, "fr-ca" for Canadian French), although only the strict * ISO subset (two letter language and country specifiers) is currently - * supported. Java-style locale strings ("fr_CA") are also supported. + * supported. Java-style locale strings ("fr_CA") are also supported.
* * @param languages Array of language specifiers, ordered with the most * preferable one at the front. For example, "en-ca" then "fr-ca", @@ -335,7 +334,7 @@ // language code ... if already lowercase, we change nothing if (len == 2) { - lang = lang.toLowerCase(); + lang = lang.toLowerCase(Locale.ENGLISH); if (lang != languages[i]) { if (!didClone) { languages = (String[]) languages.clone(); @@ -437,7 +436,7 @@ * Returns true iff the specified locale has explicit language support. * For example, the traditional Chinese locale "zh_TW" has such support * if there are message bundles suffixed with either "zh_TW" or "zh". - * + * * This method is used to bypass part of the search path mechanism
* of the ResourceBundle class, specifically the parts which
* force use of default locales and bundles. Such bypassing is required