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

[Naoto Sato]

Hi Michael,

Looks like the list does not reflect the recent changes introduced by 
the re-organization of the locale data (sun/util/resources).

To me, just keeping an eye on the files sounds error prone. Would it be 
possible to add some automated check, say in "jcheck"?

Naoto

On 9/10/12 2:26 PM, Michael Fang wrote:
> 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
>>
>