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

["Tony Jewtushenko" <tony.jewtushenko@productinnovator.com>]

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,
Christian

P.S.: I refer to
http://lists.oasis-open.org/archives/xliff/200509/msg00002.html
---

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.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html
http://www.opensourcetutorials.com/tutorials/Server-Side-Coding/Java/loa
ding-properties-from-xml/page1.html

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd";;>
<properties>
<comment></comment>
<entry key="java.runtime.name">Java(TM) 2 Runtime Environment, Standard
Edition </entry> <entry
key="sun.boot.library.path">C:\Programme\j2sdk1.5.0\jre\bin</entry>
<entry key="java.vm.version">1.5.0-beta-b32c</entry>
<entry key="java.vm.vendor">Sun Microsystems Inc.</entry> <entry
key="java.vendor.url">http://java.sun.com/</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
processing).

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


3. Provide pointers to Java pages on internationalization
=========================================================

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

http://java.sun.com/docs/books/tutorial/i18n/

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.
http://java.sun.com/docs/books/tutorial/i18n/format/messageFormat.html

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

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:

	saveLabel=Save
	saveImage=resources/save.gif

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
file)
	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
==========================================================