<i18n dev> [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo

[Michael Fang]

Hi Mark and all,

I have updated the webrev:
http://cr.openjdk.java.net/~mfang/7196354/webrev.01/

It includes the following changes:

- removed component division and contact names
- removed redundant "target" attributes


I am also moving the file from root of source tree to jdk/make/jdk.tbom. SGT strongly recommends we follow the standard file naming convention used by the translation system, which is component-name.tbom. This is followed by all Oracle products requiring translation.


We currently have no plan to publish the syntax and semantics to the 
openjdk community through JEP process. We would like to keep the syntax 
internal. When I review dev team's changes related to resource files, I 
will keep an eye on the files to be translated and translation language 
scope.

thanks,

-michael
Server Globalization Technology

On 12年09月06日 04:46 下午, Michael Fang wrote:
> Hi Mark,
>
> Thanks for the review and feedback.
>
> Please see my comments inline below.
>
> thanks,
>
> -michael
>
> On 12年09月06日 01:29 下午, mark.reinhold at oracle.com wrote:
>> 2012/9/5 14:08 -0700, michael.fang at oracle.com:
>>> Please help to review the new JDK8 file for the following CR:
>>> 7196354 check-in jdk.tbom file to openjdk repo
>>>
>>> The webrev is located at:
>>> http://cr.openjdk.java.net/~mfang/7196354/webrev.00/
>> This file needs a more descriptive name, especially if it's going to be
>> in the root of the source tree.  Suggestion: translated-files.xml .
> The translation drop system is now an Oracle-wide translation system 
> and we are strongly recommended to follow the standard naming 
> convention for all Oracle products, which is component-name.tbom.
>
> I have checked with the team and we can move the file away from the 
> root of the source tree to, for example, jdk/make/jdk.tbom.
>
>>
>> Is there a DTD or a schema for this file?  I can guess what most of it
>> means, but I might guess incorrectly.
> The XSD is available in NLSTOOLS ADE label.
> nlstools/lights2/Extractor/src/java/xsd/tbom.xsd
> It's internal information. I will find it and forward it to you 
> separately.
>>
>> [line 8] "OpenJDK" isn't a component, it's a community.  I think you 
>> mean
>> "JDK" here.
> Yes, JDK.
>>
>> The "JDK" / "JRE" division in this file is somewhat artificial and 
>> likely
>> to become incorrect over time -- not every developer knows exactly which
>> files are in the JRE vs. the full JDK.  I suggest doing away with that
>> division and simply sorting the file-set elements by source file name.
> JDK and JRE are translated into different sets of languages. 2 
> languages for JDK and 10 for JRE. We used to divide the files this way 
> in order to translate the files into the correct set of languages. But 
> it's not necessary now. Sorting by groups or projects may be fine. 
> Whatever is easy for the groups/teams to find and maintain their files.
>>
>> At a glance it looks like the source and target attributes for any given
>> file are identical.  Do you expect there to be cases where they're
>> different?
> In jdk.tbom, source and target are the same for all files. But on 
> jdkclosed.tbom, the man page files have different source and target 
> directories.
>>
>>> ...
>>>
>>> Mark:
>>> Since the dev team will need to maintain this file in the future 
>>> (modifying it
>>> if you add or delete resource files), I temporarily put down your 
>>> name as
>>> contact for the file. Please figure out the proper owner and we can 
>>> update it
>>> again.
>> We don't put contact names in source code.  Please remove my name, 
>> and do
>> not add another.
> OK, I will remove it.
>>
>>> ...
>>>
>>> In the future, if any bug/rfe requires adding/deleting resource 
>>> files, the dev
>>> work should include updating this file to reflect the correct 
>>> resource file
>>> list. (and please ask me to review it).
>> If you expect other people to update this file over time then you need
>> to document that expectation somewhere and, as importantly, you need to
>> document the syntax and semantics of the file.  Fortunately we have a
>> way to do that, namely the JEP process (http://openjdk.java.net/jeps/).
>> I suggest you draft a JEP for this and circulate it for review along
>> with the webrev.
> I will look into it.
>>
>> - Mark
>