OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff] XLIFF: feedback on draft for Java profile

My comments following [Tony] marker below... 

-----Original Message-----
From: Lieske, Christian [mailto:christian.lieske@sap.com] 
Sent: 27 September 2005 16:41
To: xliff@lists.oasis-open.org
Subject: [xliff] XLIFF: feedback on draft for Java profile

Dear all,

Presumably, many benefits can be harvested if a recommended way for
representing Java-related resources (such as Java properties files) in an
XLIFF setting exists. Accordingly, I would like to provide feedback on the
draft (see details below) ...

Best regards,

P.S.: I refer to

1. Differentiate between different Java platforms/versions

I suggest to be as specific as possible about the Java platform (J2SE, J2EE,
J2ME ...) which is addressed. In a similar vein, information about a
specific version also might be help since e.g. J2SE 1.4 is somewhat
different from Java 5 (see next remark).

[Tony] Good suggestion - will specify J2SE 1.4

2. Adress XML-based properties

J2SE (Java 5) provides native support for XML-based properties; cf.


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd";;>
<entry key="java.runtime.name">Java(TM) 2 Runtime Environment, Standard
Edition </entry> <entry
<entry key="java.vm.version">1.5.0-beta-b32c</entry>
<entry key="java.vm.vendor">Sun Microsystems Inc.</entry> <entry
<entry key="path.separator">;</entry>
<entry key="sun.desktop">windows</entry>
<entry key="sun.cpu.isalist">pentium i486 i386</entry> </properties>

I suggest to address this accordingly (e.g. by adding an XML-based example,
and adapting the statements about the possibilities for XSL-based

[Tony] Yes,  we will have to support this as well.  We will add an XML based

3. Provide pointers to Java pages on internationalization

One reference which from my understanding could complement our sketch of the
topic would be


It mentions some aspects which we may want to cover in the introductory
section for the profile:

	Take care to internationalize your application and do not
concatenate strings for
	example but rather follow the guidelines related to messages; cf.

[Tony]Good suggestion.  I will add some of this text to an introductory

4. Sketch the Extract&Merge Paradigm ====================================

I am under the impression that a sketch of the paradigm would help people to
understand the relationships and processes related to original language
native format, XLIFF and source language native format.

[Tony]We didn't sketch it out in any of the other profiles (HTML, etc) -
sketches are available in the FAQ.  I think if we have to change it here
we'll have to change it everywhere.

5. Handling of references (especially to non-textual resources)

I guess properties like the following are quite common:


Here, the second line points to an icon and a specific directory.

Presumably, it would be beneficial to address this. Two possibilities come
to mind

	A. Tell people not to do it
	B. Recommend a specific encoding

[Tony]I'm not sure I understand the problem, or your suggestion about
encoding.  Java properties files must be encoded as 8859-1 - any character
outside that char set must be represented using escaped unicode (this may be
worthy of explanation but I don't think it relates to your point). Can you
please explain? 

6. Approach for comments

Presumably, I am not the only one who can imagine a need to either

	A. keep comments (cf. a copyright notice at the beginning of a
	B. translate comments (cf. a localized copyright notice at the
beginning of a file)

Thus, we may want to reconsider the approach related to the handling of
comments (the draft recommends to put them in a 'note' element).
[Tony]I think comments could be treated as normal strings,  with some sort
of notation in the resname to indicate they don't have a corresponding key.
I think it will be more complicated to deal with comments and untranslatable
code in List Resource Bundles...
7. Numbering/naming scheme for 'Id' attribute and ordering

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]