We can have resource="ExampleUiLabels" where ExampleUiLabels.xml is the OFBiz custom format that
contains ALL translations,
-or-
we can have resource="ExampleUiLabels" where properties files are any combination of Java xml format
files or *.properties files.
So, this would work:
ExampleUiLabels_ru.xml (Java xml format)
ExampleUiLabels_en.properties
ExampleUiLabels.xml (Java xml format)
-Adrian
Scott Gray wrote:
Oh ok I see, so we can either have this:
resource="ExampleUiLabels"
ExampleUiLabels_ru.xml
ExampleUiLabels_en.xml
but *not* ExampleUiLabels.xml
or this:
resource="ExampleUiLabels"
ExampleUiLabels_ru.properties
ExampleUiLabels_en.properties
ExampleUiLabels.properties
or this:
resource="ExampleUiLabels.xml"
ExampleUiLabels.xml
but no combination of the above, correct?
Regards
Scott
On 03/01/2008, Adrian Crum <[EMAIL PROTECTED]> wrote:
Scott Gray wrote:
Ok I understand what you're trying to achieve, not going to work with
the
current code though, if the resource string ends with .xml we're only
ever
going to be able to find ExampleUiLabels.xml, but if we take it out then
anything contained with ExampleUiLabels.xml will never be found. In the
list for "ru" below, by the time you get to ExampleUiLabels.xml the file
is
found but then is searched for the locale "".
Regards
Scott
Exactly! We can mix *.properties and *.xml files if the *.xml files are in
the Java xml file format.
By having the custom format, we have to choose one way or the other - we
can't have both.
I'm sure the custom xml format idea will be refined as time goes on. Maybe
someone can come up with
a better resolver strategy.
It will be interesting to see how the community reacts to the two xml file
formats. Personally, I
don't have a strong leaning either way. The Java xml file format is a
standard and operates the same
as the *.properties file format, but on the other hand having all
translations in a single file has
benefits too.
-Adrian
On 03/01/2008, Adrian Crum <[EMAIL PROTECTED]> wrote:
Scott Gray wrote:
Ok thanks for checking up on it, I had assumed that if we could find
ExampleUiLabels.xml then that would contain all of the available locale
translations end of story.
That would be true if we supported only one xml format. With our custom
xml format,
ExampleUiLabels.xml could be one of two formats.
So for example are you saying that if the local
is "ru" it should try and find ExampleUiLabels_ru.properties before
looking
at ExampleUiLabels.xml?
Using the current UtilProperties resolver code, resource =
"ExampleUiLabels" and locale = "ru" and
server locale = "en", here are the candidate file names in order:
ExampleUiLabels_ru.xml
ExampleUiLabels_ru.properties
ExampleUiLabels_ru
ExampleUiLabels_en.xml
ExampleUiLabels_en.properties
ExampleUiLabels_en
ExampleUiLabels.xml
ExampleUiLabels.properties
ExampleUiLabels
So, the resolver code works just like ResourceBundle.getBundle(...)
except
it also checks for xml
files. Without the ".xml" extension embedded in the resource name, the
code assumes each file
contains only one locale. That's how we maintain compatibility with
existing properties files.
I figured we were supporting one style or the other but not both for
the
same resource, or am I completely missing what your saying?
Ideally, we should support the Java standard properties file formats in
addition to our own. Some
shops might frown on "proprietary" file formats and prefer to use the
Java
standards.
-Adrian
Scott
On 03/01/2008, Adrian Crum <[EMAIL PROTECTED]> wrote:
Scott,
Thank you for taking care of the "ripple effect" of the recent
UtilProperties changes. This commit
breaks the properties file resolver code however. Java xml properties
files use the same naming
convention as *.properties files (resource_locale.xml).
I'll go into a little detail here for the benefit of anyone
interested.
Getting UtilProperties.java to support multiple properties file
formats
was no easy task. Each
format must be resolved along with a specified locale. The Java
properties
file naming convention
makes the process pretty straightforward and simple:
http://java.sun.com/j2se/1.4.2/docs/api/java/util/ResourceBundle.html#getBundle(java.lang.String,%20java.util.Locale,%20java.lang.ClassLoader)
but adding in the OFBiz custom XML file format throws a wrench in the
machinery. If the resource
"ExampleUiLabels" and locale "en_US" resolve to "ExampleUiLabels.xml"
-
how do we know if that xml
file is "resource of last resort" found in the getBundle(...) strategy
mentioned in the link, or if
it's an OFBiz custom xml file that contains multiple locales? I
couldn't
think of any way to
differentiate between the two except to specify the ".xml" in the
resource
name of the OFBiz custom
xml file format.
So, a better way to solve the problem in the Example component would
be
to
change all
resource="ExampleUiLabels"
to
resource="ExampleUiLabels.xml"
which will enable UtilProperties to resolve and process the OFBiz
custom
file format.
-Adrian
[EMAIL PROTECTED] wrote:
Author: lektran
Date: Tue Jan 1 02:50:01 2008
New Revision: 607823
URL: http://svn.apache.org/viewvc?rev=607823&view=rev
Log:
Fixed a small problem with the new xml uiLabels, fail-property in
minilang wasn't able to retrieve any xml properties.
Modified:
ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilProperties.java
Modified:
ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilProperties.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilProperties.java?rev=607823&r1=607822&r2=607823&view=diff
==============================================================================
---
ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilProperties.java
(original)
+++
ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilProperties.java
Tue Jan 1 02:50:01 2008
@@ -665,6 +665,7 @@
if (UtilValidate.isEmpty(resource)) {
throw new IllegalArgumentException("resource cannot be
null
or empty");
}
+ // This is for *.properties files only (not *.xml files)
String resourceName = createResourceName(resource, locale);
if (propertiesNotFound.contains(resourceName)) {
return null;
@@ -679,7 +680,7 @@
}
}
// Check for XML properties file next
- url = FlexibleLocation.resolveLocation(resourceName +
".xml");
+ url = FlexibleLocation.resolveLocation(resource +
".xml");
if (url != null) {
return url;
}
