[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Java Property Resource Bundles
Hi All,
The following thread addresses Java Property Resource Bundles in XLIFF.
It discusses list resource bundles only obliquely. Anny comments?
Thanks,
john
---------------------------------------------------
J o h n R e i d
Localization Tools
Novell, Inc.
JREID@novell.com
801/861-3855 ( Voice)
801/861-2754 ( Fax )
----------------------------------------------------
>>> John Reid 3/11/04 7:22:42 PM >>>
Hi Tony & Justin,
I haven't had a chance to really address the issues involved with Java
ResourceBundles. My initial impression is that the handling of
PropertyResourceBundles can be rather simple since the properties file
is a key-value table much like the StringTable of the Win32 Resource
format. Following that work:
-Each properties file is a separate <file>
-The datatype of <file> is "javapropertyresourcebundle".
-The <body> contains the <trans-unit>
-A <trans-unit> is created for each key-value pair.
-The <trans-unit> id attribute value is serially assigned according the
retreival order to maintain consistency and uniqueness of the trans-unit
id attribute value.
-The key of the property becomes the resname attribute value of the
<trans-unit>.
-The translate attribute value of null strings is 'no' in the
<trans-unit>.
-The value string becomes the content of the child source element.
In addition, I propose the following:
-MessageFormat replaceables are masked with inline element <ph> with
consecutive ids.
Using MessageBundle_en_US.properties from Sun as the example, the
properties file contains the following key-value pairs:
template = At {2,time,short} on {2,date,long}, we detected \
{1,number,integer} spaceships on the planet {0}.
planet = Mars
The resulting MessageBundle_en_US.properties.xlf would be as follows.
<?xml version="1.0"?>
<xliff version='1.1'
xmlns='urn:oasis:names:tc:xliff:document:1.1'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:schemaLocation='urn:oasis:names:tc:xliff:document:1.1
xliff-core-1.1.xsd'>
<file source-language="en_US" datatype="javapropertyresourcebundle"
original="MessageBundle_en_US.properties">
<body>
<trans-unit id="1" restype="string" resname="template" >
<source>At <ph id="1">{2,time,short}</ph> on <ph
id="2">{2,date,long}</ph>, we detected <ph
id="3">{1,number,integer}</ph> spaceships on the planet <ph
id="4">{0}</ph>.</source>
</trans-unit>
<trans-unit id="1" restype="string" resname="planet" >
<source>Mars</source>
</trans-unit>
</body>
</file>
</xliff>
Unfortunately, unless we know that the contents of the curly braces
(e.g. {1,number,integer}) is a message format, we can only present it
as part of the string using Sun's notation. We could assume that any
text contained within curly braces within a value is a replaceable value
but then valid uses of the curly braces in text would be mismarked. (To
know the purpose of the curly-brace-enclosed message format, we would
need to read through the ResourceBundle code. This somewhat negates the
advantages gained by the properties file. This is further exacerbated by
their proposal for handling plurals, which definitely requires reading
both files.) By only masking the the message format string, that string
is still available for translation. If the ResourceBundle file is read
and the string is a MessageFormat, a translate="no" attribute can be
added to the <ph> element. We may even want to make that default
behavior, which would force that attribute to be unset when the string
is mismarked.
What do you think?
-jr
---------------------------------------------------
J o h n R e i d
Localization Tools
Novell, Inc.
JREID@novell.com
801/861-3855 ( Voice)
801/861-2754 ( Fax )
----------------------------------------------------
>>> Tony Jewtushenko <Tony.Jewtushenko@oracle.com> 3/9/04 8:23:59 AM
>>>
Hi John:
I wonder if you could help with Justin's query. I am presently working
on the ResourceBundle profile, but haven't addressed this matter yet.
Can you please copy me on reply, so I can add it to the profile. If
you haven't dealt with this yet, I'll foward to the XLIFF TC and see
if anyone has any good suggestions.
Thanks,
Tony
Justin Erik Tilton wrote:
>Tony,
>
>In our prior correspondence you mentioned an XLIFF guidelines doc for
>java resource bundles. I was wondering if I could take a look at it?
In
>particular, I am looking for a recommendation for handling
dynamically
>generated compound messages. Sun describes how this is done in java
>here:
>
>http://java.sun.com/docs/books/tutorial/i18n/format/messageFormat.html
>
>I'm looking for a best practice for translatable units that are
>"compound messages" in our XSLT skeleton files - using XLIFF as an
>external translation memory.
>
>When we first spoke months ago, we were developing a build time
script
>using a skeleton XSLT to generate XLIFF files for each locale then
using
>the XLIFF and XSLT skeleton to generate localized XSLT files (all due
to
>performance concerns). Now we have a caching solution that will allow
us
>to do run-time generation - so I am leaning toward John Reid's
approach
>using variables in the XSLT with cooresponding IDs in the XLIFF. I
was
>wondering if you thought John would be the best resource to ask about
a
>compound message technique or if you might have another contact that
>could help me with this?
>
>I had a hard drive crash a couple of months ago, and lost my contact
>list, so if you would pass my email address along to John or anyone
else
>for assistance it would be most appreciated...
>
>Thank you,
>Justin
>
>
>
>
>
>
>On Fri, 2004-02-13 at 10:08, Tony Jewtushenko wrote:
>
>
>>Hi Justin:
>>
>>I'm glad my email response was of use to you. And thanks for the
>>explanation - it's good to know you're not rejecting XLIFF due to
>>technical problems. Hopefully we can help you implement an XLIFF
>>solution during the short window of opportunity.
>>
>>Regarding the resource guides - they are in "draft" form only at
this
>>point, but you're welcome to review the work in progress and
provide
>>comments or questions. The two guides that you might find useful
are:
>>
>>Windows 32:
>>http://lists.oasis-open.org/archives/xliff/200312/msg00011.html
>>HTML: :
>>http://lists.oasis-open.org/archives/xliff/200402/msg00008.html
>>
>>I have some very very informal information on representing java
>>resource bundles - let me know if this is of interest to you now,
>>however a draft will be published in the next couple of weeks if
you
>>can hold on 'til then.
>>
>>You can send queries and comments on these guides to the TC comment
>>mailing list - xliff-comment@lists.oasis-open.org
>>
>>Regards,
>>Tony
>>
>>
>>Justin Erik Tilton wrote:
>>
>>
>>>Tony,
>>>
>>>Thank you very much for the detailed information. I am very pleased
to
>>>hear the progress and get caught up on the latest information.
>>>
>>>Let me explain my earlier statement. I developed an i18n proof of
>>>concept for the uPortal project last year using XLIFF, but due to
>>>another pressing project and delays in the framework code, did not
have
>>>time to push it into the project. In the meantime, developers were
>>>working on the framework, fixing some unicode issues and building
the
>>>methods to prioritize and select localizations etc. To test their
work,
>>>they began using java resource bundles and have I short window of
>>>opportunity to reiterate/demonstrate the power of XLIFF as a
>>>replacement. I am doing this now.
>>>
>>>Are any of your resource guides available at this time? I would be
quite
>>>interested to see what is emerging as "best practice".
>>>
>>>Take care,
>>>Justin
>>>
>>>
>>>
>>>On Fri, 2004-02-13 at 05:28, Tony Jewtushenko wrote:
>>>
>>>
>>>
>>>>Hi Justin:
>>>>
>>>>We released XLIFF 1.1 back in May 2003, and successfully completed
open
>>>>peer review in October 2003. Our present focus for the near term
(3+
>>>>months) is to author non-normative "representation guides" for how
to
>>>>transform standard resources types (HTML, Windows, etc) to XLIFF.
>>>>We'll be submitting XLIFF 1.1 to formal OASIS standards review only
>>>>after we've completed that work.
>>>>
>>>>According to the rules of OASIS, once a technical committee has
>>>>completed its stated deliverables as per its charter, it must
either
>>>>"refine" its charter, or shut itself down - possibly resuming at a
>>>>future date. So the "placing the TC in holding pattern" agenda
item on
>>>>our annual Dec 2003 Face to Face meeting was an option between
these two
>>>>polar extremes. The "holding pattern" meant that we would not
terminate
>>>>the TC or extend the charter, but rather agree to a rota for
monitoring
>>>>the mailing lists, and schedule regular meetings only on a
quarterly
>>>>basis, and meet more frequently if necessary. We presently meet
>>>>monthly. Ultimately we decided that we have plenty of work to keep
us
>>>>busy for the next 6 months, so no changes will be made for at
least
>>>>that amount of time. We also agreed not to start working on an
XLIFF
>>>>2.0 (or 1.2) until 1.1 has had a reasonable period of time to be
>>>>understood and implemented throughout the industry. Bugs will of
course
>>>>be addressed immediately.
>>>>
>>>>As to adoption of XLIFF, there have been announcements from 2
major
>>>>tools vendors (Alchemy Software's Catalyst, and PASS Engineering's
>>>>Passolo) that they now provide support visual XLIFF editing.
Idiom
>>>>World Server has announced support in their next version. The
industry
>>>>leading tool developer (can't divulge the name yet) is in
discussions
>>>>with our TC on implementation of XLIFF, as well as joining the TC.
Our
>>>>TC membership has been stable and in fact is growing (XML INTL,
and
>>>>PASS Engineering have joined). Industry-wide, XLIFF is clearly
moving
>>>>from early adopter to the mainstream adoption phase.
>>>>
>>>>I'm somewhat concerned by your statement that uPortal is
"revisiting our
>>>>use of XLIFF for i18n purposes" - does this mean you're not
satisfied
>>>>with some aspect of XLIFF, or is this just part of your normal
review
>>>>process? If you've got problems with XLIFF, I'm sure members of
the
>>>>TC would be happy to provide direct support to your efforts.
Could you
>>>>please expand on your statement?
>>>>
>>>>Regards,
>>>>Tony
>>>>
>>>>
>>>>Justin Erik Tilton wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Tony,
>>>>>
>>>>>Justin Tilton here - from the uPortal project. We are revisiting
our use
>>>>>of XLIFF for i18n purposes, and I was wondering if you could give
me a
>>>>>brief update on the status. I noticed from your December agenda
that one
>>>>>of the items was "Place TC in holding pattern"... What should I
make of
>>>>>this :)
>>>>>
>>>>>Take care,
>>>>>Justin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>--
>>Tony Jewtushenko mailto:tony.jewtushenko@oracle.com
>>Principal Product Manager direct tel: +353.1.8039080
>>Oracle Corporation, Ireland
>>
>>
>
>
>
--
Tony Jewtushenko mailto:tony.jewtushenko@oracle.com
Principal Product Manager direct tel: +353.1.8039080
Oracle Corporation, Ireland
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]